Hi, my system is affected as well (installed ubuntu as the only system using
LVM), so I would like to ask whether my understanding of the problem as follows
is correct.
I would also like to know whether bug reports have been filed regarding the
5)a) and 5)b) points, or if there has been any
As workaround I've added line GRUB_RECORDFAIL_TIMEOUT=0 to
/etc/default/grub
** Also affects: baltix-default-settings
Importance: Undecided
Status: New
** Changed in: baltix-default-settings
Status: New => Triaged
** Changed in: baltix-default-settings
Importance: Undecided
** Also affects: grub2 (Baltix)
Importance: Undecided
Status: New
** Changed in: grub2 (Baltix)
Milestone: None => baltix-18.04
** Changed in: grub2 (Baltix)
Importance: Undecided => Medium
** Changed in: grub2 (Baltix)
Status: New => Triaged
--
You received this bug
> > Maybe it's possible to load grubenv from esp partition? It will make
recordfail usable for all UEFI users regardless of FS.
> Yes, it's likely possible. It's actually something we've been
discussing, just need to figure out how to do it.
Is there progress on this?
--
You received this bug
Steve, Mathieu, any news on this issue?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815002
Title:
quick-boot-lvm.patch caused regression - menu always appear if root is
on Btrfs
To manage
> RussianNeuroMancer's argument is different; he argues that using Esc
to access the GRUB menu during UEFI boot DOES work reliably and
therefore we should default to booting fast.
Just in case, I want to note, that it works with 2.02+dfsg1-5ubuntu8 but
not with 2.02+dfsg1-5ubuntu8.2. Could you
@Steve Thanks so much for your post. Based on this, would you recommend
having a different partition just for boot, which would be a non-LVM
partition? If this is the preferred way, how big should I make it? I've
heard recommendations of 150MB, others say 250MB.
Also, should I repurpose my EFI
On Thu, Mar 07, 2019 at 05:04:51PM -, Felipe Castillo wrote:
> Any news on this issue? The suggested workaround, which is to modify the
> timeout is not even a workaround. It will indeed shorten the boot time,
> but in case of any errors or interruption to booting, I won't be able to
> see
Any news on this issue? The suggested workaround, which is to modify the
timeout is not even a workaround. It will indeed shorten the boot time, but in
case of any errors or interruption to booting, I won't be able to see the GRUB
menu on next boot.
This is such a regression, for years (as many
Is this discussion somewhere on public mail-list or some other
bugreport?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815002
Title:
quick-boot-lvm.patch caused regression - menu always appear if
Yes, it's likely possible. It's actually something we've been
discussing, just need to figure out how to do it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815002
Title:
quick-boot-lvm.patch
> but if they're all the same kind (all Dell, all AMI, etc.) then it
might not be a good sample
All three is different: HP Elite x2 1013 G3, Dell Venue 8 Pro 5855 and
Acer Aspire Switch Alpha 12 SA5-271. Besides this three, again, no such
issue on other devices, as mentioned in Comment #10
I'm not convinced the keypress is 100% reliable. It does get better all
the time, but there are still systems on which it's just not possible to
get it working reliably, and sometimes not at all - you'll press
consistantly "too late" or "to early" and GRUB won't notice, so you
won't get the menu.
> Under UEFI, there is no way for grub to detect a modifier key being held
> down; instead of holding shift at boot to get to the menu, you have to press
> the shift key at the right moment.
> And you will never reliably get the boot menu.
Press Esc when GRUB2 gray screen appear is reliable way
** Changed in: grub2 (Ubuntu)
Status: Confirmed => Opinion
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815002
Title:
quick-boot-lvm.patch caused regression - menu always appear if root is
On February 15, 2019 4:08:36 AM PST, RussianNeuroMancer
<1815...@bugs.launchpad.net> wrote:
>> Nevertheless, this configuration does NOT reliably allow the user to
>reach the boot menu with the default timeout of 0.
>
>Could you please clarify under which circumstances this configuration
>does
Steve, with all respect, If possible, can you answer question in the end
of this message? This is critical question because if you doesn't have
answer that mean quick-boot-lvm.patch introduced regression for affected
devices without keyboard for no single good reason. You said:
> Nevertheless,
** Changed in: grub2 (Ubuntu)
Status: Confirmed => Opinion
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815002
Title:
quick-boot-lvm.patch caused regression - menu always appear if root is
Hey, all the time I'm performing a rebooting my remote servers I should
wait 30 sec more to connect to them. This is not normall and never been
before. It shoud be optional: who needs it to appear at each boot, let
him turn it on, but it not should be the default behaviour.
--
You received this
** Changed in: grub2 (Ubuntu)
Status: Invalid => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815002
Title:
quick-boot-lvm.patch caused regression - menu always appear if root is
> Nevertheless, this configuration does NOT reliably allow the user to
reach the boot menu with the default timeout of 0.
Could you please clarify under which circumstances this configuration
does not reliably allow user reach boot menu? I asking because I never
seen situation where this menu
The bug went unnoticed because UEFI plus /boot on btrfs is a corner case
that is not widely used by the Ubuntu developers. Nevertheless, this
configuration does NOT reliably allow the user to reach the boot menu
with the default timeout of 0. It is more important to be reliable by
default than
> therefore we cannot default to a timeout of zero on UEFI systems when
grub is installed to btrfs.
How that was not the case for eight years?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815002
Tested on bionic:
mkfs.btrfs /dev/vda2
mount /dev/vda2 /mnt
cp -a /boot/* /mnt/
umount /mnt
mount /dev/vda2 /mnt
grub-install vda
update-grub
reboot
- Boot to the grub prompt and hit 'c'
grub> save_env timeout_style
error: sparse file not allowed
grub>
grub does not support writes to btrfs;
Also affected by this with BTRFS filesystem on EFI. The patch which
introduced the behavior change was titled quick-boot-lvm.patch, not
slow-boot-btrfs.patch ;-)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I am booting from MBR/GPT and Grub menu also appears all the time with
30 sec. timeout. Definitely some kind of ridiculous bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815002
Title:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: grub2 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815002
Title:
> As discussed in bug #1814403, this is by design.
Disagree. Mathieu mentioned in Comment #31 of bug #1814403:
> When your system doesn't boot correctly through the kernel however, it
would likely not show the menu without this fix -- you'd have no way to
switch back to a working kernel,
If you are booting via UEFI and your /boot is on btrfs then grub has
detected that /boot/grub/env is not writable from within grub and
therefore the boot menu is shown with a delay. As discussed in bug
#1814403, this is by design.
** Changed in: grub2 (Ubuntu)
Status: New => Invalid
--
Additional information: all affected devices boot via grub-efi.
** This bug is no longer a duplicate of bug 1814403
Latest update causes 30 sec. menu delay timeout
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
*** This bug is a duplicate of bug 1814403 ***
https://bugs.launchpad.net/bugs/1814403
** This bug has been marked a duplicate of bug 1814403
Latest update causes 30 sec. menu delay timeout
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
31 matches
Mail list logo
