Bug 157129

In fact the messages are written after "Red Hat Nash version ..." and before
"Init version ...".

This continues to occur in the release version of Core 4, though it still does
not appear to be anything other than cosmetic. Has anyone actually seen an
instance where there in fact is no device node for the errored devices?

Also, I would suggest updating the version number for this bug to FC4.

*** Bug 158427 has been marked as a duplicate of this bug. ***

I am running a fresh FC4 install, downloaded from the official torrent. I am
getting these same errors, yet these files do exist.

I had the same messages with the final release of FC4, but the last update of
the selinux packages (1.23.18-12) seems to have cured the problem.

I'm on FC4 Final, SElinux disabled, and the error still occurs.
System is fully updated.

-RoNNY

Mass update of -test bugs to update version to fc4.
(Please retest on final release, and report results if you have not already done
so).

Thanks.

I'm not sure I understand that last message Dave.
What is it that you want done exactly?

Thanks

-RoNNY

Dave J.,

To confirm, the errors reported for this bug continue to occur in the release version of FC4.

-David N.

OK. So apparently I did understand what Dave J. asked for.
David is correct. FC4 *FINAL* (as I wrote above), still has the bugs.
Fully updated FC4.

-RoNNY

Confirm the same here 
well after start X with startx or kdm or gdm, my console becames with wrong
format with some blue on background , kdm doesn't start correctly always show a
default blue screen with login that I am not what I am asking for.

have you some workarround for this bug ? 

the console corruption is likely bug 161242

I still have no explanation for the original bug reported here.  Was the
mkinitrd package up to date when the kernel was installed ?

the problem happened after an FC4 install from scratch, and there hasn't been
any update to mkinitrd in FC4.  So, yes, it's up to date.  And, really, there's
not a lot of room for changes in the sequence that starts with udevstart and is
immediately followed by the mknods that fail.

In my previous post I wrote that the mknod issue seems to be resolved. However
it now appears to be almost random. On some reboots I do not receive the error,
but sometimes it is there. The same goes for when the PC is switched on or when
I had to do a hard reset.

Further, referring to comment #12, sometimes I cannot access the text consoles
using Ctrl-Alt-F1. The X window (gnome @ 1280x1024) simply changes size, locks
and places itself in the top-left of the screen (@ 1600x1200).

[This comment has been added as a mass update for all FC4 kernel bugs.
 If you have migrated this bug from an FC3 bug today, ignore this comment.]

Please retest your problem with todays 2.6.12-1.1398_FC4 update.

If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..

mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak
kudzu


Thank you.

This fixed the issue for me.

-RoNNY

I got the same problem on old Sony Vaio PCG-Z505R notebook. I did a fresh
install of FC4, which showed the problem. After "yum update" which brought
kernel to 2.6.12-1.1398_FC4, nothing changes and again I got during boot:

mknod failed to create console 17
mknod failed to create null 17
mknod failed to create zero 17

Same problem here after upgrading from FC3 to FC4, and yum update to have all
FC4 updates (including kernel) applied.

It seems random in that one some reboots, I don't see the error.

Same problem here on 3 different machines (P3@600+800 MHz, P4@2,4 GHz).
With initial kernel-2.6.11-1.1369_FC4 (after fresh install,
no custom initrd, everything on ) and updated kernel-2.6.12-1.1398_FC4.

Chances are about 75% that the errors don't appear. And sometimes
not all 3 mknod errors come up but only 2 or 1. Could that be
related to some timing problems during initrd processing?

The only "non-standard" thing on these machines is the software RAID-1
(via DiskDruid) which also caused a kernel panic after first installation
on all machines (right after the final "Reboot" button). But this seems
to be a different story.

Haven't had any of these errors on an AMD AthlonXP 2000 (single harddisk,
no RAID-1).

However, doesn't seem to be harmful. It just doesn't "look" good to
have errors during boot. ;-)

still a problem with the latest errata ?
(Note, there's also another going to be pushed *really* soon, which you can grab
& test at http://people.redhat.com/davej/kernels/Fedora/FC4/ )

I believe this was fixed with a mkinitrd update, that fixed a bug in nash's
wait() for child processes, by which it would not wait for the right child to
complete if any other child completed first.  Or something like that...

See Bug 163407 for the gory details.

Sorry to say that, but today I got the error messages again
with the newest kernel 2.6.14-1.1653_FC4 (and all other updates).
Obviously, it happens very rarely (haven't seen the messages
for weeks). But it looks like the bug is not fixed yet.

Idem with 2.6.14-1.1656_FC4 and up to date packages : this appears 'sometimes',
but it seems to me that it happens more often that before (difficult to say
because quite random) : roughly every 2 / 4 boot.

Problem also appears with kernel 2.6.15-1.1833_FC4 (also random).