mirror of
https://github.com/token2/snapd.git
synced 2026-03-13 11:15:47 -07:00
83244699a3
* snap-bootstrap: wait in `mountNonDataPartitionMatchingKernelDisk` The current snap-bootstrap has a race when mounting the seed partition in `mountNonDataPartitionMatchingKernelDisk` on EFI systems. The code determines the partUUID of the disk that booted the kernel by reading the EFI LoaderDevicePartUUID variable. However there is no guarantee that this partition is available when snap-bootstrap runs, the kernel may still enumerate the HW. This can be observed on a fast NUC when booting from a USB stick. Note that the `the-tool.serice` already has a "After=systemd-udev-settle.service" set but that is still racy because any `udev settle` (or `udev trigger --settle`) is racy, the only option is to poll for the part uuid to appear. This is a minimal commit to avoid too much churn in code. Thanks to Sertac for reporting this bug. * snap-bootstrap: rework waitPartSrc to improve testing (thanks to Alberto and Ian) * snap-bootstrap: show a log message if waitPartSrc needs to wait If waitPartSrc needs to wait for the device this commit makes it show a logger.Noticef() message. The message is only shown once because waiting for the device is usually super quick and if it is not that is most likely an error anyway so spamming the terminal will not help. * snap-bootstrap: add test that ensures that if no waiting is needed for partSrc no log message is displayed * snap-bootstrap: rename waitPartSrc -> waitFile * snap-bootstrap: fix time.Duration() casting on 32bit systems
snap-bootstrap
Welcome to the world of the initramfs of UC20!
snap-bootstrap is the main executable that is run during the initramfs stage of UC20. It has several responsibilities:
- Mounting some partitions from the disk that UC20 is installed to. This includes ubuntu-data, ubuntu-boot, ubuntu-seed, and if present, ubuntu-save (ubuntu-save is optional on unencrypted devices).
- As part of mounting those partitions, snap-bootstrap may perform the necessary steps to unlock any encrypted partitions such as ubuntu-data and ubuntu-save.
- After unlocking and mounting all such partitions, snap-bootstrap then chooses which base snap file is to be used for the root filesystem of userspace (as the root filesystem of the initramfs is just a static set of files built into the initramfs and is not the final root filesystem), and mounts this base snap file.
- snap-bootstrap then chooses which kernel snap file is to be used to mount and find additional kernel modules that are not compiled into the kernel or shipped as modules inside the initramfs or otherwise loaded as DTBs, etc.
- snap-bootstrap then also will mount the ubuntu-data partition such that either the writable components of the root filesystem come from this actual partition, or if the mode the system is booting into is an ephemeral system such as install or recover, will mount a temporary filesystem for this.
- snap-bootstrap on kernel and base snap upgrades will also handle updating bootloader environment variables to implement A/B or try-boot functionality.
- snap-bootstrap then finally may do some additional setup of the root filesystem such as copying some default files for ephemeral system modes such as recover.
Degraded recover mode
When booting into recover mode, snap-bootstrap has some additional logic setup to try and be as robust as possible. This logic is fairly complicated and best explained in the following state diagram showing the states and transitions that snap-bootstrap operates in during recover mode, which has been called degraded mode.
The above state diagram was made with https://app.diagrams.net/ and can be imported by opening the SVG file in this directory there.