On 3/28/2021 05:25, James Le Cuirot wrote:> On Sat, 27 Mar 2021 18:40:52 -0400 Joshua Kinard <ku...@gentoo.org> > wrote: > >> On 3/27/2021 18:16, James Le Cuirot wrote: >>> On Sat, 27 Mar 2021 17:43:34 -0400 Joshua Kinard <ku...@gentoo.org> >>> wrote: >>> >>>> I kinda wish the Linux kernel had an ability to partially boot, >>>> init the networking subsystem, then fetch an initramfs image over >>>> TFTP like it can do with NFS Root. That would solve the problem >>>> on my MIPS system(s) (and make install netboots better). I've dug >>>> around, but this does not seem to be a capability currently in the >>>> kernel, unless I have over looked something. >>>> >>>> Otherwise in the future, I may just have to setup an initramfs >>>> into an NFS Root and teach the SGI's to somehow deal with it. >>>> Which all still seems unnecessarily complicated because some other >>>> distro thinks it knows what's best for everyone else (but I >>>> digress...). >>>> >>> >>> NBD may be a slightly simpler alternative and a bit more like an >>> initramfs. nbdkit can do all sorts of weird things. I thought it >>> might have a plugin for cpio archives, allowing you to use a regular >>> initramfs generated by Dracut or similar directly. It doesn't >>> appear to but plugins are quite easy to write. Alternatively you >>> could just extract the initramfs and use nbdkit-linuxdisk-plugin. >> >> Can NBD be used like I described? Never played with it before. The >> MIPS machine has functioning local disk drives, and currently, it >> boots fine by just pulling a kernel off my TFTP server and booting from >> the local drive, no initramfs needed because I compiled everything into >> it. If we ever force sep-usr to end, then I'll need a way to teach it >> to mount /usr before dropping into /bin/init (and nothing else). > > Apologies, I went to experiment with this idea but I'd forgotten that > booting over NBD is not a built-in kernel feature and requires... an > initramfs. NFS looks like the only option with this general approach.
I've kinda come to this conclusion myself. I could probably host an extracted, micro-initramfs on my NFS server that would be loaded by the kernel to jump to $REAL_ROOT. Not *too* much of an issue on the Octane, because I can store the kernel command line args in a PROM variable so that all I have to do is type "$foo" at the PROM prompt to load something. But, SGI did their best to be inconsistent, and IP27 systems cannot permanently save variables to NVRAM. Once you power cycle, all user-defined PROM vars are lost. And Linux's NFS Root command args are somewhat complicated from what I remember. Upshot is I boot the IP27 over serial console, so I can just save bootp() args in a text file on my desktop and paste it into the console for those instances. In any event, I kinda wish there was some way to just boot the kernel to a point, have it copy an initramfs image via TFTP, load it, run it, jump to $REAL_ROOT. If I had the time, maybe I could put something together like that myself, but time is not something I have much of right now. > Rich is right though, the initramfs can be tiny. Dracut images are heavy > because they are very flexible and pack a lot of features but none of > that is required. > > The kexec idea would be a nice bonus for you, if it works. Limiting what > kernel features you can enable must be frustrating. My primary kernel image for daily use on the Octane isn't terribly limited. The final vmlinux output is ~39MB, due to loading debugging symbols in. But the cutoff in size for Octane seems to be somewhere around 43-45MB, before the PROM errors out due to no available contiguous FreeMemory() areas (the mem region defined by the ARCS PROM where stuff can be loaded and executed). Netboot kernels for installs can creep up there if you go too crazy on kernel features and pack the netboot with supporting packages (mainly filesystem tools). This already impacts older systems, like SGI Indy, which cannot boot current MIPS netboot images because they have smaller FreeMemory() areas. I thought switching to musl would make the netboots smaller, but that oddly didn't work and musl netboots are about ~2MB larger than the older uclibc-ng versions. And all of my uclibc-ng stages have become unusable for some unknown reason. As soon as you rebuild ncurses in one, all binaries linked to it throws SIGSEGVs (which kills portage). glibc-based netboots are too big and will not load at all, even on the Octane. > It's also worth bearing in mind that you could just generate an image > with Dracut and extract it to a disk partition. That may seem a little > pointless if you're not using something like LVM or encryption but I > don't see the point in separate /usr either. ;) I'm guessing you don't > want to change your partition layout at this point though. No, no LUKS, encryption, btrfs, etc. Just mdraid w/ 0.90 metadata for auto-assemble. Which is why I hate having to use an initramfs for something so simple. Unnecessary complexity annoys me (unless you're working on a non-functional art piece). In any event, I've already rebuilt the system from a RAID5 down to a RAID1, so re-doing that to merge / and /usr would not be difficult when the time comes. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
