Same idea as 03677889f0.
No functional change intended. The type of the iterator is generally changed to
be 'const char*' instead of 'char*'. Despite the type commonly used, modifying
the string was not allowed.
I adjusted the naming of some short variables for clarity and reduced the scope
of some variable declarations in code that was being touched anyway.
bootctl so far tried to determine the layout from /etc/machine-info, but
that's obsolete, and the kernel-install script never looked there. Let's
read the setting from /etc/kernel/install.conf instead, where
kernel-install actually looks.
Support for reading the field from /etc/machine-info is retained for
compat.
This means we'll now read /etc/machine-id, /etc/machine-info and
/etc/kernel/install.conf, and read the machine ID from the former too
and the layout setting from the latter two.
With the changes in 20ec8f534f, we would sort
entries with sort-key as expected (higher versions earlier, i.e. at the top of
the menu), but entries without the sort-key as before, with higher versions
later.
When we have a bunch of boot entries grouped by machine-id (or even in the
typical case of all boot entries having the same machine id), sorting by id
should generally give good results. Entries will be grouped by installation,
and then newer entries should generally be at the top of the menu.
The code is quite different from the rest of bootspec.c, with different
deps and stuff. There's even a /***/ line to separate the two parts.
Given how large the file already is, let#s just split it into two.
No code changes, just some splitting out.
Conceptually the feature is great and should exist, but in its current
form should be worked to be generic (i.e. not specific to
Windows/Bitlocker, but appliable to any boot entry), not be global (but
be a per-entry thing), not require a BootXXXX entry to exist, and not
check for the BitLocker signature (as TPMs are not just used for
BitLocker).
Since we want to get 251 released, mark it in the documentation, in NEWS
and in code as experimental and make clear it will be reworked in a
future release. Also, make it opt-in to make it less likely people come
to rely on it without reading up on it, and understanding that it will
likely change sooner or later.
Follow-up for: #22043
See: #22390
Apparently Grub is measuring all kinds of garbage into PCR 8. Since people
apparently chainload sd-boot from grub, let's thus stay away from PCR 8,
and use PCR 12 instead for the kernel command line.
As discussed here: #22635Fixes: #22635
It's not a pointer after all, but a numeric value. As such the const
applies to the value and not the target, but we genreally don#t do that
for value parameters. Hence drop the const.
This makes a bunch of closely related changes:
1. The "entry-token" concept already introduced in kernel-install is now
made use of. i.e. specifically there's a new option --entry-token=
that can be used to explicitly select by which ID to identify boot
loader entries: the machine ID, or some OS ID (ID= or IMAGE_ID= from
/etc/os-release, or even some completely different string. The
selected string is then persisted to /etc/kernel/entry-token, so that
kernel-install can find it there.
2. The --make-machine-id-directory= switch is renamed to
--make-entry-directory= since after all it's not necessarily the
machine ID the dir is named after, but can be any other string as
selected by the entry token.
3. This drops all code to make automatic changes to /etc/machine-info.
Specifically, the KERNEL_INSTALL_MACHINE_ID= field is now more
generically implemented in /etc/kernel/entry-token described above,
hence no need to place it at two locations. And the
KERNEL_INSTALL_LAYOUT= field is not configurable by user switch or
similar anyway in bootctl, but only read from
/etc/kernel/install.conf, and hence copying it from one configuration
file to another appears unnecessary, the second copy is fully
redundant. Note that this just drops writing these fields, they'll
still be honoured when already set.
The data type off_t can be 64 on 32 bit systems if they have large
file support. Since mmap expects a size_t with 32 bits as second
argument truncation could occur. At worst these huge files could
lead to mmaps smaller than the previous check for small files.
This in turn shouldn't have a lot of impact because mmap allocates
at page size boundaries. This also made the PAGE_ALIGN call in
open_mmap unneeded. In fact it was neither in sync with other mmap
calls nor with its own munmap counterpart in error path.
If such large files are encountered, which is very unlikely in these
code paths, treat them with the same error as if they are too small.
Some firmware supports sending input events for shift and logo keys.
Previously, we would suppress these with EFI_NOT_READY unless
some other key was pressed alongside, but it is really the job of the
caller to decide how to handle these.
Note that for keys that already have a printable shift representation
the reported input event will not have the shift key bits set
(Shift+a is reported as A). Should some firmware turn out to violate the
spec here we can always remove that part.
In some cases there was a unlikely possibility that we would look
at an uninitialized key value.
Also, returning in case of unexpected input error cases should prevent
infinite looping.
On my local system I linked up the ESP and XBOOTLDR partitions, and
ended up with duplicate entries being listed. Try hard to detect that
and only enumerate entries in the ESP if it turns out that both dirs
have the same dev_t.
This should detect both bind mounted and symlinked cases and should make
our list output less confusing.
Let's improve display of boot entries and show what type they have (i.e.
boot loader spec type 1, or type 2, or auto-discovered or reported by
boot loader), and in particular mark entries the boot loader discovered
but we can't find (i.e. that likely vanished, or possibly couldn't be
found due to a misconfiguration) and that the boot loader didn't find
but we see (which are new, or possibly also the result of
misconfiguraiton).
This is supposed to be a replacement for #22161, but instead of hiding
vanished entries, highlights them, which I think is more appropriate for
a low-level tool such bootctl.
Replaces: #22161#22398
The single consumer of ticks_read() (i.e. time_usec()) checks for == 0
to detect the "not supported/invalid" case, hence actually return the
right value for that.
Note to self: should I ever become a black hat hacker, this is how I'd
hide a vulnerability. ;-)
(No, this one is not a vulnerability)
Follow-up for: 163d1ea5dd
No actual code changes, just renaming.
Rationale: the focus here should be on the fact that these are "unified"
images, whether our stub is used or not, or something else doesn't
really matter. Moreover, these are still Linux entries. Hence, emphasize
that these are *unified* images, and *Linux* images, and deemphesize
that our sd-stub is likely used.
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Yu Watanabe
Jan Janssen
Michael Biebl
Alfonso Sánchez-Beato
Tobias Stoeckmann
Daan De Meyer