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: > > http://wiki.linuxfromscratch.org/lfs/changeset/8315 > > 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. > > http://www.linuxfromscratch.org/blfs/view/svn/basicnet/net-tools.html > 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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
