The default rootfs size for the .bin raw iamge is a bit smaller now
because we still want to be able to flash to 8 GB storage. However, the
VM images still have the 6 GB rootfs as before. Some cloud images
weren't using the larger VM rootfs size though but the raw image rootfs
size.
Specify that AWS and Akamai images should use the larger VM rootfs size.
Signed-off-by: Kai Lueke <kailuke@microsoft.com>
The /usr partition was too small some time ago and we gained space again
by switching to btrfs with compression and also removing/splitting out
content. The /boot partition is too small all the time and we added
many hacks to fit the kernel+initrd under 60 MB. To handle the case
where the /oem partition is too small for the A/B-updated OEM extensions
we added the workaround to write the inactive one (or both) to the
rootfs. All this would not be needed if we had increased the partition
sizes a few years ago so that we could now assume that most nodes have
the increased sizes and we can make use of them. Still, we can do it now
to prepare for the next time when in five or ten years we have serious
size problems and run out of workarounds. We have to do the change now
and wait a few years so that most nodes have been provisioned with the
new layout. Then we can drop the workarounds and have a full featured
kernel and initrd, and we can also increase the /usr filesystem to make
use of the larger partition. Ideally we use large enough sizes that we
never have to worry again but since we also want to support small ARM
boards which might only have 8 GB internal storage, let's target this
when increasing the partition sizes. With 1 GB /boot, two 2 GB /usr, and
1 GB /oem partitions we are already at 6 GB, leaving 2 GB for the
rootfs. For now, reduce the extracted /usr update payload size to the
current combined filesystem and verity data usage (same size as before).
The rootfs size was also reduced for the initial .bin image so that we
don't overshoot 8 GB - it will be resized to fit the disk anyway on
first boot.
Signed-off-by: Adrian Vladu <avladu@cloudbasesolutions.com>
Signed-off-by: Kai Lueke <kailuke@microsoft.com>
Python warns about an invalid escaped sequence (\s) within a string -
make the string raw, so python stops treating backslashes as special
characters.
Signed-off-by: Krzesimir Nowak <knowak@microsoft.com>
We invoke zip inside the BUILD_DIR and tell it to output the
compressed file somewhere in BUILD_DIR. This works if BUILD_DIR is an
absolute path, but breaks when it's relative. Since we already are in
BUILD_DIR, tell zip to output the file in the current directory
instead.
Signed-off-by: Krzesimir Nowak <knowak@microsoft.com>
OS-dependent sysexts that ship kernel modules, usually also ship the
files in /usr/lib/modules/*-flatcar/modules.XXX When multiple such
sysexts get activated, depmod files from just one sysext win and other
kernel modules cannot be loaded using modprobe. We get around this by
removing the depmod files from every sysext with kernel modules.
Instead, we set up modprobe hook, which dynamically runs depmod in a
temporary directory on every sysext kernel module activation.
Signed-off-by: Daniel Zatovic <daniel.zatovic@gmail.com>
The pxe disk is a cpio file that, among other things, contains a
squashfs image.
The image has contents of `/usr` directory, so the image's toplevel
directories are `lib`, `lib64`, `share` and so on. The first fix was
to change the `/usr/share/flatcar/update.conf` path in pseudofile
listing to `/share/flatcar/update.conf`. Otherwise mksquashfs started
complaining that `usr` directory does not exists in the image, so some
of the pseudofiles won't be installed.
Second fix is still related to the same file. It already exists in the
image, so the pseudofile wanting to be installed there won't be,
because mksquashfs stopped liking overwriting the files already
present in the image. I added `-e share/flatcar/update.conf` to avoid
adding the file into the image, so that pseudofile can be created
there. It was actually a suggestion printed by mksquashfs.
Following what was done for incus. Removes the subuid/gid from sysext.
Adding subuid/subgid could be done through Ignition:
```yaml
version: 1.1.0
variant: flatcar
storage:
files:
- path: /etc/subuid
append:
- inline: |
core:1065536:65536
- path: /etc/subgid
append:
- inline: |
core:1065536:65536
```
Related: flatcar/Flatcar#1733
This create more issues than it solves:
* override existing subuid / subgid
* not flexible for the end user
* it has to be created only once (while tmpfiles always try to create
those files)
I think Flatcar should not be responsible to create this and it should
be documented on how to do it through Ignition:
```yaml
version: 1.1.0
variant: flatcar
storage:
files:
- path: /etc/subuid
append:
- inline: |
root:1065536:65536
- path: /etc/subgid
append:
- inline: |
root:1065536:65536
```
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
I thought cpio was always creating the output directory automatically,
but it was silently failing. It would only extract the next rootfs when
run a subsequent time.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
The final part of the script differed only the name of the qemu binary
to execute and in network device driver (virtio-net-pci on amd64 vs
virtio-net-device on arm64). virtio-net-pci seems to be working also
on arm64, so simplify the code to avoid repetition.
There's no need to differentiate between amd64 and arm64 boards here
any more. This also adds bootindex=1 option to the -device flag, so we
can pass more secondary disks without affecting the boot order.
This version writes fewer temporary files and tries cpio multiple times
for concatenated archives again.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
I couldn't take it anymore! The launcher script could not handle paths
outside the script's own directory, and it was driving me crazy. Now
only the default values are relative to the script's directory. Given
paths are relative to the current directory and absolute paths work as
you would expect.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
On Linux >= 6.10, the first rootfs is an extra ghost rootfs of 336K,
that has a corrupted CPIO.
To overcome this issue, do not fail on `cpio --extract`.
Setting a profile in a newly created sysroot when building native
toolchains broke after an eselect update. Apparently eselect gets the
path to the coreos-overlay repository and then prefixes it with
ROOT. Since ROOT was set to /build/<arch>-usr, the resulting patch was
wrong. Fix this by telling eselect where to find our make.profile
symlink in new sysroot by setting PORTAGE_CONFIGROOT to
/build/<arch>-usr and where to find our profiles by setting ROOT (and
SYSROOT, because it must match ROOT) to /.
