486er hangs on boot with iPXE floppy

[His_Cifnes]

Dear community,

I have restored my 486 DX2-66 MHz machine utilising 24 MB of RAM to work perfectly fine again, like back then.

Now I've came to the idea, why not use it's capabilities to forensically restore floppy disks, specifically reading from 5,25" and 3,5" drives saving stuff to a NAS.
Also for creating images of internal drives it would be nice to have something similar to dd or partimage.

Very nice, you may think.. boot off a 32bit CD and be a happy man. - Unfortunately the BIOS does only offer the boot options "A, C" and "C, A", which kind of limits my options to booting off a floppy disk.

I've tried SuSE 6.0, as I had this flying around still, and it works.. but not as good as it could. It is also a security risk to have such a thing running on the network, as there are no updates anymore.
For any newer version the kernel was too big to fit on a 1,445 MB floppy, and therefore I needed to dig deeper: Slackware Linux has the same problem... reasonable version numbers have a wayyy too big kernel to boot from a 3,5" floppy.. but the Slackware guys had a nice idea.. why not use PXE? - Just go ahead and write a floppy, boot from a network stored image, and magic surrounds the whole thing.

In theory this should have worked, BUT.. for starters the 486er boots quite nicely from the floppy disk showing:

Quote:Loading ROM image...................................

... but then freezes and never goes any further. - What might that be?
I have tried this floppy on all the other machines here and at work that have 3,5" floppy disk support.. and it works on all the other machines, even on VirtualBox, but not on the target machine..

Any ideas?

[NiKiZe]

I would just create a HDD image instead and boot via iSCSI, even use a virtual machine to populate that image in the first place.

[His_Cifnes]

NiKiZe, thanks for your quick reply.
Unfortunately I cannot boot from anything but drive A: or C: as the BIOS does not allow anything but that, and I do not have any IO-cards which could change this. :/ (yet..)

I cannot create "online" images. The only way would be to take out the hard drive and image the stuff "offline".

But, instead of this I would like to use the to-be-installed linux as two things:
1) to image floppies and other partitions (but this very linux) on the hard drive
2) to simply use it and see how far a 486er with 24 MB of RAM can be helpful with *a current* 32bit distribution of today and up-to-date packets.


Also the iPXE-boot-from-any-image thingy could be useful in general. Thinking of testing this further with more up2date machines, but still.. I do not get why the boot floppy hangs with that 486er, while it works on every other machine. Weird. What could that be?
Too few RAM maybe (24 MB), or problems when probing the hardware? Is there a way to debug this problem?

[NiKiZe]

You can still boot iPXE? how do you do that? once iPXE have booted it is in control of if iSCSI should be used and iSCSI will become "C:" or drive 0x80 (meaning first harddrive)

You would create a disk image, on a virtual machine that runs on a different PC.

What is your current iPXE script for loading that ... or if the above is from booting a floppy with iPXE, how did you create that floppy (sorry maybe i jumped to conclusion on that you already had iPXE running, but it wasn't very clear from your original post)

[His_Cifnes]

Sorry, I might have not been precise enough.

--> Yes I DO have a floppy with iPXE, that boots on any machine BUT that 486er.

--> the floppy hangs up the 486er after that "Loading ROM image....." message after POST
No scripts running yet at that point. I might do a screeny if you need to know where it hangs!


> What is your current iPXE script for loading that

none yet


> if the above is from booting a floppy with iPXE, how did you create that floppy

The linux distribution CentOS comes with a set of iPXE images for floppies, CDs, USB-sticks and so on. You may download these images if you like. So I did.
Creating the floppy disk was rather easy:

Quote:dd if=image-file of=/dev/fd0

tested on quite a few machines, where it worked. Also VirtualBox ran a test with that very image, and could boot from it.

First of all they all showed the usual:

Quote:Loading ROM image..... (with growing number of dots)

On the 486er after quite a few dots were added, the machine simply hangs up and nothing happens any further. A hard reset via button is required afterwards. CTRL + ALT + DEL does not reboot.

On any other machine, after this Loading ROM image with growing number of dots, the iPXE menu appears. (as it should be)

[MultimediaMan]

What kind of a NIC is in the 486er? You ~need~ a PCI NIC of some kind... preferably an Intel Pro100/1000. I'm pretty sure an ISA NIC or an EISA NIC isn't going to cut it.

[His_Cifnes]

MultimediaMan, NIC is a RTL8139 PCI.
This is quite a common card. Should be supported :o

[MultimediaMan]

The Realteks can be dodgy (especially some of "counterfeit" cards). I would try a different card.

[His_Cifnes]

Oho! Didn't know! I'll try this out tomorrow. Lending an old PCI card from @work.. ; )
Remembering correctly, there should be an Intel Pro1000 card also..

Thanks for the input! : ) - I'll let you know what happened with this card.

[NiKiZe]

MultimediaMan: There is NE2000 drivers as well, but I think those needs to be built separately since there is no autodetection for them so can't be included in the normal ipxe binary.

If you are having issues with getting iPXE to run, then it might be easier to concentrate on that, no need to mention and risk confusing with the other stuff.

I would never use prebuilt version of iPXE from any distro since you never know how it was built which for one makes it harder to debug, also it is often just to old.

Please build the ipxe.fd image

Code:

make bin/ipxe.dsk

from sources yourself.
You can find latest prebuilt one at http://boot.ipxe.org/

Unfortunately I can confirm that this does not work on 486 with this:

Code:

qemu-system-x86_64 -cpu 486 -m 24 -fda bin/ipxe.dsk

To fix this edit src/config/local/general.h and add this

Code:

#undef TIVOLI_VMM_WORKAROUND

now you can build the latest version, and it will work on machines without MMX instructions, such as the 486.

---

Below is just technical details on how I found this

After running git bisect between current master and an old version that I found working:

Quote:71560d185475117b10994d839afe059577e7768c is the first bad commit
Author: Michael Brown <mcb30@ipxe.org>
Date: Wed Apr 27 11:03:18 2016 +0100

[librm] Preserve FPU, MMX and SSE state across calls to virt_call()

So to get a working build for 486, this works:

Code:

git clone git://git.ipxe.org/ipxe.git
cd git
git checkout fe62f3c831
cd src
make bin/ipxe.dsk

Later TIVOLI_VMM_WORKAROUND was implemented to revert this behavior so that is the better way get it working on older CPUs

[His_Cifnes]

Getting interesting.

First of all, I swapped the RTL8139 NIC with an Intel Pro1000 Desktop Adapter PCI, but usual problem... hangs up with the prebuilt floppy image. --> So, not the card's fault as it appears.
Next, I did this:

1) installed git on a x86_64 machine with Linux Mint (up2date)
2) got the sources in the way NiKiZe recommended, via "git clone git://git.ipxe.org/ipxe.git"
3) created the src/config/local/general.h and wrote "#undef TIVOLI_VMM_WORKAROUND" in there, saved the file
4) cd'ed to src and ran " make bin/ipxe.dsk"

Unfortunately resultin in a compile error:

Code:

[............ lots and lots of DEPs and BUILD lines until.......]
  [BUILD] bin/undi.ids.o
  [BUILD] bin/rtl8185.ids.o
  [BUILD] bin/rtl8180.ids.o
  [BUILD] bin/ath5k.ids.o
  [BUILD] bin/ath9k.ids.o
  [AR] bin/blib.a
ar: Creating bin/blib.a
  [HOSTCC] util/zbin
util/zbin.c:7:18: fatal error: lzma.h: File or Directory not found
compilation terminated.
Makefile.housekeeping:1373: no rule for target „util/zbin“ failed
make: *** [util/zbin] Error 1

There is indeed no lzma.h in the whole git download, that I did. What I am doing wrong?

---

okay.. found out myself.. typical for noobs like me.. ; ) --> Installed lzma dev package... and g++ went through nicely.

Now testing the new image..

---

Nope.. no change.

486er still hangs at "Loading ROM image............................." but before "Initialising devices..."
amd athlon machine works fine with the shortly created disk image.

--> Are there some debug flags to compile in, to see what stage the booting fails?

[NiKiZe]

(2017-12-28 19:27)His_Cifnes Wrote:  First of all, I swapped the RTL8139 NIC with an Intel Pro1000 Desktop Adapter PCI, but usual problem... hangs up with the prebuilt floppy image. --> So, not the card's fault as it appears.

Extremely unlikely in the first place, but if you want to be sure it is not NIC related, pull it out and don't have any NIC in the machine and make sure iPXE boots to prompt even if it won't have any network. (after we know that to be working you can pop whatever nic back in)

(2017-12-28 19:27)His_Cifnes Wrote:  486er still hangs at "Loading ROM image............................." but before "Initialising devices..."
amd athlon machine works fine with the shortly created disk image.

--> Are there some debug flags to compile in, to see what stage the booting fails?

I need to ask 486er? there is no er on any 486 model AFAIK so what do you actually mean?

Are you sure you dd the correct file "ipxe/src/bin/ipxe.dsk" to the floppy before booting? if you boot that floppy on some other machine, what do you see in the iPXE header? Something like "iPXE 1.0.0+ (be9e) -- Open Source ..." the version (be9e in this case latest version right now) is which git commit it was built from, plase post that number that you are seeing, that way we can make sure it is the latest code.

[His_Cifnes]

Yup, absolutely sure. Yes, exactly that one.
I've got the terminal open, still. Copied and pasted here:

Code:

ipxe/src $ make bin/ipxe.dsk
  [... lots of stuff successfully compiling ...]
  [AR] bin/blib.a
ar: Erzeugen von bin/blib.a
  [HOSTCC] util/zbin
  [VERSION] bin/version.ipxe.dsk.o
  [LD] bin/ipxe.dsk.tmp
  [BIN] bin/ipxe.dsk.bin
  [ZINFO] bin/ipxe.dsk.zinfo
  [ZBIN] bin/ipxe.dsk.zbin
  [FINISH] bin/ipxe.dsk
rm bin/version.ipxe.dsk.o bin/ipxe.dsk.zinfo bin/ipxe.dsk.zbin bin/ipxe.dsk.bin

ipxe/src $ cd bin/

ipxe/src/bin $ ls ipxe.dsk
ipxe.dsk

ipxe/src/bin $ dd if=ipxe.dsk of=/dev/fd0

Oki, booted the floppy again on the athlon machine, that can successfully boot from this floppy disk.
The output is:

Code:

Loading ROM image.................................
iPXE 1.0.0+ (be9e) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: DNS HTTP iSCSI TFTP SRP AoE ELF MBOOT PXE bzImage Menu PXEXT

net0: <some specific ipv6-addy here> using rtl8139 (yeah this machine also has such a card.. so not a problem) on 0000:03:01.0 (open)
[Link up, TX:0 TXE:0 RX:0 RXE:0]
Configuring (net0 <same ipv6-addy as above>).....

The 486er shows the usual:

Code:

Loading ROM image.................................
(hangs and needs a hard reset)

[His_Cifnes]

Mhmhm.. is it possible that 24 MB of RAM is not enough to run iPXe?

[NiKiZe]

(2018-01-04 00:23)His_Cifnes Wrote:  Mhmhm.. is it possible that 24 MB of RAM is not enough to run iPXe?

Above I mentioned qemu which was used to test a virtual machine with 486 CPU and 24MB memory.... testing again with 4MB works fine as well ... but with only 2MB of RAM the virtual machine just reboots after "Loading ROM image ... "

If I reduce iPXEs size by building intel.dsk (which only has Intel drivers instead of "all" drivers) then it works fine with only 2MB as well.

Anyway, RAM size is not the issue here, but there is a multitude of possible reasons, to many to mention them all

But, have you run memtest86+ on the machine to make sure it don't have any faulty ram?

Since the issue you are having is in the loader code itself I'm not sure what, if any, debug methods are available.

You might also try some older version of iPXE for example checking out the old 1.0.0 tag and see if that behaves differently (if it at all compiles that is)

Sorry not being able to help much more on this.

[His_Cifnes]

I will memtest the machine with the current version of memtest86+ - Let's hope it's not the RAM... :o

[His_Cifnes]

NiKiZe, I did memtest the machine with memtest+ 2.0

Newer versions of memtest+ made the machine crash immediately when booted.
The old version though ran through nicely 3 times in a row without an error.

So, I suspect it's not the RAM.