Can't start from RAM disk image

["Dr. Daniel Löb"]

Hello Thomas,

I've found a workaround, in the process identifying a likely cause of
the problem.

On a hunch, I created a bootable Etherboot USB stick, as described here:

http://etherboot.org/wiki/removable

Usually, this is done for systems with a network adapter that doesn't
have pxe capability, but in my case it also worked. This indicates that
the onboard implementation of pxe/ftp is somehow broken on my computer.

Now I get my root prompt and can continue forward. I will of course have
to use that USB stick for installs, but for my handfull of machines,
this is not really a problem.

As for what gave me the hunch that something wasn't right with the
onboard software: The computers I use were former office PCs of a big
insurance company. Even before booting, they had the name of that
insurance company plastered all over them, indicating that they had
meddled with the bios/firmware...

Best regards,
Daniel

On 07/16/2014 05:53 PM, "Dr. Daniel Löb" wrote:
> On 07/16/2014 03:53 PM, Thomas Lange wrote:
>>>>>>> On Wed, 16 Jul 2014 12:20:40 +0200, "Dr. Daniel Löb" <daniel at sardisverlag.de> said:
>>     > When I boot the target machine after that, it _should_ start fai but then drop into a root at none prompt. What it instead does is to show these two messages:
>>     >     Received 001a Kbyte, sorted 001a Kbyte, invoked primary bootstrap
>>     >     C6e: can't start from RAM disk image
>> Mmm. I'm not sure when it drops into the prompt. Do you see the red
>> ascii text? Or does it drop into the rescue shell of the initrd?
>> I never saw this error message.
> Oh, it doesn't drop to the prompt. The Wiki said that it should drop
> to the prompt if FAI is working (without having the target system
> config properly set up).
>
> Instead, the error message appears and then the system immediately
> boots from the next boot option (Hard Disk).
>> You can enable debugging the initrd by adding rd.debug=1 to the kernel
>> command line.
>>
> I tried it again with
>> fai-chboot -FIv -k rd.debug=1 joffrey
> unfortunately, the result is the same. System shows the error message,
> then proceeds to boot from disk.
>
> I've also activated the --verbose option of tftp on the server and it
> gives this output in the logs
>> Jul 16 17:39:13 varys in.tftpd[8111]: RRQ from 192.168.28.3 filename
>> pxelinux.0
> So it seems that something weird is happening on the target machine,
> before/while the kernel is loaded...
>
>
> My Google searches showed that this problem has appeared every now and
> then in the last 10 years for people trying to boot over pxe. Somewhat
> dishearteningly, not a single one of the people asking questions about
> it on forums managed to get it fixed...
>
> I'm grateful for any further suggestions.
>
> Best regards,
> Daniel
>
> --

-- 
*Dr. Daniel Löb*:
Geschäftsführer Sardis Verlag UG (haftungsbeschränkt).
<http://www.sardisverlag.de>
Tel:: +4916091236780 <callto:+4916091236780>
Web: www.sardisverlag.de <http://www.sardisverlag.de>

Sardis Verlag UG (haftungsbeschränkt)
Alexanderstraße 9
64732 Bad König

Telefon: +4916091236780
Registergericht:  Amtsgericht Darmstadt
Registernummer:  HRB 93023
Ust-ID:  DE293817909

Verantwortlicher i.S.d. § 55 Abs. 2 RStV: Dr. Daniel Löb,
Alexanderstraße 9 64732 Bad König
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20140716/ff80c940/attachment.html>