[weasel@debian.org: Bug#858832: calls efibootmgr with invalid options]

[weasel@debian.org: Bug#858832: calls efibootmgr with invalid options]

[Colin Watson]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

I guess that the attached bug happens because grub_install_register_efi
is called on non-biosdisk-ish systems but uses
grub_util_biosdisk_get_osdev to get an OS device name for
efidir_grub_dev->disk, which isn't going to work so well.  I'm a bit
rusty here - would anyone care to venture a guess at suitable
replacement code that would work on devices other than biosdisk?

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]

[-- Attachment #2: Type: message/rfc822, Size: 10781 bytes --]

From: Peter Palfrader <weasel@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#858832: calls efibootmgr with invalid options
Date: Mon, 27 Mar 2017 12:24:16 +0000
Message-ID: <20170327122416.GA13201@sarek.noreply.org>

Package: grub-efi-arm64
Version: 2.02~beta3-5
Severity: serious
User: debian-admin@lists.debian.org
Usertags: needed-by-DSA-Team

On upgrading from jessie to stretch on our arm64 box acker.debian.org I
noticed this issue with grub-efi-arm64:


acker:~# apt-get install --reinstall grub-efi-arm64
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not upgraded.
Need to get 73.0 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://mirror.netcologne.de/debian stretch/main arm64 grub-efi-arm64 arm64 2.02~beta3-5 [73.0 kB]
Fetched 73.0 kB in 0s (603 kB/s)          
Preconfiguring packages ...
(Reading database ... 62883 files and directories currently installed.)
Preparing to unpack .../grub-efi-arm64_2.02~beta3-5_arm64.deb ...
Unpacking grub-efi-arm64 (2.02~beta3-5) over (2.02~beta3-5) ...
Setting up grub-efi-arm64 (2.02~beta3-5) ...
Installing for arm64-efi platform.
efibootmgr: option requires an argument -- 'd'
efibootmgr version 14
usage: efibootmgr [options]
        -a | --active         sets bootnum active
        -A | --inactive       sets bootnum inactive
        -b | --bootnum XXXX   modify BootXXXX (hex)
        -B | --delete-bootnum delete bootnum
        -c | --create         create new variable bootnum and add to bootorder
        -C | --create-only      create new variable bootnum and do not add to bootorder
        -D | --remove-dups      remove duplicate values from BootOrder
        -d | --disk disk       (defaults to /dev/sda) containing loader
        -r | --driver         Operate on Driver variables, not Boot Variables.
        -e | --edd [1|3|-1]   force EDD 1.0 or 3.0 creation variables, or guess
        -E | --device num      EDD 1.0 device number (defaults to 0x80)
        -g | --gpt            force disk with invalid PMBR to be treated as GPT
        -i | --iface name     create a netboot entry for the named interface
        -l | --loader name     (defaults to \EFI\redhat\grub.efi)
        -L | --label label     Boot manager display label (defaults to "Linux")
        -m | --mirror-below-4G t|f mirror memory below 4GB
        -M | --mirror-above-4G X percentage memory to mirror above 4GB
        -n | --bootnext XXXX   set BootNext to XXXX (hex)
        -N | --delete-bootnext delete BootNext
        -o | --bootorder XXXX,YYYY,ZZZZ,...     explicitly set BootOrder (hex)
        -O | --delete-bootorder delete BootOrder
        -p | --part part        (defaults to 1) containing loader
        -q | --quiet            be quiet
        -t | --timeout seconds  set boot manager timeout waiting for user input.
        -T | --delete-timeout   delete Timeout.
        -u | --unicode | --UCS-2  pass extra args as UCS-2 (default is ASCII)
        -v | --verbose          print additional information
        -V | --version          return version and exit
        -w | --write-signature  write unique sig to MBR if needed
        -y | --sysprep          Operate on SysPrep variables, not Boot Variables.
        -@ | --append-binary-args file  append extra args from file (use "-" for stdin)
        -h | --help             show help/usage
grub-install: error: efibootmgr failed to register the boot entry: Operation not permitted.
Failed: grub-install --target=arm64-efi  
WARNING: Bootloader is not properly installed, system may not be bootable
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.9.0-2-arm64
Found initrd image: /boot/initrd.img-4.9.0-2-arm64
Found linux image: /boot/vmlinuz-4.9.0-0.bpo.2-arm64
Found initrd image: /boot/initrd.img-4.9.0-0.bpo.2-arm64
Found linux image: /boot/vmlinuz-4.8.0-0.bpo.2-arm64
Found initrd image: /boot/initrd.img-4.8.0-0.bpo.2-arm64
Adding boot menu entry for EFI firmware configuration
done
acker:~# 

Cheers,
-- 
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

Re: [weasel@debian.org: Bug#858832: calls efibootmgr with invalid options]

[Andrei Borzenkov]

Link to the bug report would be helpful. I assume it contains actual
invocation with arguments, I do not see them in this mail.

On Mon, Mar 27, 2017 at 3:41 PM, Colin Watson <cjwatson@debian.org> wrote:
> I guess that the attached bug happens because grub_install_register_efi
> is called on non-biosdisk-ish systems but uses
> grub_util_biosdisk_get_osdev to get an OS device name for
> efidir_grub_dev->disk, which isn't going to work so well.  I'm a bit
> rusty here - would anyone care to venture a guess at suitable
> replacement code that would work on devices other than biosdisk?
>
> Thanks,
>
> --
> Colin Watson                                       [cjwatson@debian.org]
>
>
> ---------- Forwarded message ----------
> From: Peter Palfrader <weasel@debian.org>
> To: Debian Bug Tracking System <submit@bugs.debian.org>
> Cc:
> Bcc:
> Date: Mon, 27 Mar 2017 12:24:16 +0000
> Subject: Bug#858832: calls efibootmgr with invalid options
> Package: grub-efi-arm64
> Version: 2.02~beta3-5
> Severity: serious
> User: debian-admin@lists.debian.org
> Usertags: needed-by-DSA-Team
>
> On upgrading from jessie to stretch on our arm64 box acker.debian.org I
> noticed this issue with grub-efi-arm64:
>
>
> acker:~# apt-get install --reinstall grub-efi-arm64
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not upgraded.
> Need to get 73.0 kB of archives.
> After this operation, 0 B of additional disk space will be used.
> Get:1 http://mirror.netcologne.de/debian stretch/main arm64 grub-efi-arm64 arm64 2.02~beta3-5 [73.0 kB]
> Fetched 73.0 kB in 0s (603 kB/s)
> Preconfiguring packages ...
> (Reading database ... 62883 files and directories currently installed.)
> Preparing to unpack .../grub-efi-arm64_2.02~beta3-5_arm64.deb ...
> Unpacking grub-efi-arm64 (2.02~beta3-5) over (2.02~beta3-5) ...
> Setting up grub-efi-arm64 (2.02~beta3-5) ...
> Installing for arm64-efi platform.
> efibootmgr: option requires an argument -- 'd'
> efibootmgr version 14
> usage: efibootmgr [options]
>         -a | --active         sets bootnum active
>         -A | --inactive       sets bootnum inactive
>         -b | --bootnum XXXX   modify BootXXXX (hex)
>         -B | --delete-bootnum delete bootnum
>         -c | --create         create new variable bootnum and add to bootorder
>         -C | --create-only      create new variable bootnum and do not add to bootorder
>         -D | --remove-dups      remove duplicate values from BootOrder
>         -d | --disk disk       (defaults to /dev/sda) containing loader
>         -r | --driver         Operate on Driver variables, not Boot Variables.
>         -e | --edd [1|3|-1]   force EDD 1.0 or 3.0 creation variables, or guess
>         -E | --device num      EDD 1.0 device number (defaults to 0x80)
>         -g | --gpt            force disk with invalid PMBR to be treated as GPT
>         -i | --iface name     create a netboot entry for the named interface
>         -l | --loader name     (defaults to \EFI\redhat\grub.efi)
>         -L | --label label     Boot manager display label (defaults to "Linux")
>         -m | --mirror-below-4G t|f mirror memory below 4GB
>         -M | --mirror-above-4G X percentage memory to mirror above 4GB
>         -n | --bootnext XXXX   set BootNext to XXXX (hex)
>         -N | --delete-bootnext delete BootNext
>         -o | --bootorder XXXX,YYYY,ZZZZ,...     explicitly set BootOrder (hex)
>         -O | --delete-bootorder delete BootOrder
>         -p | --part part        (defaults to 1) containing loader
>         -q | --quiet            be quiet
>         -t | --timeout seconds  set boot manager timeout waiting for user input.
>         -T | --delete-timeout   delete Timeout.
>         -u | --unicode | --UCS-2  pass extra args as UCS-2 (default is ASCII)
>         -v | --verbose          print additional information
>         -V | --version          return version and exit
>         -w | --write-signature  write unique sig to MBR if needed
>         -y | --sysprep          Operate on SysPrep variables, not Boot Variables.
>         -@ | --append-binary-args file  append extra args from file (use "-" for stdin)
>         -h | --help             show help/usage
> grub-install: error: efibootmgr failed to register the boot entry: Operation not permitted.
> Failed: grub-install --target=arm64-efi
> WARNING: Bootloader is not properly installed, system may not be bootable
> Generating grub configuration file ...
> Found linux image: /boot/vmlinuz-4.9.0-2-arm64
> Found initrd image: /boot/initrd.img-4.9.0-2-arm64
> Found linux image: /boot/vmlinuz-4.9.0-0.bpo.2-arm64
> Found initrd image: /boot/initrd.img-4.9.0-0.bpo.2-arm64
> Found linux image: /boot/vmlinuz-4.8.0-0.bpo.2-arm64
> Found initrd image: /boot/initrd.img-4.8.0-0.bpo.2-arm64
> Adding boot menu entry for EFI firmware configuration
> done
> acker:~#
>
> Cheers,
> --
>                             |  .''`.       ** Debian **
>       Peter Palfrader       | : :' :      The  universal
>  https://www.palfrader.org/ | `. `'      Operating System
>                             |   `-    https://www.debian.org/
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: [weasel@debian.org: Bug#858832: calls efibootmgr with invalid options]

[Peter Palfrader]

On Mon, 27 Mar 2017, Andrei Borzenkov wrote:

> Link to the bug report would be helpful. I assume it contains actual
> invocation with arguments, I do not see them in this mail.

see https://bugs.debian.org/858832


-- 
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

Re: [weasel@debian.org: Bug#858832: calls efibootmgr with invalid options]

[Andrei Borzenkov]

27.03.2017 15:41, Colin Watson пишет:
> I guess that the attached bug happens because grub_install_register_efi
> is called on non-biosdisk-ish systems but uses
> grub_util_biosdisk_get_osdev to get an OS device name for
> efidir_grub_dev->disk, which isn't going to work so well.  I'm a bit
> rusty here - would anyone care to venture a guess at suitable
> replacement code that would work on devices other than biosdisk?
> 

"biosdisk" here means "firmware device", not necessary BIOS.

Where /boot/efi is located? Output of lsblk and "grub-probe -t device
/boot/efi".

Re: [weasel@debian.org: Bug#858832: calls efibootmgr with invalid options]

[Peter Palfrader]

On Mon, 27 Mar 2017, Andrei Borzenkov wrote:

> 27.03.2017 15:41, Colin Watson пишет:
> > I guess that the attached bug happens because grub_install_register_efi
> > is called on non-biosdisk-ish systems but uses
> > grub_util_biosdisk_get_osdev to get an OS device name for
> > efidir_grub_dev->disk, which isn't going to work so well.  I'm a bit
> > rusty here - would anyone care to venture a guess at suitable
> > replacement code that would work on devices other than biosdisk?
> > 
> 
> "biosdisk" here means "firmware device", not necessary BIOS.
> 
> Where /boot/efi is located? Output of lsblk and "grub-probe -t device
> /boot/efi".

} acker:~# df -h /boot/efi
} Filesystem      Size  Used Avail Use% Mounted on
} /dev/md2        953M  176K  953M   1% /boot/efi
} acker:~# cat /proc/mdstat 
} Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
} md1 : active (auto-read-only) raid1 sda3[0] sdb3[1]
}       979565888 blocks super 1.2 [2/2] [UU]
}       bitmap: 0/8 pages [0KB], 65536KB chunk
} 
} md0 : active raid1 sdb2[1] sda2[0]
}       19514368 blocks super 1.2 [2/2] [UU]
}       
} md2 : active raid1 sdb1[1] sda1[0]
}       975808 blocks super 1.0 [2/2] [UU]
}       
} unused devices: <none>
} acker:~# lsblk
} NAME                                 MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
} sda                                    8:0    0 953.9G  0 disk  
} ├─sda1                                 8:1    0   953M  0 part  
} │ └─md2                                9:2    0   953M  0 raid1 /boot/efi
} ├─sda2                                 8:2    0  18.6G  0 part  
} │ └─md0                                9:0    0  18.6G  0 raid1 /
} └─sda3                                 8:3    0 934.3G  0 part  
}   └─md1                                9:1    0 934.2G  0 raid1 
}     ├─vg0-swap                       253:0    0    16G  0 lvm   [SWAP]
}     ├─vg0-OLD--arm--conova--02--root 253:1    0    20G  0 lvm   
}     ├─vg0-OLD--arm--conova--02--lvm  253:2    0    20G  0 lvm   
}     ├─vg0-OLD--arm--conova--02--swap 253:3    0    90G  0 lvm   
}     ├─vg0-arm--conova--02--root      253:4    0    20G  0 lvm   
}     ├─vg0-arm--conova--02--lvm       253:5    0    20G  0 lvm   
}     └─vg0-arm--conova--02--swap      253:6    0    90G  0 lvm   
} sdb                                    8:16   0 953.9G  0 disk  
} ├─sdb1                                 8:17   0   953M  0 part  
} │ └─md2                                9:2    0   953M  0 raid1 /boot/efi
} ├─sdb2                                 8:18   0  18.6G  0 part  
} │ └─md0                                9:0    0  18.6G  0 raid1 /
} └─sdb3                                 8:19   0 934.3G  0 part  
}   └─md1                                9:1    0 934.2G  0 raid1 
}     ├─vg0-swap                       253:0    0    16G  0 lvm   [SWAP]
}     ├─vg0-OLD--arm--conova--02--root 253:1    0    20G  0 lvm   
}     ├─vg0-OLD--arm--conova--02--lvm  253:2    0    20G  0 lvm   
}     ├─vg0-OLD--arm--conova--02--swap 253:3    0    90G  0 lvm   
}     ├─vg0-arm--conova--02--root      253:4    0    20G  0 lvm   
}     ├─vg0-arm--conova--02--lvm       253:5    0    20G  0 lvm   
}     └─vg0-arm--conova--02--swap      253:6    0    90G  0 lvm   
} acker:~# grub-probe -t device /boot/efi
} /dev/md2

Cheers,
-- 
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

Re: [weasel@debian.org: Bug#858832: calls efibootmgr with invalid options]

[Andrei Borzenkov]

28.03.2017 09:34, Peter Palfrader пишет:
> } /dev/md2        953M  176K  953M   1% /boot/efi

Sorry, that's not going to work. Even assuming that grub can map from
Linux MD to underlying physical device + partition (as that is what
efibootmgr needs, we cannot simply pass /dev/md2 to it), this will
obviously fail unless metadata is 0.90 or 1.0 (and current mdadm default
is 1.2). And even if you are careful enough - EFI application is free to
write to ESP, so unless you have EFI driver for Linux MD it is no go to
try to mirror it, as you are never sure whether mirrors are identical
after boot. And if you have EFI driver for Linux MD you need to modify
efibootmgr to understand it.

We need to return better error message here to explain what happens
though, that's the actual bug.

The (IMHO) correct way to handle ESP redundancy is to call "grub-install
/path/to/first/ESP /path/to/second/ESP". I have half-finished patch
allowing this, but it will need distributions cooperation to actually be
useful.

Re: [weasel@debian.org: Bug#858832: calls efibootmgr with invalid options]

[Steve McIntyre]

On Tue, Mar 28, 2017 at 08:59:30PM +0300, Andrei Borzenkov wrote:
>28.03.2017 09:34, Peter Palfrader пишет:
>> } /dev/md2        953M  176K  953M   1% /boot/efi
>
>Sorry, that's not going to work. Even assuming that grub can map from
>Linux MD to underlying physical device + partition (as that is what
>efibootmgr needs, we cannot simply pass /dev/md2 to it), this will
>obviously fail unless metadata is 0.90 or 1.0 (and current mdadm default
>is 1.2). And even if you are careful enough - EFI application is free to
>write to ESP, so unless you have EFI driver for Linux MD it is no go to
>try to mirror it, as you are never sure whether mirrors are identical
>after boot. And if you have EFI driver for Linux MD you need to modify
>efibootmgr to understand it.

ACK, good catch.

>We need to return better error message here to explain what happens
>though, that's the actual bug.
>
>The (IMHO) correct way to handle ESP redundancy is to call "grub-install
>/path/to/first/ESP /path/to/second/ESP". I have half-finished patch
>allowing this, but it will need distributions cooperation to actually be
>useful.

More than happy to help with that - it's something I've been wanting
for a while.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross

Patch to support ESP redundancy [was: Re: [weasel@debian.org: Bug#858832: calls efibootmgr with invalid options]]

[Francesco Poli]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

On Tue, 28 Mar 2017 20:59:30 +0300 Andrei Borzenkov wrote:

[...]
> The (IMHO) correct way to handle ESP redundancy is to call "grub-install
> /path/to/first/ESP /path/to/second/ESP". I have half-finished patch
> allowing this, but it will need distributions cooperation to actually be
> useful.

Hello Andrei,
I stumbled upon this [message] of yours.

[message]: <https://bugs.debian.org/858832#35>

If I understand correctly, you are talking about the support for ESP
redundancy that I have been wanting since September 2015!

I wanted to prepare a patch to implement this support, but,
unfortunately, I haven't yet managed to find the time to do so.
My effort has not seen any progress since January 2016.
Please take a look at my [status update] (and maybe the thread that
followed).

[status update]: <https://lists.debian.org/debian-efi/2016/01/msg00016.html>

Does your half-finished patch address the exact need described in my
[status update]?
Please let me know, thanks for your time!

P.S.: Please note that I am not subscribed to grub-devel or to
debian-efi, hence please Cc me on replies. Thanks for your
understanding!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]