Bug 147366

Summary: Installer mounts filesystems in wrong order, resulting in boot failure
Product: [openSUSE] SUSE Linux 10.1 Reporter: Carl-Daniel Hailfinger <kernel01>
Component: InstallationAssignee: Thomas Fehr <fehr>
Status: RESOLVED DUPLICATE QA Contact: Klaus Kämpf <kkaempf>
Severity: Normal    
Priority: P5 - None CC: stefan.fent, susedev
Version: Beta 3   
Target Milestone: ---   
Hardware: Other   
OS: Other   
See Also: http://bugworks.engr.sgi.com/query.cgi/949002
Whiteboard:
Found By: Development Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: y2logs
tarball of fdisk -l,lvdisplay,vgdisplay,pvdisplay
tarball with disk info, y2logs ,etc.

Description Carl-Daniel Hailfinger 2006-02-01 19:25:56 UTC
My / is on LVM and my /boot is a "normal" partition. Unfortunately the installer mounts /boot before / and so the contents of /boot end up on the wrong partition.

y2logs will be attached in a minute.
Comment 1 Carl-Daniel Hailfinger 2006-02-01 19:29:13 UTC
Created attachment 66081 [details]
y2logs
Comment 2 Michael Gross 2006-02-01 21:05:54 UTC
Please also attach /etc/fstab itself and the output of `fdisk -l'.
Comment 3 Carl-Daniel Hailfinger 2006-02-01 21:39:22 UTC
"fdisk -l" for both hard disks is already in the tarball (it has everything in /var/log/YaST2).

/etc/fstab can be easily extracted from y2log as follows:
# cat var/log/YaST2/y2log|grep "EtcFstab.cc.createTabLine.:[0-9]* ret:"|sed "s/.*ret://"


For your convenience, I have done that step.
LABEL=Linux_boot2    /boot                ext2       acl,user_xattr        1 2
LABEL=LVM_Root       /                    reiserfs   noatime,acl,user_xattr 1 1
/dev/hda8            swap                 swap       defaults              0 0
/dev/hdb7            swap                 swap       defaults              0 0
LABEL=LVM_Home       /home                reiserfs   noatime,acl,user_xattr 1 2
LABEL=LVM_storage    /storage             reiserfs   noatime,acl,user_xattr 1 2
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
/dev/hda5            /data1               auto       noauto,user           0 0
/dev/hda7            /data2               auto       noauto,user           0 0
/dev/hda9            /data3               auto       noauto,user           0 0
/dev/hda10           /data4               auto       noauto,user           0 0
/dev/hdb6            /data5               auto       noauto,user           0 0
Comment 4 Michael Gross 2006-02-02 12:18:12 UTC
Please attach these files anyway, the problem might be located somewhere in YaST itself, which would be hidden that way. A vgscan of your disks would also be useful.
Comment 5 Erik Jacobson 2006-02-02 14:38:48 UTC
SGI QA hit this issue too.  If there is something our QA team could provide
in the way of testing here and logs, we could try it too.
Comment 6 Michael Gross 2006-02-03 10:57:17 UTC
Erik: the LVM- and partition-configuration of the affected systems would sure be useful, as well as the yast logfiles.
Comment 7 Carl-Daniel Hailfinger 2006-02-03 15:20:58 UTC
Created attachment 66368 [details]
tarball of fdisk -l,lvdisplay,vgdisplay,pvdisplay

OK, my fstab is identical with the one I included in the comment above. All other information (fdisk -l, lvdisplay, vgdisplay, pvdisplay) is in the tarball.
Comment 8 Erik Jacobson 2006-02-07 16:54:28 UTC
Created attachment 66831 [details]
tarball with disk info, y2logs ,etc.

Hi.  Sorry for the delay.  Jim in QA got back to me
and here is a tarball that includes disk
configuration, volume info, and some logs.
Comment 9 Thomas Renninger 2006-02-07 22:08:02 UTC
I wonder why this ended up in my box?
-> Reassigning to fehr for Yast stuff.
-> Adding sf to CC whether this has to do with latest Yast bootloader changes
Comment 10 Thomas Fehr 2006-02-08 09:50:37 UTC

*** This bug has been marked as a duplicate of 146838 ***