Find the answer to your Linux question:
Results 1 to 2 of 2
Built a vanilla kernel (2.6.29.3) and cannot get it to fully boot. All the output hurtles up the screen and by the time it all stops the original problem has ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Apr 2009
    Location
    South East England
    Posts
    40

    Question Trying to debug boot problem - any ideas?


    Built a vanilla kernel (2.6.29.3) and cannot get it to fully boot. All the output hurtles up the screen and by the time it all stops the original problem has disappeared off the top. But the errors I can still see are all about being unable to access the hard drive file systems.

    I've managed to debug up to a point, by putting a debug printk into the kernel startup, followed by a while(1){ssleep(1)} ... moving this around lets me trace where it gets to, and stops further startup messages from pushing mine off the screen.

    It gets through start_kernel() fine and then into rest_init(), where it then fires up kernel_init() into another thread. kernel_init() runs fine then drops into init_post(). I can trace to the point in init_post() where it does ramdisk_execute_command("/init"), whereupon it then does lots of other stuff I cannot find the source code for. It must be successfully invoking the init daemon from the RAM drive, because something is doing an awful lot of complaining, and it doesn't run anything more in init_post() so it must be the daemon doing it. But from this point on my debug is no use ~ stacks of messages from init pushing all the useful info off-screen.

    So what I really want to do is find some source code I can put more debug into, either the init daemon itself or some of the code it calls into. If I could get one of my while loops into this code I might then get to see the original error message!

    Because the normal file system is not up and running nothing gets logged. And for the same reason I cannot drop into bash so far as I can tell ... all very frustrating. I tried to find a way of doing a directory listing for the RAM drive, but not sure how to do this in the kernel ~ don't seem to have access to things like opendir, readdir, etc. Would be nice to see what is actually on the RAM drive.

    All my kernel was built fully from scratch, with the config based on the original distro one. The modules are all built separate from the distro and the initrd based on all the 2.6.29.3 build. I've got separate kernel images and separate initrd images from my distro kernel so all is segregated. So I just keep rebooting alternately between them, the good distro one to edit and forage around in, and my vanilla one to debug in and cuss at!

    If I could just get to the source code at the point where things start to fall over I could get a chance to see what the initial error is ... and maybe put in some debug to find out a bit more.

    Help please!

  2. #2
    Just Joined!
    Join Date
    Apr 2009
    Location
    South East England
    Posts
    40
    I think I must have bored you all!

    I've got it to boot now, albeit still with a few much less serious errors. Turned out the 'splash' command in the RAM drive's init script was causing lots of knock-on issues. Though it takes a few seconds to write it took a lot of time to track it down! Having patched it out the boot process now runs all the way through and lets me log in. Progress. Why a 'splash' error could cause so much subsequent file system problems is still a mystery to me.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •