Should Attended System Upgrade work for x86 VM with resized image?

I've used Attended System Upgrade before on simpler devices. This is the first time I've tried on x86. The x86 is a Proxmox VM with the image resized to 512M. Based on the log, it looks like it thinks it's out of space.

error: ext4_allocate_best_fit_partial: failed to allocate 2051 blocks, out of space?
make[3]: *** [/builder/include/image.mk:350: /builder/build_dir/target-x86_64_musl/linux-x86_64/root.ext4] Error 1
make[2]: *** [Makefile:208: build_image] Error 2
make[1]: *** [Makefile:146: _call_image] Error 2
make: *** [Makefile:262: image] Error 2

The VM disk looks like this:

Disk /dev/sda: 512 MiB, 536870912 bytes, 1048576 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x80cdd189

Device     Boot Start     End Sectors   Size Id Type
/dev/sda1  *      512   33279   32768    16M 83 Linux
/dev/sda2       33792 1048575 1014784 495.5M 83 Linux

Any suggestions?

Which of the upgrade tools are you using? Sounds like LuCI Attended Sysupgrade?

If that's the case, that tool does not pay attention to your resized partitions and tries to build an image using the default partition size (128MB if I recall), and hence you are getting that error at image build time.

The only (easy?) way I know to replicate your system is to collect your installed package list and use an imagebuilder with PACKAGES="your extra packages" and ROOTFS_PARTSIZE="512", then install the resulting image with the usual sysupgrade ....

Yes, I figured as much. It defeats the convenience of Attended System Upgrade. x86 should be the easiest, but in practice it's the most difficult to update. Modern hard drives are gigabytes or terabytes. 128MB is ridiculous for a 64-bit architecture.

I hear ya, it's history catching up with us. Back in the day, no sane person would use an x86 as a router: big $, huge box, total power hog, minimal connectivity and so on. These days with all the mini PCs (I've got two sitting right here!), it's a valid and attractive option.

For what it's worth, I'm implementing a CLI tool like auc, but with a bunch more options (adding and removing packages from the build, specifying fstype and rootfs size, more diagnostics and so on), mostly because of those x86 boxes that I prefer over the typical all-in-one "routers". (You can follow my progress at https://github.com/efahl/owut/, note it's snapshot-only because the ucode-mod-uclient isn't available on release builds.)

2 Likes

The infra is already there it's just hardcoded to 100MB .

1 Like

That got merged this morning, I've been testing it with x86 builds, default (104), 128, 256, 512 all work fine for me.

$ owut download --rootfs-size 512
Board-name     generic
Target         x86/64
Root-FS-type   squashfs
Sys-type       combined-efi
Package-arch   x86_64
Version-from   SNAPSHOT r26300-da0cd9d764 (kernel 6.1.89)
Version-to     SNAPSHOT r26300-da0cd9d764 (kernel 6.1.89)
Build-at       2024-05-12T11:49:39.000000Z
Image-prefix   openwrt-x86-64-generic
Image-file     openwrt-x86-64-generic-squashfs-combined-efi.img.gz
Image-URL      https://downloads.openwrt.org/snapshots/targets/x86/64/openwrt-x86-64-generic-squashfs-combined-efi.img.gz
Installed      270 packages
Top-level       86 packages
Default         46 packages
User-installed  54 packages (top-level only)

Package version changes:
  base-files                   1591~da0cd9d764                            1591~4f87a4d84f
1 packages are out-of-date.

There are currently package build failures for SNAPSHOT x86_64:
  basicstation       Sun May 12 13:53:50 2024 - Package not installed locally
  elektra            Sun May 12 15:07:15 2024 - Package not installed locally
  gatling            Sun May 12 14:10:46 2024 - Package not installed locally
  kadnode            Sun May 12 13:01:00 2024 - Package not installed locally
  libuhttpd          Sun May 12 14:16:26 2024 - Package not installed locally
  libwebsockets      Sun May 12 14:33:54 2024 - Package not installed locally
  micropython        Sun May 12 13:06:21 2024 - Package not installed locally
  pianod             Sun May 12 13:42:15 2024 - Package not installed locally
  shadowsocks-libev  Sun May 12 14:03:18 2024 - Package not installed locally
  shairport-sync     Sun May 12 16:27:04 2024 - Package not installed locally
  umurmur            Sun May 12 14:24:09 2024 - Package not installed locally
Failures don't affect this device, details at
  https://downloads.openwrt.org/snapshots/faillogs/x86_64/packages/

Requesting build ----------------------
Hash:   b304b2cead3b1486f52723b7dc053980
Status: 200
Detail: done
Build completed in 1 seconds.

Image: https://sysupgrade.openwrt.org/store/b304b2cead3b1486f52723b7dc053980/openwrt-f2f3d6a0adb2-x86-64-generic-squashfs-combined-efi.img.gz
Manifest: /tmp/firmware-manifest.json
Verifying: /tmp/firmware.bin (24268343 bytes) against /tmp/firmware.sha256sums
  Saved sha256 matches
  Mon May 13 17:35:59 PDT 2024 upgrade: Image metadata not present
  Mon May 13 17:35:59 PDT 2024 upgrade: Reading partition table from bootdisk...
  Mon May 13 17:35:59 PDT 2024 upgrade: Extract boot sector from the image
  Mon May 13 17:35:59 PDT 2024 upgrade: Reading partition table from image...
  Mon May 13 17:35:59 PDT 2024 upgrade: Partition layout has changed. Full image will be written.
Checks complete, image is valid.

$ zcat /tmp/firmware.bin >| /tmp/x ; fdisk -l /tmp/x
GPT PMBR size mismatch (1081887 != 1081918) will be corrected by write.
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
The backup GPT table is not on the end of the device.
Disk /tmp/x: 528.28 MiB, 553942528 bytes, 1081919 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 215907C3-3A1F-28A3-2491-8CB40F3E9C00

Device     Start     End Sectors  Size Type
/tmp/x1      512   33279   32768   16M Linux filesystem
/tmp/x2    33280 1081855 1048576  512M Linux filesystem
/tmp/x128     34     511     478  239K BIOS boot

Partition table entries are not in disk order.