booting 7.4: it skips rc S and goes directly to runlevel 3
I tried to boot lfs-7.4 for the first time. It boots the kernel, and when it's time to hand over to initscripts it's like it skips 'rc S' and goes directly to 'rc 3'.
I have run diff on all files in /etc/init.d, and the only difference between lfs-7.3 and lfs-7.4 are small differences in mountfs and mountvirtfs. I copied those from 7.3 to test with the exact same scripts, but no difference. /etc/inittab is also the exact same. Here are the links in /etc/rc.d/rcS.d Code:
/media/lfs-7.4-test/etc/rc.d/rcS.d Code:
/media/lfs-7.4-test/etc/rc.d/init.d Code:
id:3:initdefault: I have no bootlog, because the rootfs was mounted readonly (it should be remounted in the scripts that were skipped). The messages from the kernel looked normal. "...used greatest stack..." I think that was the last line from the kernel, and then it said initscript and I think it showed what version it was. Where it was supposed to say "mounted /run /proc /sys" instead it said entering "runlevel 3", and then stopped with an error because sda7 (the root-partition) was mounted readonly. sda7 is the correct partition. Does anyone have any idea about what could be causing this? It must be a stupid mistake I did somewhere, because the initscripts are the exact same as the ones working fine in 7.3... |
Just have to ask but did you follow the book EXACTLY during Chapter 7 setting up the boot scripts, directory permissions, and did you attempt any level of customization during the initial compile and setup of your LFS system?
Attempts to customize LFS at all tend to really hurt the system, and, really, if you don't follow the book(s) exactly, you'll often, but not always, end up getting something screwed up, which I did on one of my first build attempts. As for why it did that? Unless you did any customizations, LFS, by itself, is a rather raw GNU/Linux distribution with very little, so chances are it might have been a customization or an issue with LFS itself. I've had no issues with this myself and my system boots fine. You MAY want to look into expanding LFS using Beyond Linux from Scratch, especially using (at least) Chapter 3 of BLFS-7.4. Chapter 3 will really clear up a lot of left-over mundane stuff, as well as give a raw LFS some personality. |
Of course I've deviated from the book, otherwise there wouldn't be any breakages... ;) I used the same build script that I used for 7.3, updated to the versions in 7.4, and some of them with a few other adjustments. I build packages with pacman, and try different ways to have the install script doing some stuff that can't be put in the packages. But I didn't add any patches or other changes to the actual building of the lfs packages.
I went through chapter 7 when it failed to boot, and made sure those files exist, and are correct. I ran diff on those relevant for early boot, and they are the same as in 7.3. I have for quite long thought about writing my own initscripts, because I don't like the symlinks and I think the rc file is a mess to follow what it does. I wrote my own initscipts in Slackware, but I don't like how the output look because I didn't know then how to make the colorful output for OK in green or FAIL in red. I think I have learned enough about bash scripting to make it now. If I could just stop being lazy... But it disturbs me that it doesn't work with the initscripts from LFS. It's a sign of something being wrong, and I want to sort it out even if I write my own initscripts. I checked the log from building sysvinit, and I can't see anything wrong there. No errors, nothing that looks strange. The "error" must be very early. /sbin/init should read /etc/inittab, and there it clearly says it should start with 'rc S'. The file rc is the exact same as the one in 7.3, and all other scripts come later. I couldn't see anything wrong with the output from booting the kernel. Maybe recompiling sysvinit and see if it makes a difference. |
I found it. I put a lot of echo in the rc scripts, to see how far it came. Where it uses ls (redirected to /dev/null) to find the symlinks for the runlevel that should be started, I showed the output from ls. It couldn't find a shared library...
I recompiled coreutils after I installed acl, but then ls/coreutils became dependent on libcap, which was not installed in my test-system. So I installed it, and then it booted to normal login-prompt. With a few exciting 'FAIL's, of cource, but that was kind of expected... :cool: |
All times are GMT -5. The time now is 04:36 PM. |