Eric Lucas on 22 Feb 2013 07:17:09 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Panic (kernel that is)


On Wed, Feb 20, 2013 at 11:15 AM, Rich Freeman <r-plug@thefreemanclan.net> wrote:
On Wed, Feb 20, 2013 at 10:53 AM, Eric Lucas <eric@lucii.org> wrote:
>
> On Wed, Feb 20, 2013 at 10:15 AM, Rich Freeman <r-plug@thefreemanclan.net>
> wrote:
> What I don't see is a file called init.  There is a soft link for init that
> points to sbin/init but that's broken - the target does not exist.  So how
> does it know what to do?

I couldn't find a doc on the search path for init.  It should find
/sbin/init, so if that exists and is something that can be executed
(including a script with #!) then it will be run.

>
> Based on the messages I see on the frozen screen the problem is with trying
> to mount the RAID drives.  There are a lot of messages that go by before the
> panic and I have to believe that it must be running from the ram disk at
> that point.  Even so, this system should continue to run out of the ram disk
> - it's a rescue disk after all.  In my normal scenario I expect there to be
> two blank hard drives in there.

Sounds like it is running your RAM disk, though the kernel can
potentially try to automount the RAID before the initrd runs.  I
/think/ the behavior is that the kernel will try to autodetect RAID if
you're booting from an initrd, but not if you're booting from an
initramfs (can you tell I've had initramfs RAID-detection issues
myself).

As far as what happens when things go wrong - if the initrd is
actually running then that is up to the initrd.  If it has good error
detection/handling it could drop you to a shell.  If not it might try
to do something that causes a panic/etc.  Some initrds (including
dracut) make this behavior configurable - for security reasons you
might not want to offer a shell.

If you can scrollback the ring buffer you should be able to tell when
the initrd is booted.

One of the last things output by the kernel before loading an
initrd/initramfs is:
[    3.247932] Freeing unused kernel memory: 572k freed
[    3.248300] Write protecting the kernel read-only data: 10240k
[    3.255536] Freeing unused kernel memory: 684k freed
[    3.259153] Freeing unused kernel memory: 1268k freed
(or something to that effect)

The initrd is all userspace - as far as the kernel is concerned the
system IS booted when it runs.  It is just another kind of root
filesystem.  So, if you see a message about freeing kernel memory/etc
followed by a lot of additional output that is a sign that your initrd
is booted (and the additional output is coming from it).  If you don't
get that message, or it happen just before the panic that is a sign
that the initrd isn't really getting a chance to do anything (or the
initrd is really quiet).

Your other option is to force the initrd to echo something to the
console early-on, but that will require you to extract and re-assemble
it.  Not super-hard, but squashfs is a read-only filesystem so you
basically need to extract/modify/rebuild it.  The initrd filesystem
itself doesn't contain anything magic (like boot sectors/etc) - if you
can compress it linux will boot it.

Rich

Rich.  

I received an email from the mondo-devel list... it turns out that I had the 
package mindi-busybox 2.7 when I should have been using 2.18.

I Installed 2.18 and the resulting disk booted normally.  

Thanks again.
Eric
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug