> Anyone know how to fix this? As soon as the kernel decompresses, and
> searches for hardware, etc, it complains about not being able to find an
> initial console. Then, it tries to run rc.sysinit, but since the
> filesystem is read-only at this point, a write to /dev/null fails. Then
> it locks.
> I know it's my fault :) I was upgrading some stuff from Mandrake Cooker.
> What could possibly cause the message "Unable to open initial console"
> to appear. I upgraded glibc, and MAKEDEV, among many other things.
> Also complains about not being able to dup2() some descriptor, but I
> assume that's related to not being able to open a console.
> Any info appreciated,
> Steve
Had exactly the same problem *after* upgrading dev to dev-3.3.1. Here's
the excerpt of various emails I sent to mandrake cooker to correct this
problem.
HTH
John
P.S Make sure to upgrade to the latest dev after fixing which corrects
this problem.
Quote:> Upgraded dev to dev-3.3.1 following instructions (option 1) as outlined
> in earlier mandrake cooker email. Now system will not boot and I'm
> getting the dreaded "Unable to open an initial console" message.
> What cerrective actions should I take to get system back online.
1. boot on rescue, mount your root fs. your problem was fixed in -2mdk.
2. chroot /mnt
3. /usr/sbin/mdk_makedev /dev
4. "find /dev|wc -l" should report ~19k files
Quote:> My /dev directory has ~16.8k files in it after executing these commands.
> The system now gets further along in the boot process but now I'm
> getting the following errors:
> setting default font: dup2: bad file descriptor [Failed]
> /etc/rc.sysinit: /dev/null: read-only file system
something has accedded /dev/null at the bad time and create a file instead
of a device.
on the rescue, you can do "find /dev/ | xargs rm -fr" in the chrooted
environment before running mdk_makedev (which don't overwite already
existing entries).
longer explanation:
?????? 1) 1mdk and 2mdk had typos :-(
?????? 2) while updating from <3.3.1-1mdk, there's a 7 seconds race
????????? window, which make possible to have a program that
write to /dev/null whereas the old one has been delete
by rpm but the new one isn't yet created, thus
resulting in a file insead of a special device;
????????then the next process which'll try to access /dev/null
'll have some problems ....
?????? as /dev/null is one of the rare /dev/ entries one write to,
and is the device that get 99% of the writes in /dev/, i'll
put a special case in dev-3.3.1-4mdk, something as:
????????????? while [[ ! -c /lib/root-mirror/dev/null ]]; do
??????????????????? rm -f /lib/root-mirror/dev/null
??????????????????? mknod -m 0666
/lib/root-mirror/dev/null c 1 3 ???????????????????
chown root.root /lib/root-mirror/dev/null done
??????
?????? so that we'll be sure to have a valid /dev/null after dev
update
by