resize x86 rootfs to 36 MB and kernel to 16 MB

[nrbffs]

By default, OpenWRT 18.06 uses 256 MB rootfs and 16 MB kernel partition size, see config/Config-images.in:

     config TARGET_KERNEL_PARTSIZE
         int "Kernel partition size (in MB)"
         depends on GRUB_IMAGES || USES_BOOT_PART
         default 16
 
     config TARGET_ROOTFS_PARTSIZE
         int "Root filesystem partition size (in MB)"
         depends on GRUB_IMAGES || USES_ROOTFS_PART || TARGET_ROOTFS_EXT4FS || TARGET_rb532 || TARGET_mvebu || TARGET_uml
         default 256
         help
           Select the root filesystem partition size.

This will result in an image larger than 256 MB. However, some x86 devices such as Futros will have just a 256 MB CF card and thus won't be able to upgrade (in my observations).

To resolve, make kernel and rootfs as small as possible for x86, allowing x86 devices with 256 MB disk to upgrade.

[rotanid]

256MB isn't enough anymore since Gluon v2017.1 has been released in 2017, see the note in its release notes:
https://github.com/freifunk-gluon/gluon/blob/master/docs/releases/v2017.1.rst
therefore, only devices still running ancient versions before this would benefit from the suggested change.

[Adorfer]

just 2 notes: (this is not a statement for or against the proposal)

1. all S550 i got either shipped with 512MB or 1GB CF
2. there are still big communities on 2016.x

[txt-file]

@rotanid: The Release Notes state that more than 273 MB disk size are needed. There is no explanation why. Can you state why such big disks are needed?


@Adorfer: Only because all devices you got have bigger flash does not mean everybody has such huge disk space.


Another note: With 2019.x we switch from ext4 to squashfs images.

• Is it really useful to raise the limit and one version later switch file systems?
• Would it be better to backport target x86-*: change from ext4 to squashfs #1634?

[txt-file]

16 is already the default. Why setting it explicitly?

[nrbffs]

Good point. Maybe not to be surprised from upstream changes to partition layout? I am fine either way, though.

[rotanid]

@rotanid: The Release Notes state that more than 273 MB disk size are needed. There is no explanation why. Can you state why such big disks are needed?

no i can't, as i didn't commit related changes, i can only quote from existing docs.

Another note: With 2019.x we switch from ext4 to squashfs images.

* Is it really useful to raise the limit and one version later switch file systems?

one version later? please check again or explain

[nrbffs]

@rotanid: The Release Notes state that more than 273 MB disk size are needed. There is no explanation why. Can you state why such big disks are needed?

The increased image size was introduced by upstream commit a1f83bad606411a561e8e60110c71232b1a28aa2. However, no rationale is given on why this change is needed. Maybe someone who's more involved in OpenWRT development knows.

Then, later it was increased to 2 GiB to allow online resizing. After that, they reverted back to 256 MB. In master, however, they have now switched to 128 MB.

Is it really useful to raise the limit and one version later switch file systems?

For now, Freifunk Stuttgart maintains their own fork of Gluon just to keep 256 MB Futros we might have alive (difficult to see how many of these we have, though). I'd like to avoid having to maintain this fork for a long time. If you say squashfs will also solve the problem (don't know myself tbh as filesystem IMO doesn't have anything to do with partition size, does it?), I'm also fine maintaining this fork for v2018.2.x and then abandoning it when we switch to v2019.x.

[rotanid]

thank you for your analysis. maybe we should switch the value from OpenWrt Master then instead of reducing it as much as you propose?

either way, as you said yourself we need someone else to think about this, e.g. neoraider or blocktrron.

[A-Kasper]

256 MB is very uncommen for x86 targets. There are other Devices than Futros and all Futros I know have at least 1 GB Flash.

Would it be possible to offer an x86-tiny image for this special usecase?
For me x86 Image is the one I'm using for debugging, Services and experimental setup. It's the only image where I really install additional packages.

[blocktrron]

I have no in depth knowledge about the x86 Image generation, however 36M Rootfs size might clash with GLUON_DEBUG.

There were Futros with 256M CF card in circulation, however these should all be very old models from around 2004. We've only seen them on old Geodes and Transmetas.

I would keep the value close to upstream. I've not yet heard of communities which accidentally killed a lot of devices with this update.

Another point is that x86 is very hard to predict hardware-wise. So it always has a higher chance of breaking on updates.

[rotanid]

we (@mweinelt ) discussed this topic on IRC yesterday and thought if we change it, we should use something more meaningful, at least can't make sense of 36+16 (this PR) or 128+16 (openwrt master)
We suggest 112+16 to be able to use 128mb disks but still not waste any available space on such a disk size.
we welcome opinions on this, especially from @blocktrron or @NeoRaider

[neocturne]

I would suggest to use 111+16 (to leave some space for bootloader and alignment) or even 110+16 (no idea how much space is reserved for the bootloader?). But I don't really want to discuss this in Gluon - we should just use the defaults from OpenWrt, and discuss changes upstream.

[nrbffs]

Changed to 110+16 for now. I think we only need to reserve space for the MBR. The first-stage bootloader is then stored in the MBR and contains the offset to the second-stage bootloader in the partition itself.

I will also submit this change upstream.

[neocturne]

We need to confirm that the generated images are actually smaller than a 128MB card. As @T-X pointed out in IRC, an (arbitrarily chosen) 256MB card had only 254,435,328 bytes, making the actual limit for the image size ~242MiB (in units of 1024). I assume it will be similar for 128MB cards.

Also, I have no idea where grub-mkimage puts the second stage - the only sane option is to add it between the MBR and the first partition, so it would need to be considered for the full image size, but I'm not sure if the image generation code is sane ;) In any case, making a test build and checking the size of the generated image is the best way to find out if the size is correct.

[kpanic23]

Is there a reason for the filesystem to have a specific size? Wouldn't it be optimal to generate the image with as little padding as possible, and then resize the filesystem to fill the drive after installing?

[neocturne]

@kpanic23 Sure, theoretically possible (and what OpenEmbedded does by default), but I don't see why we should put much effort into implementing that - the current solution works well enough IMO.

[rotanid]

I would suggest to use 111+16 (to leave some space for bootloader and alignment) or even 110+16 (no idea how much space is reserved for the bootloader?). But I don't really want to discuss this in Gluon - we should just use the defaults from OpenWrt, and discuss changes upstream.

what does this mean, we don't do anything in Gluon until upstream changes its defaults again?
and who takes care of an upstream discussion?

[neocturne]

I can take care of proposing a patch upstream (I did a few tests and ended up with 16+104 MiB to make it fit a 128MB CF card). I wouldn't change anything downstream for now - after all, this issue existed for several Gluon versions, so I don't see a reason to hurry.

[neocturne]

Pushed to OpenWrt master in https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=61c57af618e264e9ed3ebd795eb923cbf32797c8, so we will get the change with OpenWrt 19.07 + 1.

[blocktrron]

Is there anythin speaking against backporting this change? I've talked to @nrbffs and it would greatly simplify upgrading the Gluon version from 2016.2 to the upcoming Gluon Release for their x86 nodes.

[neocturne]

I guess there is no harm in backporting this change.