Just experimented with a "clean" Ubuntu system that had grub-efi-
amd64-signed. To get the prompt for the efi partitions I had to call
dpkg-reconfigure shim-signed. After that it seemed to work OK.
I wish I knew where all this was documented.
--
You received this bug notification because you
** Tags added: hwcert-server
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466150
Title:
grub-install breaks when ESP is on raid
To manage notifications about this bug go to:
Corresponding bug report on Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765740
This Ubuntu support for multiple ESPs has not been upstreamed to Debian
Bullseye. Is someone working on upstreaming to Debian? I hope so!
** Bug watch added: Debian Bug tracker #765740
I had some problems when using grub-efi-amd64-signed rather than grub-
efi-amd64. Unfortunately not consistent enough to create a coherent bug
report. A number of times I ended up dropping into grub command line.
That seemed not to happen with the unsigned version.
--
You received this bug
On Sat, Dec 05, 2020 at 06:05:29PM -, Georg Sauthoff wrote:
> I've just tested this and it works as described.
>
> However, grub-efi-amd64 wasn't installed on my freshly installed 20.04
> Ubuntu system.
>
> Installed was grub-efi-amd64-signed.
>
> And 'dpkg-reconfigure
Tony Middleton (@ximera) wrote
(https://bugs.launchpad.net/ubuntu/+source/grub-
installer/+bug/1466150/comments/36):
> Since focal the change I originally asked for at the beginning of this
thread has now been made. > If you set up multi efi partitions, not
raided, when you run "dpkg-reconfigure
I agree with Seth Arnold; assuming that the user won't make a mistake is
a recipe for disaster.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466150
Title:
grub-install breaks when ESP is on raid
On Mon, Nov 30, 2020 at 05:38:10PM -, John Robinson wrote:
> If the user knows she's building her ESP on RAID, she probably knows
> enough not to be writing to the RAID's constituent devices
> independently.
Given how many broken grub configurations there are in the world that
come out of the
@Rod Smith wrote:
> Assuming that the user knows enough to not do these things seems like an
> unwise assumption, IMHO.
If the user knows she's building her ESP on RAID, she probably knows
enough not to be writing to the RAID's constituent devices
independently.
--
You received this bug
@Georg Sauthoff wrote:
> Can you name _one_ UEFI implementation that actually does write to an
ESP?
Offhand, I don't know of an EFI that will write to the ESP
automatically; HOWEVER, there are cases when it can happen because of
user actions and/or EFI applications' operation. For instance:
*
Since focal the change I originally asked for at the beginning of this
thread has now been made. If you set up multi efi partitions, not
raided, when you run "dpkg-reconfigure grub-efi-amd64" the system asks
which efi partitions you wish to use. You can specify more than one and
it then
(This may have only been present on older firmware versions, though, as
I no longer see the behavior on a newer T30.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466150
Title:
grub-install
https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/
The UEFI on the Dell T30 I was testing on would write a "boot variable
cache" file to the ESP. :(
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The only reference I could find was
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Variable-
Runtime-Cache which hints at a "device storage" for variables...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Tom Reynolds (tomreyn) wrote (https://bugs.launchpad.net/ubuntu/+source
/grub-installer/+bug/1466150/comments/28):
> While installing ESP on top of mdadm (metadata version <= 1.0) RAID-1
is practically possible, supporting this is not: The UEFI specification
(version 2.8, sections 13.3.1.1,
> Modifying this line in /usr/lib/grub/grub-multi-install will allow the
grub pkg update to complete succesfully...
Where I can find this in Trusty? (14.04)
I need to upgrade my host to move forward, but with grub-install failing it's
nontrivial.
--
You received this bug notification because
Adding --no-nvram to grub-install
grub-install --efi-directory=$mntpoint --target=x86_64-efi --no-nvram
fixes this, the --no-nvram bypasses updating efi vars with efibootmgr
but this entries don't need to be modified after install and on every
grub pkg update.
Modifying this line in
Five years later: …
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466150
Title:
grub-install breaks when ESP is on raid
To manage notifications about this bug go to:
While installing ESP on top of mdadm (metadata version <= 1.0) RAID-1 is
practically possible, supporting this is not: The UEFI specification
(version 2.8, sections 13.3.1.1, 13.3.3) defines the ESP as a FAT32 file
system which is located (directly) on a GPT partition. While this does
not seem to
The way to make it work is to place the EFI on a separate GPT raided
partition, outside the LVM PV. Which I forgot about when I wrote the idea
earlier.
On 1 July 2019 8:54:49 am John Robinson <1466...@bugs.launchpad.net>
wrote:
> You can use 0.90 or 1.0 metadata. Both leave the partitions
Yes Jack it does. That's why you can use a "trick" with md raid 1 with
metadata 0.90 or 1.0, because those both result in having two (or more)
discs with ESP partitions which are readable and bootable by the EFI
BIOS.
This bug thread is more about making grub-install call efibootmgr
correctly to
I'm beginning to thing the problem is simply that the EFI System
Partition really does need to be a real partition, and not a logical
volume or part of a raid. It is not an issue with raid and fat32, it is
just that the ESP (/boot/efi) needs to be reached from the EFI firmware,
which doesn't know
You can use 0.90 or 1.0 metadata. Both leave the partitions underneath
looking like it has a simple (non-RAID) filesystem on each disc of a
mirror when the EFI or BIOS looks at the drives. I think that's what
they need to boot from, so I don't think there's any chance of booting
from a /boot/efi
> I have EFI partitions on both disks but it is not possible to RAID1 these
> as they are FAT32.
Actually it is possible to RAID1 FAT32. The problem is that the default
RAID format places a header at the front of the partition, which stuffs up
the boot loader. But if you use the 0.9.0 format
I'm having the same problem with a new Gentoo install, but with a twist.
I am using lvm2 with a vg of two whole disk pvs and raid1 lvs for /,
/boot, and /boot/efi. Since I'm not using mdadm, the script in comment
#18 doesn't work for me, and I'm not able to modify it for my case,
although I try a
I meant #18, sorry.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466150
Title:
grub-install breaks when ESP is on raid
To manage notifications about this bug go to:
I just upgraded my system yesterday, which meant an updated grub, which
meant grub-install was run again, which meant this happened to me again.
Now on Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-150-generic x86_64) with
grub2 2.02~beta2-36ubuntu3.22 and its dependencies. Then I found that
Alejandro
I had to configure my BIOS manually to point to both ESP partitions.
Installing new kernel is still a thrilling experience, but so far reboots were
smooth.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I wrote a not-so-little wrapper for efibootmgr to pretend grub-install
isn't broken:
# cd /bin
# mv efibootmgr efibootmgr.real
# ln -s efibootmgr.sh efibootmgr
efibootmgr.sh
---
#!/bin/sh
die() {
echo "$*" >&2
exit 1
}
run_device() {
local devdir="$1" label= label_set=
This might be the fix?
Handle partition name parsing and formatting for partitioned md
https://github.com/rhboot/efivar/commit/576f55b02d9ec478bd5157352c884e3543bcca58
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
# grub-install --recheck --no-floppy /dev/md0
Installing for x86_64-efi platform.
efibootmgr: option requires an argument -- 'd'
efibootmgr version 0.5.4
usage: efibootmgr [options]
…
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Then why it fails to install bootloader?… Even on 0.90 meta?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466150
Title:
grub-install breaks when ESP is on raid
To manage notifications about this
On 8/21/2018 12:29 PM, Mathieu Trudel-Lapierre wrote:
> This has to do with grub not grokking the metadata format on disk, which
> is avoidable by using metadata 0.90.
What? Grub understands all of the metadata formats.
--
You received this bug notification because you are a member of Ubuntu
All that patch would do is show a pretty error message earlier, not
actually make sure the problem is fixed -- upgrades would still fail;
installs would still fail on RAID.
This has to do with grub not grokking the metadata format on disk, which
is avoidable by using metadata 0.90.
--
You
There is a patch at https://savannah.gnu.org/bugs/?46805 , why not try
it ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466150
Title:
grub-install breaks when ESP is on raid
To manage
More and more people stumble upon this -
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1720572
** Bug watch added: GNU Savannah Bug Tracker #46805
http://savannah.gnu.org/bugs/?46805
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
** Tags added: id-5b16b1664f4c7a0f1fb8839f
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466150
Title:
grub-install breaks when ESP is on raid
To manage notifications about this bug go to:
** Package changed: grub2 (Ubuntu) => grub-installer (Ubuntu)
** Changed in: grub-installer (Ubuntu)
Importance: Low => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466150
Title:
I agree that the severity is incorrect. Whenever grub-install is run -
ie when the version of grub is upgraded - I end up with an unbootable
system. Yes, my trusty rescue disk sorts it out but that's not a
solution.
Referring to the comment above, I have two EFI entries, one for each
disk.
Just an FYI, this is still present in 16.04.4 which I just `apt-get
upgrade`d to. I have /boot/EFI on a md RAID1 with 1.0 metadata.
I'm not sure whether the severity is correct; as far as I could tell
when hacking about with the efibootmgr command, the process had removed
the 'ubuntu' boot entry
The bug is still reproducible in 16.04.2LTS. It is particularly funny
that the grub-install reports no errors in the end:
...
grub-install: info: copying `/usr/lib/shim/shimx64.efi.signed' ->
`/boot/efi/EFI/Ubuntu/shimx64.efi'.
grub-install: info: copying
Thanks for reporting this, AnrDaemon! I'm not shure where exactly the
issue is, probably grub script should be modified in a way that if it
detects that the ESP on the raid it looks into /proc/mdstat and iterates
the process with all the component devices. Or it should pass some extra
args to
ESP is also on RAID1 with 0.90 meta.
# mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Tue Aug 16 11:08:49 2016
Raid Level : raid1
Array Size : 266176 (259.98 MiB 272.56 MB)
Used Dev Size : 266176 (259.98 MiB 272.56 MB)
Raid Devices : 2
Total Devices :
Setting up linux-signed-generic-lts-xenial (4.4.0.47.34) ...
Setting up linux-libc-dev:amd64 (3.13.0-101.148) ...
Setting up shim-signed (1.19~14.04.1+0.8-0ubuntu2) ...
Installing for x86_64-efi platform.
efibootmgr: option requires an argument -- 'd'
efibootmgr version 0.5.4
usage: efibootmgr
Hi! I have same issue. We are running Ubuntu 16.04 on our servers,
/boot/efi is on /dev/md0 (which is raid1 metadata 0.90 array of 4 little
partitions, each on the beginning of one of the 4 disks)
System boots normally, but I believe that is because the EFI entries were
created before, when the
45 matches
Mail list logo
