Hi,
I made an update from FC2 to FC3, and now, my machine will no more boot: The boot stops when executing the init scripts: having problems with the /dev directory (cannot open /dev//null and/or /dev//console). I'm not using the FC3 kernel, but the vanilla kernel 2.6.9. When using the FC3 kernel, all is OK. I think, it has to do with udev (in my vanilla kernel, hotplug is configered correctly!).
Regards
Joachim Backes
--
Joachim Backes backes@rhrk.uni-kl.de University of Kaiserslautern,Computer Center, High Performance Computing, D-67653 Kaiserslautern, PO Box 3049, Germany -------------------------------------------------- Phone: +49-631-205-2438, FAX: +49-631-205-3056 http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html
On Wed, 2004-11-10 at 15:52 +0100, Joachim Backes wrote:
Hi,
I made an update from FC2 to FC3, and now, my machine will no more boot: The boot stops when executing the init scripts: having problems with the /dev directory (cannot open /dev//null and/or /dev//console). I'm not using the FC3 kernel, but the vanilla kernel 2.6.9. When using the FC3 kernel, all is OK. I think, it has to do with udev (in my vanilla kernel, hotplug is configered correctly!).
did you also make an initrd?
(if you used "make install" in the kernel tree one should have been created for you automatically, as well as it being added to grub automatically)
On Wed, 2004-11-10 at 15:52 +0100, Joachim Backes wrote:
Hi,
I made an update from FC2 to FC3, and now, my machine will no more boot: The boot stops when executing the init scripts: having problems with the /dev directory (cannot open /dev//null and/or /dev//console). I'm not using the FC3 kernel, but the vanilla kernel 2.6.9. When using the FC3 kernel, all is OK. I think, it has to do with udev (in my vanilla kernel, hotplug is configered correctly!).
I've seen this as well- have been unable to get FC3* to run under a vanilla kernel.org kernel. When i disable the 'quiet' flag in grub, the boot process aborts with something like 'unable to open /dev/console'.
I never reported it because I thought i was missing something obvious- i guess I'm not the only one.
Arjan van de Ven wrote:
did you also make an initrd?
(if you used "make install" in the kernel tree one should have been created for you automatically, as well as it being added to grub automatically)
I know I did when I tried it, except i run mkinitrd manually.
Could this have something to do with udev? I noticed that if I enabled the deprecated /dev FS, it broke in a slightly different manner. I suspect the problem is the FC3 environment expects a magic combination of kernel options- I just have not been able to stumble upon them yet...
ron
On Wed, 2004-11-10 at 12:34 -0600, RON FLORY wrote:
I know I did when I tried it, except i run mkinitrd manually.
Could this have something to do with udev? I noticed that if I enabled the deprecated /dev FS, it broke in a slightly different manner. I suspect the problem is the FC3 environment expects a magic combination of kernel options- I just have not been able to stumble upon them yet...
hmm you need tmpfs enabled but beyond that... can't really think of anything.
On Wed, 2004-11-10 at 12:34 -0600, RON FLORY wrote:
I know I did when I tried it, except i run mkinitrd manually.
Could this have something to do with udev? I noticed that if I enabled the deprecated /dev FS, it broke in a slightly different manner. I suspect the problem is the FC3 environment expects a magic combination of kernel options- I just have not been able to stumble upon them yet...
Arjan van de Ven wrote:
hmm you need tmpfs enabled but beyond that... can't really think of anything.
yeah, I just tried it again. Looking at .config, tmpfs is definitely enabled, but the boot process aborts with:
"Warning: unable to open an initial console."
and thats the last thing it does.
I've tried this on perhaps 3 different makes/models of x86 systems, all with same results. In each case 'console' is either local laptop or generic x86 HW. I know this will be simple when it finally makes sense...
ron
P.S. Also, what has to be enabled in the kernel to support the grub 'root=LABEL=/' directive? I always have to supply literal 'root=/dev/hdax' with kernel.org kernels.
Thanks.
ron
On Wed, 2004-11-10 at 13:38 -0600, RON FLORY wrote:
P.S. Also, what has to be enabled in the kernel to support the grub 'root=LABEL=/' directive? I always have to
Arjan van de Ven wrote:
nothing. That is purely done and used by the initrd. are you *sure* you are properly using an initrd ???
using 2.6.9 from kernel.org:
while in /usr/src/linux-2.6.9:
mkinitrd -f -v /boot/initrd-2.6.9.img 2.6.9 ??
is this bogus?
ron
P.S. as a side note, i remember the LABEL=/ directive not working with kernel.org 2.4 kernels since RH8, and i never really *had* to bother with building initrds then. I just assumed some RH proprietary stuff was not present and didn't worry too much about it.
ron
using 2.6.9 from kernel.org:
while in /usr/src/linux-2.6.9: mkinitrd -f -v /boot/initrd-2.6.9.img 2.6.9 ??
is this bogus?
no but you have to tell your bootloader about it as well otherwise it just goes unused.
P.S. as a side note, i remember the LABEL=/ directive not working with kernel.org 2.4 kernels since RH8, and i never really *had* to bother with building initrds then. I just assumed some RH proprietary stuff was not present and didn't worry too much about it.
well that's the wrong assumption; LABEL= has never been a kernel side thing...
using 2.6.9 from kernel.org:
while in /usr/src/linux-2.6.9:
mkinitrd -f -v /boot/initrd-2.6.9.img 2.6.9 ??
is this bogus?
Arjan van de Ven wrote:
no but you have to tell your bootloader about it as well otherwise it just goes unused.
Like?
title Test (2.6.9) root (hd0,1) kernel /vmlinuz-2.6.9 ro root=/dev/hda4 rhgb initrd /initrd-2.6.9.img
except, substituting 'root=LABEL=/' for 'root=LABEL=/' keeps the bootloader from finding an initrd. As it is now, it just can't find a console ;)
Yet, the below target works when the FC3 kernel source is built and prepared with mkinitrd:
title Fedora Core (2.6.9-prep) root (hd0,1) kernel /vmlinuz-2.6.9-prep ro root=LABEL=/ rhgb initrd /initrd-2.6.9-prep.img
P.S. as a side note, i remember the LABEL=/ directive not working with kernel.org 2.4 kernels since RH8, and i never really *had* to bother with building initrds then. I just assumed some RH proprietary stuff was not present and didn't worry too much about it.
well that's the wrong assumption; LABEL= has never been a kernel side thing...
OK, I believe you- it just an 'unknown' i can work around without too much trouble. I am a bit curious why it behaves differently tho.
ron
On Wed, 2004-11-10 at 15:29 -0600, RON FLORY wrote:
title Test (2.6.9) root (hd0,1) kernel /vmlinuz-2.6.9 ro root=/dev/hda4 rhgb initrd /initrd-2.6.9.img
except, substituting 'root=LABEL=/' for 'root=LABEL=/' keeps the bootloader from finding an initrd. As it is now, it just can't find a console ;)
odd.. makes me wonder if you disabled initrd support in the kernel config...
Do you see the nash banner printed at all on the screen ? (which is about the first thing the initrd will do)
On Wed, 2004-11-10 at 15:29 -0600, RON FLORY wrote:
title Test (2.6.9) root (hd0,1) kernel /vmlinuz-2.6.9 ro root=/dev/hda4 rhgb initrd /initrd-2.6.9.img
except, substituting 'root=LABEL=/' for 'root=LABEL=/' keeps the bootloader from finding an initrd. As it is now, it just can't find a console ;)
Arjan van de Ven wrote:
odd.. makes me wonder if you disabled initrd support in the kernel config...
BINGO- although its not quite that simple or obvious.
It seems the initrd support option depends upon
Device Drivers -> Block Devices -> RAM disk support
which defaults to N or M on a 2.6.9 kernel.org kernel after 'make mrproper' etc. Historically I tend to set this to M.
Also, the most important option:
"initial RAM disk (initrd) support"
is disabled and not even visible unless "RAM disk support" is explicitly enabled (i.e., set to "Y"), which is not the case on a stock kernel. It makes this option pretty hard to find unless one knows exactly where it is and how to unhide it...
Anyway, enabling both these switches solved both the stock kernel.org kernel and and LABEL=/ issues.
Thanks for the hint- I suspected it would be something painfully simple, but not too obvious. I'm sure this issue will resurface again and again.
ron
I hit the same problem when updating from dev to udev the first time, just run /sbin/udevstart to create the necessary /dev entries before you reboot. You will likely need to umount /dev if you boot an FC kernel though.
Tom
On Wednesday 10 November 2004 19:42, Thomas Zehetbauer wrote:
I hit the same problem when updating from dev to udev the first time, just run /sbin/udevstart to create the necessary /dev entries before you reboot. You will likely need to umount /dev if you boot an FC kernel though.
I didn't understand this. What exactly do you mean by the last sentence? What command do you give, and when?