Netboot: kernel panic no init found

Graham Leggett minfrin at sharp.fm
Tue Oct 12 17:56:53 UTC 2004


C. Linus Hicks wrote:

> I think you mis-understand the initrd.img file. From the initrd man
> page:
> 
> BOOT-UP OPERATION
>        When booting up with initrd, the system boots as follows:
> 
>          1.  The  boot  loader  loads  the  kernel  program   and
>          /dev/initrd's contents into memory.
> 
>          2. On kernel startup, the kernel uncompresses and copies
>          the contents  of  the  device  /dev/initrd  onto  device
>          /dev/ram0 and then frees the memory used by /dev/initrd.
> 
> It continues from there, but the point is that when you mount a ram
> disk, it doesn't associate a pre-existing filesystem with it. The mount
> gives you a brand new empty memory filesystem. The procedure as
> described above adds the steps of uncompressing the initrd image, then
> copying it onto the newly created ram disk.
> 
> You can verify its contents by doing something similar:
> 
> 1. Copy your initrd to /tmp.
> 2. Rename it to include the .gz extension.
> 3. gunzip it.
> 4. mount it:  mount <unzipped img file> <some mount point> -o loop

I figured out the problem of seeing the contents of the initrd - it 
seems that mount is quite happy to accept a gzipped ramdisk, it just 
displays that disk as empty. I had to manually uncompress the disk and 
mount it a second time before I could see the contents of the disk.

None of this solves my original problem though, which is that netboot 
doesn't work. I have confirmed that a file called "disklessrc" is 
present in the root of the initrd, and I have confirmed that the 
init=disklessrc is apparently being passed to the kernel, but it would 
seem that the kernel does not agree.

Is there a way to convince the kernel to print out the command line that 
it has received? I strongly suspect the command line it is supposed to 
receive, and the command line it is actually seeing are two very 
different things, thus the problem.

Regards,
Graham
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3220 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20041012/75bfaf2f/attachment-0001.bin>


More information about the fedora-list mailing list