[Bug 329655] New: Cannot boot if SUSE has / on an USB external hard drive
https://bugzilla.novell.com/show_bug.cgi?id=329655 Summary: Cannot boot if SUSE has / on an USB external hard drive Product: openSUSE 10.3 Version: RC 1 Platform: i686 OS/Version: openSUSE 10.3 Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: giosif@ase.ro QAContact: jsrain@novell.com Found By: --- Hello, While installing OpenSUSE 10.3 RC1, I used an LVM group on an USB external hard drive for creating the root partition. The first part of the setup (until the first reboot) went without problems, but, after rebooting, the root partition would not be detected any more. After some troubleshooting, I found out that the script that activates the LVM group (/boot/62-lvm2.sh) is run BEFORE the USB subsystem had time to finish detecting all attached devices (especially, but not limited to, when using external USB hubs). The way I solved the problem was by inserting a /bin/sleep 10 line in the /boot/62-lvm2.sh file from the initrd, right before the following statement: for vgr in $lvm $vg_root $vg_roots; do vgchange -a y $vgr done Now, although this solved my particular problem, I think you should consider the delay (that the USB subsystem introduces while scanning and detecting devices) in a more general manner (I haven't figured it out when exactly does the boot process activate the USB subsystem - 04-udev.sh maybe ?) because it may affect other installation scenarios as well (external USB drive with no LVM, or with software RAID). The problem was also present in Beta 3 but I didn't have the time to troubleshoot. Cheers, George Iosif -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=329655 Cyril Hrubis <chrubis@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.provo.novell.com |hare@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=329655#c1 Hannes Reinecke <hare@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #1 from Hannes Reinecke <hare@novell.com> 2007-10-15 04:39:56 MST --- Please increase the udev timeout by adding eg 'udev_timeout=60'. The default of 30 seconds might be too short here. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=329655#c2 George Iosif <giosif@ase.ro> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | --- Comment #2 from George Iosif <giosif@ase.ro> 2007-10-15 17:08:36 MST --- Hi, I'm sorry, but this does not solve the problem. The true cause is not that udev doesn't create the "real" (read /dev/sdX for my case) devices in the default 30 seconds (it creates them, until the 30 seconds expire), but the fact that, by the time the /boot/62-lvm2.sh script is run, the specific external USB device (in my case, /dev/sdb and its partitions) is not yet "seen" by the USB subsystem (and, therefore, neither by udev), and, as such, cannot activate the LVM volumes present on that specific device. By the time the boot process reaches the "Waiting for the root device to appear..." stage (when the udev_timeout value kicks in), the USB subsystem has finished enumerating the devices, udev has created the devices in /dev (including /dev/sdb and its partitions), but it's already too late, since the LVM volumes will not be activated (so, no /dev/NAME_OF_LVM_VOLUME/NAME_OF_LOGICAL_VOLUME(S) files present). If needed, I can go into more detail with the description of the problem. Cheers, George Iosif -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=329655#c3 Hannes Reinecke <hare@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WORKSFORME --- Comment #3 from Hannes Reinecke <hare@novell.com> 2007-10-18 04:04:15 MST --- Not true. udev_timeout is used as the timeout for udevsettle, too. And this is called from /boot/21-devinit_done.sh, before lvm detection starts. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=329655#c4 George Iosif <giosif@ase.ro> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | --- Comment #4 from George Iosif <giosif@ase.ro> 2007-10-27 18:49:32 MST --- Hi, Sorry for... bugging you again, but, as I said, udev_timeout doesn't solve my problem. I went through the scripts (from the initrd file) and you are right, udevsettle is called before lvm detection (so, I understand your logic). The problem is that /boot/21-devinit_done.sh executes and finishes almost instantly, which would imply that there is no queued kernel/udev event left unhandled, even if the external drive is not present in /dev yet (I modified the /boot/21-devinit_done.sh script to include the following sequence: ls /dev cat /proc/partitions both before and after the execution of the udevsettle line and the output is the same in both cases: no /dev/sdb -- my external drive.). Later though, the /dev/sdb (and it's partitions) device is created, but it's already too late (the lvm detection script has executed for some time). Is this an udevsettle bug ? Cheers, George Iosif -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=329655#c5 Hannes Reinecke <hare@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |ASSIGNED --- Comment #5 from Hannes Reinecke <hare@novell.com> 2007-10-30 03:31:31 MST --- No, it's a bug in boot-devinit_done.sh. Currently it just calls udevsettle, which will return if no events are pending. In the case of USB the bus scanning is invisible to the upper levels, ie it's not possible to determine if and when the USB bus scanning is complete; one could even argue that the USB bus scanning is _never_ complete as device might come and go as they please. But we will only get events once the USB bus driver detected a device; and the event stack will be empty until then. So we should rather call udevsettle in a loop if using USB so that we are guaranteed to wait a specified time. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=329655 User hare@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=329655#c6 Hannes Reinecke <hare@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |DUPLICATE --- Comment #6 from Hannes Reinecke <hare@novell.com> 2008-01-10 05:35:22 MST --- This is actually the same issue than bug #343891 *** This bug has been marked as a duplicate of bug 343891 *** https://bugzilla.novell.com/show_bug.cgi?id=343891 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com