startup problem: system boots, /etc/rc.d/init.d/sysklogd "hangs": is there a good way to debug this?

support support at
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
>> consistency...
> 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 
we are. 

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 
the scripts. 

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? 

 - Larry

More information about the lfs-support mailing list