mirror of
https://github.com/oerg866/win98-quickinstall.git
synced 2026-04-25 21:15:52 +03:00
[GH-ISSUE #33] Support for installation via netboot #33
Labels
No labels
bug
documentation
enhancement
help wanted
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/win98-quickinstall#33
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ssokolow on GitHub (Apr 4, 2025).
Original GitHub issue: https://github.com/oerg866/win98-quickinstall/issues/33
Just a feature request for supporting installing via PXE net boot.
Many of my Windows 98-compatible retro PCs are actually thin clients (eg. HP t5530, HP t5710, Igel 3/2) that have been upgraded with bigger IDE DoMs or CF/SD card adapters (because I have limited room and they don't have noisy fans) and, even if I do have plenty of CD-RWs and DVD-RWs, it's still a hassle to dig out my USB DVD drive just for the install process.
Given that this is Linux based, it doesn't sound like it'd be too difficult for there to be a supported way to just add it to the PXELINUX-based "Apple Internet Restore, but for vintage PCs" boot menu that I already have chainloading various useful DOS and Windows boot disks.
(Gotta love turning "Hold F12 while powering on to net boot" into "Hold F12 while powering on to access recovery console".)
@ssokolow commented on GitHub (Apr 4, 2025):
UPDATE: Most of this is unnecessary unless you specifically want to test with real hardware. I found a blog post about how QEMU has internal support for emulating DHCP and TFTP for PXE booting.
On my system, all it took to emulate PXE boot from my "develop here, then rsync into place" folder at
~/src/tftpwas this command:...so, if that's good enough for you, all you need from what I wrote below is the stuff about what to put into the TFTP server.
If you want to set up a test environment, I have the following pieces of advice to avoid frustration:
If your goal is to test what happens after a successful PXE startup, don't get fixated on a specific client implementation.
My HP t5530 and t5710 thin clients Just Worked™ once I had a valid netboot setup, as did my ThinkPad T42 and T410, two HP laptops, and a Lenovo Ideapad, but Igel went out of their way to make their BIOS not give away that it was a BIOS unless you knew the secret handshake, I'm still trying to figure out why my Wyse Cx0 seems to find PXELINUX but then fail to boot it, and VirtualBox on Kubuntu 22.04 LTS (without the VirtualBox-breaking HWE kernel) seems determined to crash on finding a PXE server.
While I was unwilling to make the manual changes to the host machine's network config which are apparently necessary to get QEMU to see a PXE server on the same machine, this process claims to work for PXE-booting QEMU off a DHCP server on the same machine and Debugging PXE boot with QEMU is a blog post specifically about it.
Install
dhcpdumpto view what your NIC's boot ROM is saying to the DHCP server and what the server is replying with. This will save you so much frustration. (Here's an example of healthydhcpdumpoutput which produces that menu I snapped a picture of when net-booting my HP t5530 off my OPNsense router.)tftp-server-name(DHCP Option 66) sounds like what you want to set but, in my experience,next-server(A.K.A.siaddr) is what my PXE ROMs are checking for.(Note that, in the example dhcpdump output, the list under
OPTION: 55 ( 24) Parameter Request Listin theBOOTPREQUESTdoesn't mention Option 66, so theBOOTPREPLYdoesn't include it.)If you're using OPNsense with ISC DHCPv4 as your DHCP server, the fields you want to set are
Network booting > Set next-server IPandNetwork booting > Set default bios filename(where "default bios filename" means "boot file for BIOS-based machines, not UEFI-based ones") and there'sSome PXE implementations aren't fully compliant and ignore the
next-serverfield in favour of just assuming the TFTP server will be on the same machine as the DHCP server. If you're using OPNsense, see this tutorial: OPN as a PXE boot server that covers everything.If you want to use the PXELINUX menu support that I'm using (eg. as a test platform you know is built correctly), here are the PXELINUX and MENU pages of the syslinux Wiki.
The gist is that, for the
dhcpdumpresponse I attached, you set up this file structure inside your TFTP server using the binary files from the syslinux 6.03 distribution tarball (you can also get it through your distro package manager):Here's the
pxelinux.cfg/defaultwhich produces that menu I showed: defaultThey're all in a folder named
biosbecause they're all relative topxelinux.0, which is specified asFNAME: bios/pxelinux.0.in the dhcpdump'd response so they don't get intermingled with the stuff I'm doing for providing a PXE boot option for machines that boot in UEFI mode.I think that's everything I got stuck on while setting things up but, if you hit any rough patches, feel free to ask.
@oerg866 commented on GitHub (Apr 7, 2025):
I'll level with you here, I've had exactly one encounter with netboot a few years ago and it wasn't exactly pleasant...
So I have no idea how any of it works.
My immediate question is - will the kernel have to be built with network support or will it just magically find its files due to the BIOS module somehow?
@ssokolow commented on GitHub (Apr 7, 2025):
Perfectly fair. As evidenced by the advice I gave, getting to the point where PXELINUX is set up and working has quite a few pitfalls.
The gist, is:
It depends on what system requirements you want to impose on users.
PXE booting doesn't have a full-blown network disk mounting implementation in it but PXELINUX does have a ramdrive implementation and it is possible to just ask it to load an entire bootable CD-ROM into RAM and then chainload it if your netboot client has enough RAM for that... just probably not suitable for this use-case. (eg. The machines I run Windows 98 on often max out at 128MiB of RAM.)
Without that, the Linux kernel needs network drivers, just as it can't rely on the real-mode BIOS services to speak PATA or SATA for a local boot.
(I know the PXE option ROM provides an interface named UNDI, which allows a single DOS network driver to be written which works for any PXE-booted NIC, like the drivers here, but I don't know if Linux can use that or if it has the same problem as relying on BIOS services for local disk access.)
You could either have win98-quickinstall run entirely from the initial ramdisk except for the
--osrootdata (the approach that takes more RAM) and use the kernel's SMB/CIFS client tomount -t cifs ...the--osrootcontents from a Samba/Windows File Sharing share, or you could use the kernel NFS client to mount/itself over the network, retrieving everything except the kernel and potential initramdisk over NFS.In that latter case, the NFS share mounted at
/substitutes for everything except/boot/vmlinuzand/boot/initrd.img, which are the bits PXELINUX loaded over TFTP.I'll admit I haven't tried the NFS approach yet, but, if you're interested, I could look for a slot in my schedule to fit some experimentation into.
@oerg866 commented on GitHub (Apr 7, 2025):
Ah, I see. At the current time, this is a bit too much effort to implement
few things preventing me from doing this at the moment:
At the moment there's 2 kernel builds, one for floppy, one for CD with a
maximum size of 1.44 and 2.88mb respectively.
They are built without network support to save space, and enabling that
would probably blow way past that.
Initramfs is built into the kernel as of now and all the tooling for
networking would have to be included in that initramfs...
There's basically no libraries so all userspace code has to be built
statically and the peculiar build environment might be problematic (getting
the existing modules to work was hard) and could bloat the repository with
even more submodules...
I've heard of the possibility to mount filesystems via something called
iSCSI or so? Maybe I'm misremembering?
Hmmmm tricky topic... But it's definitely interesting 🤔
On Mon, Apr 7, 2025, 18:42 Stephan Sokolow @.***> wrote:
@ssokolow commented on GitHub (Apr 8, 2025):
That's fair. Depending on how things shake out for me, maybe I'll experiment with making a third kernel for netboot at some point.
PXELINUX only has a 2.88mb limitation if you're chainloading to another bootloader that needs floppy emulation.
Otherwise, PXELINUX itself and its ability to load arbitrarily large kernel and/or initramfs files over TFTP provides an experience more like GRUB when you don't need to remain compatible with early CD-booting tech (I actually don't know if it's the BIOSes or just the older bootloaders that need fake floppies) and are using genisoimage's
-no-emul-boot. The option to build the kernel with internal DHCP and NFS support to mount/replaces mounting the non-floppy-image portion of the CD.Theoretically, I should be able to mount the QuickInstall ISO, copy its contents to
/srv/win98-quickinstall, add that path as an NFS export, edit your kernel config to turn on these options and some network drivers and possibly remove any conflicting bits from your initramfs relating to mounting/......drop the resulting new kernel file at
/srv/tftp/bios/win98_quickinstall_kernel, and add something along these lines to my/srv/tftp/bios/pxelinux.cfg/default:Combining the QEMU command-line I already shared for using its internal netboot emulation with the answer here for how to mount an NFS share on the host as the emulated machine's root should allow the whole thing to be tested using QEMU on a single machine.
*nod* ...but, as mentioned, the kernel requires no additional userspace code to get an IP address over DHCP and then mount
/over NFS.The only concern is that part you mentioned about needing to not bloat out the existing CD and floppy boot images with network drivers.
Yes, but I've never used it and the relevant pros and cons for encapsulating SCSI in TCP/IP packets should be the same as using the kernel NFS client. (i.e. You still need a pile of network drivers)
@oerg866 commented on GitHub (Apr 23, 2025):
OK So I've decided that between all of my public and private projects I have way too much stuff on my plate..
I'll leave this open but I won't be able to implement it -- anyone is welcome to submit patches to facilitate this
@CursedSilicon commented on GitHub (Apr 23, 2025):
Just adding some thoughts (I literally stumbled across this project about 10 minutes ago via PhilsComputerLab)
PXE booting support shouldn't require much (any?) modification of the system. However you would need a computer with sufficient memory to load the entire CD into a RAMdisk, which may be prohibitive for "period accurate" builds.
Something like https://ipxe.org/ might also be helpful for testing. You can boot it as a LiveCD (or even burn it into a ROM!) and have it handle all the under the hood stuff, then just feed it the ISO + MEMDISK over an HTTP(S) server.
An additional advantage would be this enables downloading the 1GB+ image at wireline (NIC/CPU limit) speeds, instead of PXE's rather slow transfer rates
@ssokolow commented on GitHub (Apr 24, 2025):
*nod* ...but that is a fairly big restriction. It's already restrictive enough when I'm using Damn Small Linux's ~50MiB ISO via ramdisk instead of "proper" netboot.
Hence my idea that, if I have time, I'll try pulling apart a win98-quickinstall ISO, compiling a new kernel with some network drivers, in-kernel DHCP, and support for an NFS-mounted root filesystem, and try serving up the ISO's contents that way.
Depends on what trade-offs you want to make.
If you just want the simplest test setup to get working, that'd probably be the one I mentioned previously, where you drop the ISO and PXELINUX into a local folder, add a minimal PXELINUX config file to ask it to chainload via ramdisk, and rely on QEMU's built-in support for emulating a PXE server.
@jbruns commented on GitHub (Jul 23, 2025):
Just piling some additional interest in this feature. My retro machines generally lack CD drives, and I netboot all of my OS installs, partially to enable more rapid iteration/changes and of course quicker installs.
In some VM-based testing, I found that more or less the minimum amount of RAM you'll need to put one of the iso variants in a ramdisk, and successfully boot/install, is about 1GB. My AMD K6 machine can just forget about it at that point.
@ssokolow your proposal is sound - build the necessary support into the kernel, and mount the files over NFS (or CIFS, if I could be so bold to ask). I'm wondering if you made any progress - I didn't fuss with it much, but I'm having a ton of issues getting the build environment correctly set up on Ubuntu 22.04. I'm curious if I can just isolate the kernel configuration from this repo and pair it with the linux source tree, since all I need to do is build a kernel anyway (I think?).
@ssokolow commented on GitHub (Jul 23, 2025):
@jbruns From what I've read, NFS support is built much more deeply into the Linux kernel and CIFS would require more work on putting support files into an initramfs.
Unless I misunderstood something, it's possible to build a kernel which can netboot off NFS with no initramfs at all.
Other stuff came up and what little retro-hobby time I could spare was focused exclusively on testing and repairing hand-me-down laptops that arrived. (I've still got a couple that need more diagnosis, a Thinkpad T42 that I need to order a replacement keyboard for, and to look up where a Canadian can buy trustworthy replacement laptop PSUs without getting ripped off... both for a Vista-era Acer and what, IIRC, is a 9x-era Toshiba.)
That's why I want to try NFS... because I think that, plus a
make menuconfigsetting change or two, is all I should need to get NFS netboot working.@jbruns commented on GitHub (Jul 23, 2025):
I feel this statement in my very bones.
I've still got maybe a few hours to put into this - I was able to take the changes from https://github.com/oerg866/win98-quickinstall/pull/48 and get a sane build environment going (I'm fairly certain).
Well?
-rw-rw-r-- 1 jbruns jbruns 2407296 Jul 23 21:14 bzImage.cdNo guarantees life will put a hard stop to progress here, but I'll try and at least share if I can make any headway.
@CursedSilicon commented on GitHub (Jul 23, 2025):
Off-topic, but this item may be helpful for that converts USB-C PD to barrel jacks of various sizes. "Project IVY" uses them to power about a dozen different ThinkPads at a local retro computing event.
@jbruns I would volunteer but I've been swept up in my own enormous retro project for the last 8 months. If there's no progress made by the end of the year I may be able to sit down and hammer on this myself
@jbruns commented on GitHub (Jul 23, 2025):
Well - some progress.
Take https://github.com/oerg866/win98-quickinstall/pull/48 (@perchrh fork - nice work!!), and set up your build environment using their instructions (note the changes to the initial package setup in
BUILDING.md.Execute
init.sh. cd to thelinuxdirectory andmake menuconfig.Load the
../buildscripts/linux_config.cdfile and make the changes you need. I have tried enabling for test purposes:Networking support:
Device Drivers -> under Ethernet, I enabled Intel PRO/1000 Gigabit so I can test on Proxmox.
File Systems -> Network File Systems -> I tried enabling CIFS root, but this is probably a bit adventurous.
I actually couldn't work out how to enable "NFS client support"...it is been ages since I've compiled a kernel.
I had just finished enabling NFS on my RetroNAS machine when I sadly ran out of time.
I can confirm however if you commit changes to
linux_config.cdand then executebuild.sh, you'll get a much largerbzImage.cdupon enabling network support, and it does seem to do DHCP on boot!pxelinux.cfg/defaultentry:@jbruns commented on GitHub (Jul 24, 2025):
I kept running into walls here which largely have to do with just how stripped down the kernel is (which is, for the use case, really good).
In addition to a kernel which supports nfs root, I think you might also need:
So - as an alternative which won't require a ton of RAM, you can boot an existing Linux distribution using PXE, mount the QuickInstall CD files over NFS, set a couple of environment variables and off you go.
I used CloneZilla, since I already had it configured on my server:
Once you select the locale, you're given the option to drop to a shell, where again you can immediately just go and mount the NFS location where you have the QuickInstall files, and start that instead.
Let's say you mounted the share to
/win98qi:..and after all that, you're still installing insanely fast versus OG Setup.
@ssokolow commented on GitHub (Jul 24, 2025):
I suppose, for that, I'll have to find time to experiment with netbooting Damn Small Linux 4.4.10 over something like NFS.
It more or less just fits for ramdrive netboot on my HP t5530 thin client with 128MiB of soldered RAM (which I have normally booting Win98SE) so ramdrive netboot wouldn't work on the AST Adventure! 210 with 80MiB of RAM where I can't max it out to 128MiB because I don't have a guide to the jumpers.
(As-is, I just trial-and-error'd the AST with different DIMMs until I found a combo which POSTed and memtest86+'d with the highest reported capacity I could achieve... which is funny because I think one of them is a 256MiB DIMM that it's only using 64MiB of.)
@jbruns commented on GitHub (Jul 24, 2025):
More progress.
@ssokolow you sent me on the right path I think - I went from Damn Small, over to Tiny Core Linux.
Refer to https://wiki.tinycorelinux.net/doku.php?id=wiki:netbooting - basically the tl;dr is, if you take the kernel and initrd from the Core .iso, put those files on your tftp server, and then create a pxelinux boot entry about like this:
The
nfsmount=parameter saves you a ton of trouble (in my opinion).In your share, you can put a simple script in there to set the appropriate env vars, and then start
lunmercy.For giggles, I turned my Proxmox test VM all the way down to emulate a Pentium 1 CPU, with 128MB RAM.
free -mshows 115MB total, 9 used on boot. I'd say there's plenty of headroom.I do not know if it will work on a 486, but I'd say as opposed to adding a bunch of bloat to the QuickInstall repo, this might be the best way to fairly easily netboot it.
@CursedSilicon commented on GitHub (Jul 24, 2025):
If you want the absolute most bare-bones possible system you might want to consider doing a Gentoo i486 image with
muslfor a libc. That'll let you build both kernel and Userland apps with-Osfor size as well