Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
On 04/09/2022 at 03:06, Nicholas D Steeves wrote:
Pascal Hambourg writes:
I guess that handling btrfs subvolumes or other root filesystem mount
options would require changes in the root file system selection step. I
do not see how it could be automated (rootflags are defined in the boot
loader configuration which may be located anywhere).
(...)
To do more, we need a mechanism to detect [bootable] subvolumes and then
present a menu of candidates while excluding read-only snapshot and
non-bootable and irrelevant subvolumes.
What do you mean by "bootable" ? Root filesystems may not be "bootable"
in any way I can think of.
Would (/bin/mount AND /etc/fstab) be useful for this?
You cannot rely on the presence of /bin/mount in /usr-merged
installations with a separate /usr. And I am not sure that /etc/fstab is
even mandatory.
Ie: This may be
enough for Pascal's work to find everything else that is needed (other
than the subvolume=foo specification). If the sysadmin/user botched
their fstab then this will fail; however, the discussion I had on
debian-boot (possibly on IRC) indicates that this is a non-issue,
because "rescue" is only expected to reinstall the bootloader. What do
you think?
Rescue mode is also expected to chroot and run a shell into the selected
filesystem.
ISTM that the rescue media should test for an actual Debian installation
with something like:
awk '{print $1}' < /MOUNTPOINT/etc/issue
or perhaps
grep 'ID\=debian' < /etc/os-release
I am not sure that rescue mode should be restricted to Debian
installations only.
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
On Sat, 2022-09-03 at 21:06 -0400, Nicholas D Steeves wrote:
> First, the automated case: Currently DI statically sets the rootfs to be
> "subvolume=@rootfs", which is a value unique to Debian. The simple
> thing to do is to detect that a device has been formatted to btrfs
> before mounting, and then try to mount "-o subvol=@rootfs" as Ansgar
> suggested. One step more flexible is to have a Rescue policy of
> something like only supporting read-write subvolumes with a name that
> matches '.*\@rootfs.*', and that exist in the / of the volume. Ie:
> maxdepth=1.
Why not set the default subvolume to @rootfs then? (What `btrfs
subvolume set-default` does.)
That would also be useful for use with `systemd-gpt-auto-generator`.
It would not help with existing systems using @rootfs, but be
compatible with installations not using that.
> awk '{print $1}' < /MOUNTPOINT/etc/issue
> or perhaps
> grep 'ID\=debian' < /etc/os-release
It should also test for `/usr/lib/os-release` in case the symlink in
`/etc/` is not present.
Ansgar
Bug#1019009: console-setup-linux: missing compose sequences
Hello,
Jakub Wilk, le sam. 03 sept. 2022 09:45:50 +0200, a ecrit:
> Some compose sequences are not available on the console.
> For example, these two work in X:
>
> ' a = á
> s o = §
>
> But on the console, only the former works, even though "§" is supported
> by my font.
>From ckbcomp:
if ($charmap) {
my $file1 = "/etc/console-setup/compose.${charmap}.inc";
my $file2 = "$installdir/etc/console-setup/compose.${charmap}.inc";
if (-f $file1) {
system("cat $file1");
} elsif (-f $file2) {
system("cat $file2");
}
}
It looks as if the compose files are only included when a non-utf-8
charmap is used?
Perhaps additionally the per-locale compose file should be included?
(and by default, en_US.UTF-8)
Samuel
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
On 05/09/2022 at 10:46, Ansgar wrote: On Sat, 2022-09-03 at 21:06 -0400, Nicholas D Steeves wrote: grep 'ID\=debian' < /etc/os-release It should also test for `/usr/lib/os-release` in case the symlink in `/etc/` is not present. Neither will work with separate /usr.
