Bug#271038: Same problem happening on different hardware/kernel version ?
Hi.
We've experienced the same kind of problem on a PowerEdge 2650 Dell
server with a 2.6.8 686 SMP image...
The problem came from lack of /dev/console and /dev/null in the root
partition on the disk.
I initially thought I stroke bug #278720
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278720), but actually,
I think both may be merged... or not... not sure if same problems
although symptoms can look the same.
I've described my findings in the following comment sent to bug #278720
(which is now closed... maybe this one should be too, if problem is the
same ?) :
=============================
I think we have experienced a different problem although it
looked the same : there may be several problems which can lead to the
symptoms of the initial bug-report.
The problem seems to have been caused by the lack of /dev/null and
/dev/console created on the root partition (the partition was
accessible, having the scsi driver loaded ok, but /dev empty).
The previous configuration operated on a 2.4.27 kernel actually used a
devfs, I think, so we beleived the devices where there on the root
partition whereas they weren't. Creating the devices solved the problem.
Maybe the /dev missed the devices since it was installed with a beta
installer ?
Also we were a bit mislead as believing this was specific to this
machine type and hardware since it happend on a Poweredge 2650 too. But
actually it's just a problem of /dev lacking console and null on the
disk.
For the records, it was mentioned in the threads that this has something
to do with the aic7xxx SCSI disk driver. But some of the PowerEdge 2650
servers are shipped with the Perc 3/Di controller which requires the
aacraid driver... so it may not be a problem with the aic7xxx driver in
the initrd image.
Anyway, if someone looks for information on that issue, here are some
hints. While trying to figure out what went wrong, I read several pages:
[SNIP]
The solution was described in the UDEV primer at :
http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html#consnull :
"If this is a new install and configuring it for a Pure UDEV system, or
you get an error when you finally reboot after installing udev and
setting it correctly like this: WARNING: Unable to open an initial
console. It is because there is no /dev/console and /dev/null. What is
happening is that /dev/console is needed before udev is populating the
/dev folder. You can try this by manually deleting all static devices in
/dev folder from another system, then rebooting to the udev system. You
will get the console error. You will also notice that it is faulting at
a time before it normally loads udev. If you just make /dev/console
though it will then fail for /dev/null. So it needs both of those static
in /dev, at least for the time being. The fix for now is to manually
create them in your /dev folder.
cd /dev
mknod -m 660 console c 5 1
mknod -m 660 null c 1 3
This will create the /dev/console and /dev/null statically in your /dev
folder."
Also there was a discussion about that issue in the thread starting here
: http://www.ussg.iu.edu/hypermail/linux/kernel/0410.1/0608.html
I'm not sure I got it right, but I think this suggests that maybe the
initrd init process may not depend on the presence of null and console
on the disk ? ... If by bad luck these happen to be removed (or never
created ? ... installer's fault ?), we tend to be in bad situation.
Hope this helps and sorry again for unnecessary annoyances.
Best regards,
=============================================
Now, maybe there is no problem with initrd... and just issues with lists
of modules configured by the installer... problems of later upgrades and
then partitions not accessible at boot time... or the initrd should not
depend on null and console being present on the root partition...
Hope this helps.
Best regards,
--
Olivier BERGER <olivier.berger@int-evry.fr>
Ingénieur Recherche - Dept INF
INT Evry (http://www.int-evry.fr)
OpenPGP-Id: 1024D/6B829EEC
Reply to: