System Doesn't Boot Part 2
molbert at iterobiopharm.com
Sat Jan 26 17:09:07 PST 2008
One additional thing I noticed: if I do a ls -l /dev at the end of the LFS udev script, neither console nor null appear; they're not listed as devices.
I don't know if this is because they're not in the ramfs that's mounted on top of /dev when udev runs, or if it's related to the problem I'm experiencing, but I thought I'd pass it along because it looked odd to me.
----- Original Message ----
From: Ken Moffat <ken at linuxfromscratch.org>
To: LFS Support List <lfs-support at linuxfromscratch.org>
Sent: Saturday, January 26, 2008 3:39:07 PM
Subject: Re: System Doesn't Boot Part 2
On Sat, Jan 26, 2008 at 03:08:18PM -0800, Mark Olbert wrote:
> Some additional info:
> I checked the logs after the last failed/hanging boot, and the system
log shows most, if not all, of the shell scripts executing (I can tell
by the messages they log).
> But I never get a login prompt on the screen, and it looks like the
> I did notice one oddity in the log file, however. init complains
about not being able to open /dev/console. Why that should be I don't know,
as I never deleted it. The log also contains messages about init (or
some process related to it) spawning too fast, etc.
Hmm, /dev/console looks key to this. At least until recently,
/dev/console and /dev/null had to be the real device nodes (with
recent udev, there might be copies in /lib/udev, I don't remember,
and it's not relevant for you). I hit this myself when I restore
from backups, or when I copy a system to a different place to fit a
You say you haven't changed this, and in a running system we mount
/dev _on_top_of_ these minimal devices, which should protect them.
Anyway, from your "emergency" slackware system take a look at the LFS
/dev/null and /dev/console with 'ls -l'. Do they exist, and if so
are they the correct device special nodes, with the correct
I do wonder if you either ran fsck during the failed boot that
started this, and it found damage and deleted files, or if there is
other damage on the disk. This all sounds worrying, nearly as
worrying as somebody using such an old system (yes, I know there can
be persuasive reasons to use an old system, but it isn't the comon
case - distros provide updates, and migation paths at end of life,
we have to handle that for ourselves).
das eine Mal als Tragödie, das andere Mal als Farce
Unsubscribe: See the above information page
More information about the lfs-support