On Sun, Sep 25, 2011 at 09:32:04PM -0400, scrat wrote: hmm, I didn't intend to still be awake at this time, really I didn't, but I'm nursing my current dekstop build scripts :-( > > This is a five year old lapdog machine so it is not to beastky fast ;) > That is odd, because the log timestamp you quoted was something like 1.4 seconds after the kernel had started to boot.
> > Somebody implied a video problem - that sounds plausible. > > No I don't get a blank/black screen I just get a hard crash, the screen > never clears or blanks > Next time you boot the host system, watch the messages to see what comes next in a successful boot. > > > > You were also advised to avoid modules - in fact, for some things > > such as network adaptors (wired ethernet) modules are usually no > > problem. The big issues are booting without an initrd (most distros > > use intirds, LFS doesn't), and supporting your hardware - as well as > > the obvious "build in ext4 or whatever you use" and "enable the > > correct [ SATA ] drivers(s) for your chipset(s)" I suppose we should > > add "if in doubt, keep the video simple". > > I did use a kernel without modules. I recompiled the kernel without > modules as suggested. > Sounds good > > > > kms is a wonderful thing when it works, but a bit of a beast to set > > up in some situations, and occasionally liable to break across > > kernel upgrades on some hardware (particularly, intel). So, if you > > are using it, I suggest that you build an alternative kernel without > > it, and use that to help identify where your problem lies. Equally, > > even just using a framebuffer might cause problems (on my new > > server, I had to fiddle with grub.conf to get a non-blank screen, > > and I eventually switched to, I think, vesdafb from radeonfb - on > > earlier kernels with my previosu hardware, the framebuffer had worked > > fine without specifying anything odd to grub). > > I am not doing anything to advanced as of now. I just want to see the > machine boot. > I'll mess up the kernel by adding sound kms etc later.... > First get it to boot then on to blfs and add/chqange the kernel params > as needed to get things functional is/was my plan. > Sounds good. > > > > I think you said that you had used this config already on your host > > system ? If so, is the host using an initrd [ if it is, the config > > is probably not adequate for LFS ], and did you use the same version > > of the kernel ? Occasionally, things break in newer kernels [ hmm - > > if you are already running a *newer* kernel on the host, use the > > same version in the new system, don't go back to an older kernel > > just because it is in the book ]. > > No, I did not use a config from a distro, I made the config file from > my own doing.....(That's why it didn't work I suppose?) > > I did a mrproper > Then make deflaultconfig or something like that > Then make menuconfig and looked over the config and eliminated a bunch > of stuff and added the proper sata drivers etc. > I have no framebuffer or kms configured in the kernel. > I then compiled a kernel that booted. > > After which I changed the hard drive in the laptop ( the machine I built > the system on ) and then re-done the LFS as a new build. > When I got the the reboot stage it hung. > I'm lost here (probably because it is late) - you've used the same host to build LFS twice, first on the old disk, and then on the new disk ? > I used the same host system and the same partition system on both hard > drives. > I also scripted the first system and copied it to a usb thumb drive to > use again. > After setting up the new drive I used the scripts following the build > sequence to install on the newer/larger drive. > I have to manually do each step following the book. I built the scripts > by cutting and pasting each chapter into a script and adding a section > to untarball the source package and cd to the now source directory > Each script resides into a subdirectory. > > The script when run unpacks the tarball cd to the unpacked directoty > and runs the pasted commands. The above sounds sensible, but the reality is that scripting makes it very easy to miss errors. OTOH, if you are manually running each step, any errors ought to be apparent to you. > > What I don't know is when does the kernel hand over booting to inittab etc. > > My theory if not flawed is that some/all binaries are linked to the > /tools directory, and since /tools has beened removed it hangs. > Although I could be completely wrong about this. > > It should be simple for you to test this theory - take a program from each package (starting with /sbin/init) and use ldd to see what it links to. If the program you picked turns out to be a shell script, try a different program from the same package (see chapter 6, I think, for what gets installed in each package ? - I don't have a graphical browser on my current desktop). If /sbin/init is linked to /tools, I would expect to see a meaningful error message, but who knows. If /sbin/init is NOT linked to /tools, then this appears to be a kernel config problem. If /bin/bash is linked correctly, you can also try booting with init=/bin/bash, although it won't give you a nice environment and is normally reserved for stepping through the init scripts if things have broken. Good luck! ken [ hmm, I hate the "minimal american" keymap I get with fluxbox, but at least it's good enough to let me run X and build a sensible wm - call me grumpy! ] -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
