Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
On Fri, Apr 25, 2014 at 09:07:25PM +0200, Kay Sievers wrote:
On Fri, Apr 25, 2014 at 8:25 PM, Julian Andres Klode j...@debian.org wrote:
The Debian kernels are configured
CONFIG_FAT_DEFAULT_IOCHARSET=utf8
which causes iocharset=utf8 to be the default here, rather than
iocharset=ascii. I can now
either work around that in the gummiboot package by one of
(1) unlink() and then rename()
(2) do a stupid glob() [Bb][Oo][Tt][Xx]64.[Ee][Ff][Ii] (and the same for
the rest of the path)
I don't think you'd like either of those upstream, so you might want to
change
the generator to pass iocharset=ascii. We do not (apart from me) use that
generator, though, so it won't help Debian -- we generate a fstab entry
during
system installation instead.
Are we sure that this is the expected kernel behaviour? Seems pretty
odd to be caused by the charset option:
With ascii all is fine:
# mount /dev/sda1 /boot -o iocharset=ascii
# touch /boot/EFI/A
# rm /boot/EFI/a
rm: remove regular empty file ‘/boot/EFI/a’? y
With UTF8 it breaks:
# mount /dev/sda1 /boot -o iocharset=utf8
# touch /boot/EFI/A
# rm /boot/EFI/a
rm: cannot remove ‘/boot/EFI/a’: No such file or directory
And it gets even more weird here:
All is fine:
[root@lon /]# touch /boot/EFI/a
[root@lon /]# touch /boot/EFI/A
This fails:
[root@lon /]# touch /boot/EFI/A
[root@lon /]# touch /boot/EFI/a
touch: cannot touch ‘/boot/EFI/a’: File exists
So I attached a -patch- workaround for this problem, or well, most instances
of it. It simply opens the directory EFI/Boot and checks for
an existing bootx64.efi in whatever case. If it finds one, it
uses that case, otherwise it uses lower-case (previous code
used uppercase, I can change that back, but this is a bit
shorter).
I also have a version that globs() the entire path and uses the first
match if it exists, but it's slightly longer. And most systems should
have EFI/Boot in that case anyway.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Please do not top-post if possible.
From 676b1f04015af0cf88327f8326b20d21f3445786 Mon Sep 17 00:00:00 2001
From: Julian Andres Klode j...@debian.org
Date: Tue, 3 Jun 2014 17:41:51 +0200
Subject: [PATCH] setup: Normalize the boot*.efi to the case used by the file
system
Ensure that bootx64.efi and friends use the same case as the already
existing file to ensure that we correctly replace it on systems where
the ESP is mounted using utf8 (such as Debian).
This also changes the default case of these files to lower case as
it completely replaces the strupper function.
Bug-Debian: http://bugs.debian.org/745280
---
src/setup/setup.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/src/setup/setup.c b/src/setup/setup.c
index 0cfaccf..cb96a85 100644
--- a/src/setup/setup.c
+++ b/src/setup/setup.c
@@ -682,13 +682,33 @@ finish:
return r;
}
-static char* strupper(char *s) {
-char *p;
+static int normalize_filename_case(char *name) {
+char *base_start;
+char *base;
+DIR *d;
+struct dirent *de;
+
+base_start = strrchr(name, '/');
+base = base_start + 1;
+
+*base_start = 0;
+d = opendir(name);
+*base_start = '/';
+
+if (d == NULL)
+return -errno;
-for (p = s; *p; p++)
-*p = toupper(*p);
+while ((de = readdir(d))) {
+/* Normalize (only) the base name of the given path */
+if (strcasecmp(de-d_name, base) == 0) {
+strcpy(base, de-d_name);
+break;
+}
+}
-return s;
+closedir(d);
+
+return 0;
}
static int mkdir_one(const char *prefix, const char *suffix) {
@@ -765,7 +785,7 @@ static int copy_one_file(const char *esp_path, const char *name, bool force) {
r = -ENOMEM;
goto finish;
}
-strupper(strrchr(v, '/') + 1);
+normalize_filename_case(v);
k = copy_file(p, v, force);
if (k 0 r == 0) {
--
2.0.0.rc4
Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
Hi Kay, I received the following bug report in Debian about gummiboot. On Sun, Apr 20, 2014 at 10:04:23AM +0200, Philipp Kern wrote: Package: gummiboot Version: 44-1 Severity: important gummiboot fails to install if there is a preexisting EFI boot loader in the fallback location (e.g. after a successful installation of Windows): pkern@simplex ~ % sudo gummiboot install --path=/boot/efi Created /boot/efi/EFI/gummiboot. Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/efi/EFI/gummiboot/gummibootx64.efi. Failed to rename /boot/efi/EFI/Boot/BOOTX64.EFI~ to /boot/efi/EFI/Boot/BOOTX64.EFI: File exists As we can see here, it tries to do an atomic replace of the boot loader, but this fails because /boot/efi (we need to use /boot/efi in Debian instead of /boot, because our kernel images are installed in /boot) is FAT32 and that does not seem to allow replacements. (Same for update, which is called from the postinst.) pkern@simplex ~ % find /boot/efi/EFI/Boot /boot/efi/EFI/Boot /boot/efi/EFI/Boot/bootx64.efi The failure of »gummiboot update« is ignored in the postinst and hence ignores other failure cases upon installation as well. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Please do not top-post if possible. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
On Fri, Apr 25, 2014 at 3:51 PM, Julian Andres Klode j...@debian.org wrote: I received the following bug report in Debian about gummiboot. On Sun, Apr 20, 2014 at 10:04:23AM +0200, Philipp Kern wrote: Package: gummiboot Version: 44-1 Severity: important gummiboot fails to install if there is a preexisting EFI boot loader in the fallback location (e.g. after a successful installation of Windows): pkern@simplex ~ % sudo gummiboot install --path=/boot/efi Created /boot/efi/EFI/gummiboot. Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/efi/EFI/gummiboot/gummibootx64.efi. Failed to rename /boot/efi/EFI/Boot/BOOTX64.EFI~ to /boot/efi/EFI/Boot/BOOTX64.EFI: File exists As we can see here, it tries to do an atomic replace of the boot loader, but this fails because /boot/efi (we need to use /boot/efi in Debian instead of /boot, because our kernel images are installed in /boot) is FAT32 and that does not seem to allow replacements. It works just fine here on a FAT partition. I have no idea why it would go wrong. # blkid /dev/sda1 /dev/sda1: LABEL=EFI UUID=9B5C-C8BD TYPE=vfat PARTLABEL=ESP PARTUUID=06a08fe0-82e8-4171-b00e-5afc13668ab4 # strace -e rename gummiboot install --path=/boot rename(/boot/EFI/gummiboot/gummibootx64.efi~, /boot/EFI/gummiboot/gummibootx64.efi) = 0 Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/gummiboot/gummibootx64.efi. rename(/boot/EFI/Boot/BOOTX64.EFI~, /boot/EFI/Boot/BOOTX64.EFI) = 0 Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/Boot/BOOTX64.EFI. Created EFI boot entry Linux Boot Manager. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
On Fri, Apr 25, 2014 at 06:43:07PM +0200, Kay Sievers wrote: On Fri, Apr 25, 2014 at 3:51 PM, Julian Andres Klode j...@debian.org wrote: I received the following bug report in Debian about gummiboot. On Sun, Apr 20, 2014 at 10:04:23AM +0200, Philipp Kern wrote: Package: gummiboot Version: 44-1 Severity: important gummiboot fails to install if there is a preexisting EFI boot loader in the fallback location (e.g. after a successful installation of Windows): pkern@simplex ~ % sudo gummiboot install --path=/boot/efi Created /boot/efi/EFI/gummiboot. Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/efi/EFI/gummiboot/gummibootx64.efi. Failed to rename /boot/efi/EFI/Boot/BOOTX64.EFI~ to /boot/efi/EFI/Boot/BOOTX64.EFI: File exists As we can see here, it tries to do an atomic replace of the boot loader, but this fails because /boot/efi (we need to use /boot/efi in Debian instead of /boot, because our kernel images are installed in /boot) is FAT32 and that does not seem to allow replacements. It works just fine here on a FAT partition. I have no idea why it would go wrong. It seems to be a matter of lower vs. uppercase, for example: $ ls -l EFI/Boot/ -rwxr-xr-x 1 root root 78107 Apr 11 00:25 bootx64.efi # mv y EFI/Boot/BOOTX64.efi mv: cannot move 'y' to 'EFI/Boot/BOOTX64.efi': File exists But: # mv y EFI/Boot/bootx64.efi works as intended. Strace shows the difference: rename(y, EFI/Boot/BOOTX64.efi) = -1 EEXIST (File exists) rename(y, EFI/Boot/bootx64.efi) = 0 It does work in some cases though. I'm not entirely sure what is broken here. The file system is mounted in utf8 which produces the warning [2.998918] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! which probably causes this. I'm not sure why it is mounted with utf-8, though. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Please do not top-post if possible. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
On Fri, Apr 25, 2014 at 7:10 PM, Julian Andres Klode j...@debian.org wrote: On Fri, Apr 25, 2014 at 06:43:07PM +0200, Kay Sievers wrote: On Fri, Apr 25, 2014 at 3:51 PM, Julian Andres Klode j...@debian.org wrote: I received the following bug report in Debian about gummiboot. On Sun, Apr 20, 2014 at 10:04:23AM +0200, Philipp Kern wrote: Package: gummiboot Version: 44-1 Severity: important gummiboot fails to install if there is a preexisting EFI boot loader in the fallback location (e.g. after a successful installation of Windows): pkern@simplex ~ % sudo gummiboot install --path=/boot/efi Created /boot/efi/EFI/gummiboot. Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/efi/EFI/gummiboot/gummibootx64.efi. Failed to rename /boot/efi/EFI/Boot/BOOTX64.EFI~ to /boot/efi/EFI/Boot/BOOTX64.EFI: File exists As we can see here, it tries to do an atomic replace of the boot loader, but this fails because /boot/efi (we need to use /boot/efi in Debian instead of /boot, because our kernel images are installed in /boot) is FAT32 and that does not seem to allow replacements. It works just fine here on a FAT partition. I have no idea why it would go wrong. It seems to be a matter of lower vs. uppercase, for example: $ ls -l EFI/Boot/ -rwxr-xr-x 1 root root 78107 Apr 11 00:25 bootx64.efi # mv y EFI/Boot/BOOTX64.efi mv: cannot move 'y' to 'EFI/Boot/BOOTX64.efi': File exists But: # mv y EFI/Boot/bootx64.efi works as intended. Strace shows the difference: rename(y, EFI/Boot/BOOTX64.efi) = -1 EEXIST (File exists) rename(y, EFI/Boot/bootx64.efi) = 0 It does work in some cases though. I'm not entirely sure what is broken here. The file system is mounted in utf8 which produces the warning [2.998918] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! which probably causes this. I'm not sure why it is mounted with utf-8, though. I have it mounted without any specific options: http://cgit.freedesktop.org/systemd/systemd/tree/src/efi-boot-generator/efi-boot-generator.c#n108 which results in: rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
On Fri, Apr 25, 2014 at 08:11:10PM +0200, Kay Sievers wrote: On Fri, Apr 25, 2014 at 7:10 PM, Julian Andres Klode j...@debian.org wrote: On Fri, Apr 25, 2014 at 06:43:07PM +0200, Kay Sievers wrote: On Fri, Apr 25, 2014 at 3:51 PM, Julian Andres Klode j...@debian.org wrote: I received the following bug report in Debian about gummiboot. On Sun, Apr 20, 2014 at 10:04:23AM +0200, Philipp Kern wrote: Package: gummiboot Version: 44-1 Severity: important gummiboot fails to install if there is a preexisting EFI boot loader in the fallback location (e.g. after a successful installation of Windows): pkern@simplex ~ % sudo gummiboot install --path=/boot/efi Created /boot/efi/EFI/gummiboot. Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/efi/EFI/gummiboot/gummibootx64.efi. Failed to rename /boot/efi/EFI/Boot/BOOTX64.EFI~ to /boot/efi/EFI/Boot/BOOTX64.EFI: File exists As we can see here, it tries to do an atomic replace of the boot loader, but this fails because /boot/efi (we need to use /boot/efi in Debian instead of /boot, because our kernel images are installed in /boot) is FAT32 and that does not seem to allow replacements. It works just fine here on a FAT partition. I have no idea why it would go wrong. It seems to be a matter of lower vs. uppercase, for example: $ ls -l EFI/Boot/ -rwxr-xr-x 1 root root 78107 Apr 11 00:25 bootx64.efi # mv y EFI/Boot/BOOTX64.efi mv: cannot move 'y' to 'EFI/Boot/BOOTX64.efi': File exists But: # mv y EFI/Boot/bootx64.efi works as intended. Strace shows the difference: rename(y, EFI/Boot/BOOTX64.efi) = -1 EEXIST (File exists) rename(y, EFI/Boot/bootx64.efi) = 0 It does work in some cases though. I'm not entirely sure what is broken here. The file system is mounted in utf8 which produces the warning [2.998918] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! which probably causes this. I'm not sure why it is mounted with utf-8, though. I have it mounted without any specific options: http://cgit.freedesktop.org/systemd/systemd/tree/src/efi-boot-generator/efi-boot-generator.c#n108 which results in: rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro The Debian kernels are configured CONFIG_FAT_DEFAULT_IOCHARSET=utf8 which causes iocharset=utf8 to be the default here, rather than iocharset=ascii. I can now either work around that in the gummiboot package by one of (1) unlink() and then rename() (2) do a stupid glob() [Bb][Oo][Tt][Xx]64.[Ee][Ff][Ii] (and the same for the rest of the path) I don't think you'd like either of those upstream, so you might want to change the generator to pass iocharset=ascii. We do not (apart from me) use that generator, though, so it won't help Debian -- we generate a fstab entry during system installation instead. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Please do not top-post if possible. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
On Fri, Apr 25, 2014 at 8:25 PM, Julian Andres Klode j...@debian.org wrote: The Debian kernels are configured CONFIG_FAT_DEFAULT_IOCHARSET=utf8 which causes iocharset=utf8 to be the default here, rather than iocharset=ascii. I can now either work around that in the gummiboot package by one of (1) unlink() and then rename() (2) do a stupid glob() [Bb][Oo][Tt][Xx]64.[Ee][Ff][Ii] (and the same for the rest of the path) I don't think you'd like either of those upstream, so you might want to change the generator to pass iocharset=ascii. We do not (apart from me) use that generator, though, so it won't help Debian -- we generate a fstab entry during system installation instead. Are we sure that this is the expected kernel behaviour? Seems pretty odd to be caused by the charset option: With ascii all is fine: # mount /dev/sda1 /boot -o iocharset=ascii # touch /boot/EFI/A # rm /boot/EFI/a rm: remove regular empty file ‘/boot/EFI/a’? y With UTF8 it breaks: # mount /dev/sda1 /boot -o iocharset=utf8 # touch /boot/EFI/A # rm /boot/EFI/a rm: cannot remove ‘/boot/EFI/a’: No such file or directory And it gets even more weird here: All is fine: [root@lon /]# touch /boot/EFI/a [root@lon /]# touch /boot/EFI/A This fails: [root@lon /]# touch /boot/EFI/A [root@lon /]# touch /boot/EFI/a touch: cannot touch ‘/boot/EFI/a’: File exists -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
[Dropping pkern (bug submitter) from CC] On Fri, Apr 25, 2014 at 09:07:25PM +0200, Kay Sievers wrote: On Fri, Apr 25, 2014 at 8:25 PM, Julian Andres Klode j...@debian.org wrote: The Debian kernels are configured CONFIG_FAT_DEFAULT_IOCHARSET=utf8 which causes iocharset=utf8 to be the default here, rather than iocharset=ascii. I can now either work around that in the gummiboot package by one of (1) unlink() and then rename() (2) do a stupid glob() [Bb][Oo][Tt][Xx]64.[Ee][Ff][Ii] (and the same for the rest of the path) I don't think you'd like either of those upstream, so you might want to change the generator to pass iocharset=ascii. We do not (apart from me) use that generator, though, so it won't help Debian -- we generate a fstab entry during system installation instead. Are we sure that this is the expected kernel behaviour? Seems pretty odd to be caused by the charset option: The tables for UTF-8 for translating lower - upper case are too large, so they did not support translating that in the kernel, at least that's what one of our kernel maintainers wrote. There's also an utf8 option that can be used with a non-utf8 charset, i'm not sure how that works, though: iocharset=iso8859-1,utf8 -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Please do not top-post if possible. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745280: fails to cope properly with an existing boot loader
Package: gummiboot Version: 44-1 Severity: important gummiboot fails to install if there is a preexisting EFI boot loader in the fallback location (e.g. after a successful installation of Windows): pkern@simplex ~ % sudo gummiboot install --path=/boot/efi Created /boot/efi/EFI/gummiboot. Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/efi/EFI/gummiboot/gummibootx64.efi. Failed to rename /boot/efi/EFI/Boot/BOOTX64.EFI~ to /boot/efi/EFI/Boot/BOOTX64.EFI: File exists (Same for update, which is called from the postinst.) pkern@simplex ~ % find /boot/efi/EFI/Boot /boot/efi/EFI/Boot /boot/efi/EFI/Boot/bootx64.efi The failure of »gummiboot update« is ignored in the postinst and hence ignores other failure cases upon installation as well. -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (900, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gummiboot depends on: ii libblkid1 2.20.1-5.3 ii libc6 2.18-4 Versions of packages gummiboot recommends: ii systemd 204-8~bpo70+1 gummiboot suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
