Bug 145928 - Installation with root filesystem on LVM fails
Summary: Installation with root filesystem on LVM fails
Status: RESOLVED FIXED
Alias: None
Product: SUSE Linux 10.1
Classification: openSUSE
Component: Installation (show other bugs)
Version: Beta 2
Hardware: i686 Other
: P5 - None : Normal (vote)
Target Milestone: Beta 3
Assignee: Thomas Fehr
QA Contact: Klaus Kämpf
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 146095
  Show dependency treegraph
 
Reported: 2006-01-26 17:59 UTC by Carl-Daniel Hailfinger
Modified: 2006-04-06 22:01 UTC (History)
2 users (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
y2logs (142.36 KB, application/x-gzip)
2006-01-26 18:08 UTC, Carl-Daniel Hailfinger
Details

Note You need to log in before you can comment on or make changes to this bug.
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.