i’m stuck with a new installation of openSUSE 12.3 failing on boot and am hoping for some guidance. (sorry for the long post, trying to provide the relevant info)
to make a long story less tedious let’s try this:
i am more-or-less a linux n00b though i’ve learned a bit after a year with Ubuntu and Mint and am now distro-hopping.
i have several distros installed on my old WinXP box including Ubuntu, Mint, #!, Manjaro, etc. they all boot fine from a fairly heavily hacked grub.cfg file sitting on the Mint partition.
i am hacking grub.cfg directly (a) because i’m trying to learn my way around GRUB2 and (b) because os-prober makes a hellacious mess out of my boot menu and i’m going to have to do most of it via the 40_custom route anyway so doing it via grub.cfg seemed the quick and dirty way to learn the ropes. thus far that’s worked out fine and, as i said, i have the other distros booting fine. of course i’ll eventually have to redo everything properly via 40_custom, etc.
i have recently installed openSUSE 12.3 from downloaded install DVD – verified iso and burn – did everything by the defaults except choosing a specific partition and the bootloader part where i selected “do nothing”. fwiw the openSUSE install is on partition sda23 of /dev/sda.
my hacked grub.cfg menuentry for openSUSE is:
menuentry 'openSUSE 12.3 with XFCE (on /dev/sda23)' --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-e297bac7-d9fd-4352-85f5-3bca24c620cd' {
insmod part_msdos
insmod ext2
set root='hd0,msdos23'
if x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos23 --hint-efi=hd0,msdos23 --hint-baremetal=ahci0,msdos23 e297bac7-d9fd-4352-85f5-3bca24c620cd
else
search --no-floppy --fs-uuid --set=root e297bac7-d9fd-4352-85f5-3bca24c620cd
fi
echo 'Loading openSUSE 12.3 vmlinuz-3.7.10-1.1-default ...'
linux /boot/vmlinuz root=/dev/sda23 showopts
echo 'Loading ramdisk initrd-3.7.10-1.1-default ...'
initrd /boot/initrd
}
**when i attempt to boot into openSUSE i get the echo stuff from above, then a bunch of boot procedure output flashes by which all comes to a halt with:
resume device not found (ignoring) …
waiting for device /dev/sda23 to appear …
**
after a minute or two it gives up, burps up something about “USB disconnect” then asks if it should “fall back to /dev/disk/by-id/ata-WDC_WD5000AAKB…-part23” and then goes into an endless cycle looking at USB ports or somesuch.
in the course of my googlings i read that a munged up fstab file can cause the “waiting for device …” error message. fwiw this is /etc/fstab from my openSUSE partition:
You problem has nothing to do with miltiboot or grub, as kernel is obviously loaded. It looks like either initrd is missing drivers for your root disk or partition counting is different between different systems. For a start, you could append shell=1 to kernel command line; it will stop at the end of linuxrc, spawn a shell and you get chance to poke around what is available at this point. May be device is there but for some reasons is called differently.
Rebuilding initrd may help as well. Boot into rescue mode (I’m not sure whether 12.3 offers it now on installation DVD or you need extra ISO for it), bind-mount /dev, /sys, /proc, /run into installed system, chroot into it and just do mknitrd.
… installed openSUSE 12.3 from downloaded install DVD – verified iso and burn …
fwiw i’m running off a 10-year old P4 system, a P4P800 m/b, from which i have never successfully booted via USB. latter versions of the BIOS allow you to add USB as a boot oprion, which i have, but it’s never worked. my wife has a eeePC which will boot fine off of USBs that my P4 just chokes and dies on.
well that’s a bit of good news. nice to know that, at least, is functional. i’ll tweak it as you’ve suggested.
Rebuilding initrd may help as well. Boot into rescue mode (I’m not sure whether 12.3 offers it now on installation DVD or you need extra ISO for it), bind-mount /dev, /sys, /proc, /run into installed system, chroot into it and just do mknitrd.
ok, that sounds challenging, looks like a learning experience for sure. is there detailed procedure for this somewhere, to aid my n00bness, or should i just jump in?
This likely won’t help you, but I saw something similar error behaviour on a test PC I tried to change openSUSE with its 3.7.x kernel to an older 3.6.x kernel. Changing to an older kernel was not easily possible.
However this should not be the case for you in a fresh install, so it is puzzling what this could be.
I recommend you to change location of grub to other distro of your choice, command grub2-install your patition and grub-mkconfig -o /boot/grub/grub.cfg Grub of openSUSE has many problems for me.
when i attempted to boot into opensuse after the mkinitrd, i saw exactly the same result as before:
resume device not found (ignoring)
waiting for device /dev/sda23 to appear …
when i had booted from the install disk into Rescue the opensuse partition was listed as /dev/sdd23 instead of the usual /dev/sda23. this is not unusual afaik, i often see that drive appear as something other than sda when i boot off of live disks. when i boot from bios into GRUB though it is always sda.
given this i tweaked the second step of the mkinitrd procedure slightly: instead of “mount /dev/sda23 /sysroot” i used “mount LABEL=opensuse /sysroot”. obviously i had previously labeled my partition as “opensuse”. everything else proceeded as shown and /sbin/mkinitrd seemed to complete, no errors. there was indeed a new initrd in /boot: initrd-3.7.10-1.1-default with the appropriate timestamp.
sorry to be a pest but if i may: any further thoughts?
Please, use “code” tags when quoting computer output. They are a) better formatted b) not removed from replies to your posts.
waiting for device /dev/sda23 to appear ....
when i had booted from the install disk into Rescue the opensuse partition was listed as /dev/sdd23
Well, that’s likely the problem. Your disk is not /dev/sda when you boot. I already suggested you to stop in initrd and look around.
i had previously labeled my partition as “opensuse”
Then try to boot with root=LABEL=opensuse instead of root=/dev/sdaXXX. And after having booted, fix your /etc/fstab to use either device id or device label and rebuild initrd again.
thing.
guess there was some confusion re "shell-1". i thought you meant add that to kernel line in the grub menuentry for opensuse which i did and it had no effect. having poked around i now understand that you may have meant setting "startshell=1" as a boot parameter during either the install and/or rescue. i didn't get that at the time, my bad.
that said, changing "root=/dev/sda23" to "root=LABEL=opensuse" as you suggested DID allow me to boot into the opensuse partition. in fact i am posting from there now. the boot cycle took a heck of a long time -- seemed to stall on something related to the sound card, etc -- but i'm sure i can google around for info on those issues.
fwiw i ran blkid from within opensuse and the "opensuse" partition does in fact appear as sdd23 and not sda23. i find this a bit of a surprise because a number of my other grub menuentry items use "/dev/sda.." and they work fine. and as i've said, that drive usually **does** appear as "sda". obviously there is something less than 100% predictable there and in my n00bness i have no clue what that might be.
in any case i am up and running in opensuse so many thanks for your patience and assistance.
it’s shell=1. I just tested it and it stops in initrd.
i find this a bit of a surprise because a number of my other grub menuentry items use “/dev/sda…” and they work fine. and as i’ve said, that drive usually does appear as “sda”.
Do not use /dev/sdX anywhere directly. Even booting with plugged in USB stick may cause drive renumbering.
yes, sorry, that was a typo, i realise it was “…=1” not “…-1”.
clearly i’m still not getting it though. where did you put that? (a) kernel line of the menuentry or (b) as an extra parameter during Rescue boot? i tried (a) and it seemed to have no effect. i’d like to know for next time.
fwiw it is apparently not just a matter of changing “root=/dev/sd…” to the corresponding “root=LABEL=…” in the “linux” statements of the grub menu.
i did that and half of my distros would not boot, namely Zenwalk, Slacko Puppy and aLinux. same result when i used the UUIDs for those partitions: no go. on the other hand half or more of them were fine with the change (Mint, Manjaro, Xubuntu, antiX).
only when i changed those statements back to using “root=/dev/sd…” would those non-booting partitions boot again. doubtless it’s because i am in over my n00bie head here but i think it’s worth knowing because it would seem to point to bigger issues being involved.
Well … it is also distribution dependent, of course. E.g. you need initrd (or similar) to interpret those names. Those distributions I have worked with all did not have problems with LABEL/UUID.
out of respect and the desire to not get lost in the naming of things i have been following your lead (post #3 of this thread):
For a start, you could append shell=1 to kernel command line …
anyway, as i’ve said twice now, i did that – or what i think you intended, hard to tell because it seems a rather difficult usage to find any documentation on – and the results were ziltch: no shell as far as i can see or tell. all keyboard input was completely ignored throughout.
thank you for confirming that the usage of “root=…” is distro independent. that may be obvious to you but when you said “do not use /dev/sdX anywhere directly” perhaps you forgot to mention that it was only applicable to “those distributions I have worked with”.
again though, thank you for your help. you’ve been very generous with your time, your assistance has been invaluable, and we got there in the end.
nice to know that, at least, is functional. i’ll tweak it as you’ve suggested.