Commit Graph

7 Commits

Author SHA1 Message Date
Diederik de Haas 82dfcf25ff
Explicitly copy 'fsck*' into the initramfs
While fsck.ext4 and fsck.vfat are part of the initramfs, it turns out
that fsck itself isn't!
While it normally gets included in the initramfs, for some reason that
doesn't happen with our image creation, so it isn't available on first
boot, so explicitly copy 'fsck' so that it will be included.
For that to work, 'logsave' is needed too, so include that as well.

During boot up, initramfs wants to check the filesystems and it does so
via `fsck`, which then (presumably) checks the filesystem being used
and calls the appropriate fsck.* to do the actual checking.
But when `fsck` itself isn't available you get the following warning:
"Warning: fsck not present, so skipping root file system"
When it is available, you'll get a message like this:
"Begin: Will now check root file system ... fsck from util-linux 2.38.1"

Let's also follow our own advise and not *assume* the needed fsck
programs are present in initramfs, but add them explicitly.

Now we can start the resize operations while knowing the current
filesystem is in a proper/clean state.
2022-12-01 18:29:17 +01:00
Diederik de Haas 205dc21718
Document and complete rpi-resizerootfs hook
The main trigger was a missing program in the initramfs, which probably
everyone assumed was there ... but wasn't. (See next commit ...)

So instead list every program that we need/call, so that we *know* that
that program is included in the initramfs.
Also document this new 'policy'.

Also group the programs by the package which has them and sort the list
alphabetically by the package names.
2022-11-15 15:46:38 +01:00
Diederik de Haas 1b194afcc9
Fix bug introduced when 'fixing' SC2086 (quotes)
The 'ROOTFLAGS' parameter should NOT be quoted as it then introduces an
(empty) extra argument to 'mount', causing a boot failure.
Thanks to 'mjt' for the help and identifying the issue.

Lessons learned:
1) Don't blindly follow the *suggestions* that shellcheck makes
2) Test your changes (properly) before submitting/merging them

ad 1) I find shellcheck a very useful tool, but it doesn't (and likely
can't) understand the full context. The developer does (or should) and
should evaluate each suggestion whether it's applicable in this case.

ad 2) This should've been obvious and certainly for me.
I'm normally very dilligent and test all my changes, but I got sloppy
this time and did not. With logical consequences.
2022-11-15 15:17:40 +01:00
Diederik de Haas 422832740b
Fix shellcheck issue SC2086 (quotes)
SC2086: Double quote to prevent globbing and word splitting.

Also remove it from the exclude list in the CI config file.
2022-11-14 22:38:56 +01:00
Diederik de Haas 9bb0488096
Fix shellcheck issue SC2154
SC2154: var is referenced but not assigned.

The 'rootmnt' variable is set in /usr/share/initramfs-tools/init and if
it's not available, that would be bad.
According to SC2154 you can fix that issue by using '${var:?}' so it
would fail if unset or empty.
So apply that and reference that SC item in the comments.

Also remove it from the exclude list in the CI config file.
2022-11-14 22:38:47 +01:00
Andres Salomon 4816680ba6 resizerootfs: switch from using sfdisk to parted for resizing partitions
sfdisk is a bit crusty - it doesn't understand gpt partition tables very well,
for example. By switching to parted, we can handle gpt issues (which may be
useful in the future, and is definitely useful for other boards), and we no
longer have to hardcode that 4M alignment workaround. Parted will tell us
the free space at the end of the disk.

Because we're already using partprobe, there's no additional dependencies
needed.
2021-08-25 01:23:20 +02:00
Andres Salomon 0f23b8e378 rpi-resizerootfs: switch the root filesystem resizing away from a systemd oneshot service
Switch away from using a systemd service for the initial root resize.
Instead, we resize the root partition and filesystem in the initrd.

To simplify things, the initrd script will check whether it should resize
the partition on every boot. It does this by checking if the entire disk
(ignoring an empty 4MB) is in use.  However, the scripts themselves are
deleted from the system after the initrd is generated. After the image
is installed, the resize script should exist only in the initrd. When the
kernel gets upgraded (eg, for a security update) or a new initrd is generated
due to a package install, the new initrd will not contain the resize script.
At that point, nothing will remain from the image's initial resize
bootstrapping process.

This process (but not the scripts) is similar to what cloud-initramfs-growroot
does. However, that particular package has an indirect dependency on Python,
and we don't necessarily want that overhead in our images just for resizing.
2021-05-10 14:08:07 -04:00