startup problem: system boots, /etc/rc.d/init.d/sysklogd "hangs": is there a good way to debug this?
support at cslimits.net
Thu Sep 6 11:43:41 PDT 2007
Hi, Dan -
> ... I'd had no-boot errors twice because of typos in fstab which were
> silent because of that. Booting still failed, but at least I got to see
> the error being thrown by fsck. Here's the change:
> Does that make a difference in your case?
Maybe... unfortunately, it's difficult to do much more than catch a glimpse
of much of anything at that point; everything's flying by at top speed. I
did a little experimentation and put some output stmts in that script; I
knew they were there and I had a hard time seeing them.
I might have caught it if I'd had "boot_delay" turned on <and> been using
your newer script code; one of the collection of kernel patches I/we have
includes one which adds a kernel param "boot_delay=N" where N is the #
milliseconds to wait between messages.
Having "mountfs" complain (very) loudly about it wouldn't be a bad idea
either, though at this point, I'm thinking about a "pre-flight checklist"
sort of utility - something like SAMBA's "testparm" only system-wide; it's
not the first time I've gotten myself w typos, flat-out forgot altogether to
create this or that file, etc.
>> I used rc2 of the 6.3 version of the book; looks like a number of things
>> changed between then and "release level"... For one, I noticed that
>> ifconfig was on the live CD (rc2 is still using "ip" to do everything).
>> While I don't mind "ip", I'm tempted to use ifconfig from the standpoint of
> Not too much changed between rc2 and the final edition, but you may be
> interested in grabbing the final bootscripts and udev-config tarballs.
> BTW, what you see on the LiveCD is LFS + lots of extras determined by
> the LiveCD team. If you prefer ifconfig, you can always build
> net-tools from BLFS.
That makes more sense now. I had thought the build on the Live CD was
pretty much what the book would end up producing less X, but that's fine;
I'm actually happier that it doesn't: while the rationale for this excercise
is multi-fold; part of it has everything to do with being completely sick of
having to scrape off what RedHat (et al.) decided I should have installed.
Debian is better in that regard, but one has to learn Debian's design. I
would rather put that same time into learning my own, but lacked anything
even remotely resembling a design document. I was starting to put one
together, ran into LFS in the process, decided to give it a try, and, here
I'm definitely going to grab the final bootscripts && udev config files
> The builtin network services will still use ip, but you can use
> ifconfig interactively or whatever. I think most people keep ifconfig
> around for comfort's sake. I do, although I'm starting to get used to
> the ip usage.
Yeah, that's pretty much the way it is here, too. When I said "consistent"
I meant more "consistent with the way ifconfig and the rest of the net-tools
package behaves (or doesn't)", not just "consistent w ifconfig" - which
really isn't all that consistent from one net-tools version to another in a
number of nasty, subtle little ways - but that's another story.
Personally, I'd much rather switch everything over to iproute2; it tends to
"just work". Unfortunately, RedHat and Debian et al. have been dragging
their heels in that regard (though Debian does, at least, have an iproute2
package available, if you know enough to use it instead of net-tools). The
unfortunate fact of the matter is that a large number of scripts in RedHat /
Fedora would break; there's no layer of abstraction between the tools and
Thanks for the info & for getting back to me so quickly, I really appreciate
it. Excellent job on the book, too.
Where would I look w/ respect to volunteering to help make future versions
of LFS a reality?
More information about the lfs-support