Bug 145928

Summary: Installation with root filesystem on LVM fails
Product: [openSUSE] SUSE Linux 10.1 Reporter: Carl-Daniel Hailfinger <kernel01>
Component: InstallationAssignee: Thomas Fehr <fehr>
Status: RESOLVED FIXED QA Contact: Klaus Kämpf <kkaempf>
Severity: Normal    
Priority: P5 - None CC: hare, michael.raskey
Version: Beta 2   
Target Milestone: Beta 3   
Hardware: i686   
OS: Other   
Whiteboard:
Found By: Development Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Bug Depends on:    
Bug Blocks: 146095    
Attachments: y2logs

Description Carl-Daniel Hailfinger 2006-01-26 17:59:29 UTC 
I have an existing installation with everything except /boot on LVM. When I tried to install Beta 2 over the existing system (format existing root filesystem, leave everything else as-is), installation failed in the "preparing harddisk" stage.

(rough translation from german)
"Error: The following action resulted in error: Formatting logical volume /dev/system/slash (8,0 GB) with reiserfs. System error code: -3030"

Y2logs say the following:
"INFO libstorage - Volume.cc(checkDevice): 868 checkDevice:/dev/system/slash ret:-3030"

Will attach y2logs in a second.
Comment 1 Carl-Daniel Hailfinger 2006-01-26 18:01:59 UTC 
Interesting thing: /dev/system/slash indeed doesn't exist at that stage.
Comment 2 Carl-Daniel Hailfinger 2006-01-26 18:08:54 UTC 
Created attachment 65290 [details]
y2logs
Comment 3 Carl-Daniel Hailfinger 2006-01-27 01:30:04 UTC 
It seems the installer forgets to run "vgchange -a y" before foratting the disk.

When I run "vgchange -a y" manually, I can install perfectly, until the bootloader is about to be installed. Then another bug bites: /boot is mounted before / and is invisible because of that.
Comment 4 Carl-Daniel Hailfinger 2006-01-27 01:52:28 UTC 
After working around the problems mentioned above, the installer does install the bootloader correctly, but doesn't unmount all partitions/volumes (notably, it forgets to umount /mnt/sys ) and thus deactivating the logical volumes fails.
After working around that bug, the first stage of the installation is ok.

After reboot, I'm faced with the error message "not found -- exiting to /bin/sh".
The kernel can't find its root filesystem because the vgchange binary isn't in the initrd. Not sure how to work around that problem.
Comment 5 Carl-Daniel Hailfinger 2006-01-27 04:40:52 UTC 
And mkinitrd has a VERY subtle bug where a file from /proc is read in the following way:

while read a b; 
do
// something
done </proc/devices

That fails (actually, only the first ew bytes will be read) because the file is on /proc! Never assume files in /proc can be handled the normal way. You need cat ro read them completely.

After fixing that bug in my local sources, at least mkinitrd recognized it had a root filesystem on LVM. However, it included everything ecxept dmsetup in the initrd, so the boot failed again.
Comment 6 Carl-Daniel Hailfinger 2006-01-27 04:45:06 UTC 
Hannes: Please see comment #5 for a small mkinitrd bug.
Comment 7 Carl-Daniel Hailfinger 2006-01-27 05:46:29 UTC 
To reproduce the mkinitrd problem, try this script. It will only show you the first 2 lines of /proc/devices. Since /proc/devices is has listed 0 bytes as size, it is debatable whether that is an ash bug.

#!/bin/ash
while read a;
do
echo $a
done </proc/devices
Comment 8 Carl-Daniel Hailfinger 2006-01-27 06:26:37 UTC 
Sorry for mixing 2 bugs in one. The mkinitrd story is now in bug #146095.
Comment 9 Hannes Reinecke 2006-01-30 10:48:33 UTC 
Fixed up mkinitrd to use 'cat ... | sed ... | tail' instead of the while read shell construct.
Comment 10 Thomas Fehr 2006-01-30 11:35:02 UTC 
The funcion "import existing fstab" had the side effect of disabling active
LVM LVs. This should be fixed in beta#3. 

If possible it would be helpful if you could retry the exact same installation
with beta#3.
Comment 11 Carl-Daniel Hailfinger 2006-01-30 13:31:01 UTC 
Thanks, will try the exact same installation once Beta3 is available.
Comment 12 Michael Gross 2006-04-06 18:07:35 UTC 
*** Bug 163951 has been marked as a duplicate of this bug. ***
Comment 13 Michael Gross 2006-04-06 18:20:15 UTC 
The problem has reoccured, reopening, look at bug #163951.
Comment 14 Thomas Fehr 2006-04-06 22:01:21 UTC 
I strongly doubt #163951 is a duplicate of this one.