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
