* Add AArch64/ARM64 EFI boot support (for QEMU and some boards)
* Allow GRUB to load cmdline.txt-like
* Enable qcow2/vmdk disk images
Co-authored-by: Stefan Agner <stefan@agner.ch>
* Use LSI Logic SCSI controller in vmdk descriptor as well
For some reason, the vmdk disk format's descriptor contains the
controller type as well. By default, qemu-img sets it to "ide", which
seems not optimal especially for VMware's ESXi. Set adapter type to
commonly supported "lsilogic".
* Move ova image generation to hdd-image.sh
* Bump buildroot
* buildroot 3c5f87185d...5ffdf6ccc5 (1):
> package/e2fsprogs: Create y2038 capable file systems by default
* Use inode size of 256 bytes for overlayfs
By default older versions of mkfs.ext4 create file systems with inode
size of 128 bytes. This does not allow for 64-bit timestamps, which
leads to y2038 compatibility warnings. Use 256 bytes inodes.
* Use skopeo to download container images
Separate container download from image build. This will allow to share
the downloaded images between multiple builds.
We won't store the Supervisor container with the version tag, just with
the latest tag. This allows to simplify the procedure a bit. It seems
there is no downside to this approach.
* Use official Docker in Docker images to build data partition
Instead of building our own Debian based image let's use the official
Docker in Docker image. This avoids building an image for the hassio
data partition and speeds up build as well.
This calls mount commands using sudo to mount the data partition as part
of the buildroot build now. This is not much different from before as
mount has been called as root inside the container, essentially equates
to the same "isolation" level.
* Use image digest as part of the file name
The landing page has no version information in the tag. To avoid
potentially source caching issues, use the digest as part of the file
name.
Other compression methods remove the original image file at compression.
Add the -m (move) command to zip to do the same when compressing with
zip. This saves some space in the builds image/release directory.
* Add squashfs with LZ4 and LZO compression to Barebox
* Add squashfs with LZO compression to U-Boot
* Use squashfs for Linux kernel partition
Generate a squashfs image with LZO compression for the Linux kernel
partition. Adjust the boot scripts to be file system independent commands
to boot from squashfs.
In the past file system extents have been deactivated to get better
performance in U-Boot. However, the performance issue has been addressed
with commit d5aee659f217 ("fs: ext4: cache extent data") in U-Boot. The
performance should be equal to regular files using no extents.
Enabling extents has an advantage however: Files are stored more
efficently, especially relatively large files like a kernel image. The
impact is not all that big (~100KiB), but worthwhile nonetheless.
Virtual Disk images are often used on Windows and/or Mac platforms where
xz is not a widely known file ending and also not supported by dafault.
Use zip which is much better known.
Keep using xz for boards since those are not meant to be extracted by
users but directly used in Etcher. Also keep using xz for qcow2, since
qcow2 is mostly used on Linux platforms where xz is available by default
and zip usually needs an extra package.
Use sparse files instead of files written full of zeros. This speeds up
the image generation process significantly. It also makes sure that
virtual disk image formats are minimal in size.
Note: qemu-img automatically generates sparse files when detecting a
block full of zeros. But this is applied on the write side, after image
convertion: The disk image format itself still thinks the whole image
is allocated, leading to larger image than necessary. Also some output
format seem to regonize chunks of zero and create sparse files themself.
With this change, the raw source image file is a sparse file. This is
regocnized by qemu-img at read time (see block/file-posix.c), and leads
to "native" sparse files in the output format.
Some numbers
- qcow2 1.8G -> 862M (same on-disk size)
- vdi 15G -> 888M (same on-disk size)
- vhdx 30G -> 1.1G (918M -> 861M on-disk size)
- vmdk 1.8G -> 866M (about the same on-disk size)
Obviously this also affects the compressed size. But because there are
still lots of zeros, the difference in compressed size is not that big.
Currently the Microsoft Reserved Partition GUID is used for this FAT32
formatted partition. This GUID is a rather Microsoft Windows specific
GUID and not commonly used on Linux.
On Linux systems partitions of this type do not get automatically
mounted (see /usr/lib/udev/rules.d/80-udisks2.rules). However, since
this partition contains some files user commonly need to adjust
(config.txt, cmdline.txt) it would be good if the partition does get
mounted.
Use Microsoft Basic Data instead, which is used by default for FAT32
partition (even by Linux partitioning tools such as gparted). Tested
on ASUS Tinker Board and RPi4.
Aligning partitions (and hence file system structures) to higher level
then 512 byte sectors is common practise and highly recommended for flash
backed block devices. It makes sure that the underlaying flash translation
layer (FTL) does not amplify writes due to missalignment of its erase
block size. Use a 1MiB boundary which is what a modern fdisk is doing.
Before this change:
# fdisk /dev/mmcblk0
Welcome to fdisk (util-linux 2.35.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/mmcblk0: 14.57 GiB, 15634268160 bytes, 30535680 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: dos
Disk identifier: 0x48617373
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 16384 65537 49154 24M c W95 FAT32 (LBA)
/dev/mmcblk0p2 65539 1228814 1163276 568M 5 Extended
/dev/mmcblk0p3 1228816 1425425 196610 96M 83 Linux
/dev/mmcblk0p4 1425427 30535679 29110253 13.9G 83 Linux
/dev/mmcblk0p5 65540 114693 49154 24M 83 Linux
/dev/mmcblk0p6 114695 638984 524290 256M 83 Linux
/dev/mmcblk0p7 638986 688139 49154 24M 83 Linux
/dev/mmcblk0p8 688141 1212430 524290 256M 83 Linux
/dev/mmcblk0p9 1212432 1228814 16383 8M 83 Linux
After this change:
# fdisk /dev/mmcblk0
Welcome to fdisk (util-linux 2.35.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/mmcblk0: 14.57 GiB, 15634268160 bytes, 30535680 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: dos
Disk identifier: 0x48617373
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 16384 65535 49152 24M c W95 FAT32 (LBA)
/dev/mmcblk0p2 65536 1239039 1173504 573M 5 Extended
/dev/mmcblk0p3 1241088 1437695 196608 96M 83 Linux
/dev/mmcblk0p4 1439744 30535679 29095936 13.9G 83 Linux
/dev/mmcblk0p5 67584 116735 49152 24M 83 Linux
/dev/mmcblk0p6 118784 643071 524288 256M 83 Linux
/dev/mmcblk0p7 645120 694271 49152 24M 83 Linux
/dev/mmcblk0p8 696320 1220607 524288 256M 83 Linux
/dev/mmcblk0p9 1222656 1239039 16384 8M 83 Linux
See also:
https://unix.stackexchange.com/questions/248939/how-to-achieve-optimal-alignment-for-emmc-partitionhttp://3gfp.com/wp/2014/07/formatting-sd-cards-for-speed-and-lifetime/
Working:
* Ethernet
* Resize of Data
* RAUC boot marking/fetching
* CMD Line into HASSOS and Linux
Partially working:
* USB (requires 1+ devices in at boot. Seems to be a kernel/dt issue.)
Untested:
* RAUC Update
* HDMI
Not working:
* Homeassistant
** We see:
hassio > ha info
The HTTP request failed with the error: Get http://hassio/homeassistant/info: dial tcp 172.30.32.2:80: getsockopt: connection refused
