Netboot feasible?

Hello,

I have 3 old products in the series (2 Different Seagate GoFlex NAS series: 1 with 1x 3.5" bay, and 1 with 2x 2.5" bays; Also a NetGear Home NAS product with 2x tray-less 3.5" HDD bays - I forgot the name of it).

I have a PFsense router, which has a DHCP server capable of sending DHCP parameters required for netbooting. I also have 2 home lab servers running Proxmox, and the know-how to administer a Linux system from the command-line.

My main question is: is it possible to get these old NAS boxes to Netboot using only the available, onboard flash storage?
Secondary to that is: Is it worth the effort?

I realize the second question is subjective and more a matter of opinion. I'm just trying to gauge how much Ibuprofen I'm liable to need, so to speak.

Also, is anyone able to help me get started? If it's possible to do, I can probably figure it out eventually. Some help from those more experienced would be great.

I have a rescue USB in one of the systems with an old RootFS. I'm not sure if it'll be useful/needed. All 3 were converted to USB boot using instructions in these forums at one time.

aaronouthier,


> My main question is: is it possible to get these
> old NAS boxes to Netboot using only the available,
> onboard flash storage?
> Secondary to that is: Is it worth the effort?
>
> I realize the second question is subjective and
> more a matter of opinion. I'm just trying to gauge
> how much Ibuprofen I'm liable to need, so to
> speak.

It is quite painless. I think what you are looking for is NFS rootfs.

Wiki thread

Quote

NFS

NFS - HowTo set up NFS shares (and boot NFS rootfs), see also Debian 12 (bookworm) settings
Boot your Dockstar (and other plugs) using NFS rootfs, see also Debian 12 (bookworm) settings
Increase NFSD max_block_size
Reduce NFS threads

And your Kirkwood boxes only need to have u-boot set up to load the kernel files from an NFS rootfs, and then the kernel will mount the NFS rootfs and run on it.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

A big thanks as always Bodhi! Apologies for not getting back to you guys sooner.

I've been thinking about this quite a bit. I'm wondering now what files in a given rootfs release are specific to each box, and what files are universal? No need to answer that directly, I'm just thinking.

What would it take to have a "universal" rootfs base. If the kernel, initramfs/initrd, etc. and any unit specific files are stored directly in each specific unit's flash storage, could a generic, read only base filesystem be used, with say a unionfs or overlayfs or similar - all over NFS? I don't know enough about unionfs or overlayfs to know if a common base can be used multiple times. If not, a tarball could be deployed for each unit, I suppose.

End goal: To create a WebUI management system for modern Linux to manage these old systems! The lack of CPU power, RAM, and flash storage, is their weak point now-a-day. There just isn't sufficient to run a full Web-based config system. However, if another, more modern linux box were available, I suspect it could be used to manage anywhere from 1 to a few dozen of these old systems. Serving up NFS or SMB shares doesn't require a boat load of resources - such services could be performed locally on each device, but actual management could be performed from a central management system.

At least in theory and in my mind, the above is possible. Alas, I lack the knowledge and programming skills to accomplish such a feat. It is still find it to be a nice thought.

I have seen a somewhat similar project concept, called NSpanel Manager, used with flashed Sonoff NSPanels:
https://github.com/NSPManager/NSPanelManager

aaronouthier,

> I've been thinking about this quite a bit. I'm
> wondering now what files in a given rootfs release
> are specific to each box, and what files are
> universal? No need to answer that directly, I'm
> just thinking.
>
> What would it take to have a "universal" rootfs
> base. If the kernel, initramfs/initrd, etc. and
> any unit specific files are stored directly in
> each specific unit's flash storage, could a
> generic, read only base filesystem be used,

For Kirwood boxes, we already have a universal rootfs. That was my goal from the beginning when I start release the basic rootfs. Now the latest version is Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2.

The only difference for each box is the DTB. Everything else is the same in my setup. So u-boot envs for each box would load the correct DTB separately (if new u-boot is supported, see release thread).

If it is a Kirkwood box with stock u-boot only, then the DTB is embbed inside uImage. And that is also the only difference in the rootfs.

> with
> say a unionfs or overlayfs or similar - all over
> NFS? I don't know enough about unionfs or
> overlayfs to know if a common base can be used
> multiple times. If not, a tarball could be
> deployed for each unit, I suppose.

No need to use any overlayfs scheme, for the reason I described above.

For a while, I actually run the same NFS rootfs (starting with one and clone it to 4 other Kirkwood boxes of various types, eg. GF Net, GF Home, Pogo E02, Pogo V4, Dockstar). In my kernel build farm, there are about 8-10 Kirkwood boxes running. Each of 5 of them running from its cloned NFS rootfs. To keep the rootfs exactly the same, I used DHCP to get the dynamic ip address from the router. For LED, I have a universal scripts to turn on/off LEDs depending on which board is running. The hostname is a bit cumbersome to automate, so they are manually edited. Perhaps someone reading this would propose a solution.

After I acquired more powerful Kirkwood and Armada boxes, I no longer use these NFS booting boxes in the build farm.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 06/02/2024 05:19PM by bodhi.

Nice!

Just to clarify, my reasoning for using an overlay-type filesystem was to eliminate having to clone the FS for each box, while allowing each box to have it's own "scratch" space for FS changes. That said, besides not knowing if it's possible to use the same Read-only base with multiple overlays, I'm also not sure if such a filesystem would export correctly via NFS.

Since the Primary function of a NAS box is to facilitate File Sharing, I also suspect it wouldn't be very network-traffic efficient to boot a box via NFS, just to host it's own NFS & SMB filesystem.

Regardless of the "hows", I still think it would be an interesting project to be able to manage multiple boxes from a single Command and Control Center.

Perhaps a simple OS could be loaded into the flash storage, and be pre-setup to take commands from said C&C Center. If the need to install packages were removed from the equation, then maybe a compressed filesystem, like squashfs could be used in flash storage to make better use of space. Config changes could be stored on the CCC, and read from/implemented by instructions in the RO flash storage.

Probably all just a so-called "Pipe dream" though.

> Just to clarify, my reasoning for using an
> overlay-type filesystem was to eliminate having to
> clone the FS for each box, while allowing each box
> to have it's own "scratch" space for FS changes.
> That said, besides not knowing if it's possible to
> use the same Read-only base with multiple
> overlays, I'm also not sure if such a filesystem
> would export correctly via NFS.

What you are thinking is a typical flash-based system such as OpenWrt. The overlay FS on top are the configuration data for a specific box.

For an NFS rootfs, that would not be necessary. In both approaches, you would have to clone a reference rootfs to start with. And then add in the specifics for a box.

> Since the Primary function of a NAS box is to
> facilitate File Sharing, I also suspect it
> wouldn't be very network-traffic efficient to boot
> a box via NFS, just to host it's own NFS & SMB
> filesystem.

Not really, each of a NAS box would have its own shared data hosted on a USB or SATA disk. The rootfs has notthing to do with the data partitions.

> Regardless of the "hows", I still think it would
> be an interesting project to be able to manage
> multiple boxes from a single Command and Control
> Center.
>
> Perhaps a simple OS could be loaded into the flash
> storage, and be pre-setup to take commands from
> said C&C Center. If the need to install packages
> were removed from the equation, then maybe a
> compressed filesystem, like squashfs could be used
> in flash storage to make better use of space.

We are talking about a modern NAS where nothing else but the boot loader is on flash. So compressed file system is not applicable.

Again, you are thinking flash-based systems. Which has a lot of limitation, e.g. flash space must be very large to be able to host a Debian rootfs.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)