On Fri, Jul 04, 2025 at 04:41:35PM -0600, Philip Prindeville wrote: > On Jul 4, 2025, at 12:54 PM, Daniel Golle <[email protected]> wrote: > > On Fri, Jul 04, 2025 at 11:47:26AM -0600, Philip Prindeville wrote: > >> > >> Yeah, I’ve been thinking about us developing an Amazon EC2 image for the > >> market place for people who have CGNAT, for instance, but might want to > >> lease a VM with a fixed IP address, host DNS there, and then do > >> port-forwarding over VPN... and we could have the royalties go to the > >> project. > > > > Yes, I agree we need to do that and facilitate easy deployment of > > OpenWrt images on the various clouds. It's not my area of expertise, but > > I know that Paul Spooren has previously been working on that. > > > I’ll ask the #homelab group at Amazon if they have interest in contributing > to this. We might even be able to get a few free VMs to help with > development. >
Nice, lets see how that goes. > We have an SD driver even if the SD slot is empty from the factory. Why not > an NVMe driver baked in, even if the M.2 slot is empty from the factory? I > don’t really see the difference. The M.2 slot exposes a PCIe bus. We *do* ship the PCIe host controller driver. There are many things you can connect using PCIe, not just NVMe SSDs. While in theory the same is true for SDIO, we do include the MMC block storage driver because it is anyway already needed for the eMMC. And even if that would not be true, another reason for shipping a hypthetical SD card storage driver would also be that the SD card can be used to boot from, while there is no way to boot from anything connected to the PCIe bus on that board. Maybe I have to understand why that is such an urge for you, so let me ask you why it is such a problem that the kmod-nvme package (and maybe also filesystem and partitioning tools you may need in order to use an NVMe in a meaningful way) needs to be installed and isn't included in the *default* image? Why can't you just install all that on the systems you need it? Why can't you just create an image with the ImageBuilder which includes that? Independently of the specific case above: Including *all* kernel modules and potentially needed firmware for all those modules is really not an option. Take a look at https://packages.debian.org/sid/linux-image-arm64 and understand that even just a include-everything kernel with all modules is about 90 MB. And linux-firmware is currently about 1.2 GB (not all of that needs to be included, of course, but who would work to decide what should be?) Given that the current average OpenWrt device comes with a total of 128 MB SPI-NAND flash, that's clearly too much. Even on devices with a 4 GB eMMC it be a pain. > > > > > >> > >> How much work would it be, anyway, to have the options to build images > >> that provision /var at install time, and a “sysupgrade” that supports it > >> and doesn’t lose your configuration… > > > > One solution could be to have two variants of the 'base-files' package: > > One with /var being tmpfs (like now), and one new, let's call it > > 'base-files-persistent-var' which would treat /var as persistent storage > > on an additional volume, or even as part of rootfs_data. > > > Or the boot script could simply peek into /etc/config/fstab and see if > there’s a mount for /var ... True, we could also setup the symlink /var -> /tmp dynamically if there isn't any entry for that in /etc/config/fstab. Currently the symlink itself is part of the base-files package. > > > > The problem is that it doesn't end there, as an unknown number of > > packages also assumes that /var == /tmp, and all of them will have to be > > fixed. > > > At this point I’d settle for /var/log working… though if I ran a mail > front-end (a relay only, not a mail store) on my OpenWRT, I’d probably want > mail storage (/var/spool/mqueue or whatever) to be persistent so that > undelivered email doesn’t get lost in the case of a reboot. logger should already handle if the logfile is on a mounted volume. You need to install 'blockd' for that to work though, as blockd is in charge of emitting the notification about a newly mounted filesystem. _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
