Bug 1094489 - add support for btrfs in grub2 on /boot
Summary: add support for btrfs in grub2 on /boot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: grubby
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
: 864198 (view as bug list)
Depends On:
Blocks: 689509 864198 989644 1039124 1418336 F28BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2014-05-05 19:44 UTC by Gene Czarcinski
Modified: 2020-02-19 23:05 UTC (History)
19 users (show)

Fixed In Version: grubby-8.40-10.fc28 grubby-8.40-8.fc27
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-27 20:04:37 UTC
Type: Bug


Attachments (Terms of Use)
v1: add support for btrfs in grub2 (26.37 KB, patch)
2014-05-05 19:44 UTC, Gene Czarcinski
no flags Details | Diff
Enable DEBUG (538 bytes, patch)
2014-05-05 19:45 UTC, Gene Czarcinski
no flags Details | Diff
screenshot of kernel panic from attempt to boot system with /boot as btrfs subvol (32.47 KB, image/png)
2014-05-06 23:56 UTC, Adam Williamson
no flags Details
grub.cfg from install where boot fails (2.79 KB, text/plain)
2014-05-07 00:01 UTC, Adam Williamson
no flags Details
add code to validate grub2 entry (4.86 KB, patch)
2014-06-08 13:16 UTC, Gene Czarcinski
no flags Details | Diff
v2 add support for btrfs when grub2 is bootloader (9.56 KB, patch)
2014-06-08 13:18 UTC, Gene Czarcinski
no flags Details | Diff
v2 add lots of debugging (13.97 KB, patch)
2014-06-08 13:19 UTC, Gene Czarcinski
no flags Details | Diff
v2 add code to validate a grub2 entry (4.83 KB, patch)
2014-06-08 14:34 UTC, Gene Czarcinski
no flags Details | Diff
v2.1 add support for btrfs when grub2 is bootloader (11.63 KB, patch)
2014-06-10 04:05 UTC, Gene Czarcinski
no flags Details | Diff
v2.1 add compile time enabled debugging code for btrfs (13.63 KB, patch)
2014-06-10 04:06 UTC, Gene Czarcinski
no flags Details | Diff
v2.1 add tests for btrfs support (52.86 KB, patch)
2014-06-10 04:07 UTC, Gene Czarcinski
no flags Details | Diff
v2.2 add support for btrfs when grub2 is bootloader (11.63 KB, patch)
2014-06-10 07:10 UTC, Gene Czarcinski
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Github rhinstaller grubby issues 22 0 None None None Never
Red Hat Bugzilla 1418336 0 unspecified CLOSED Anaconda won't accept /boot on btrfs subvol, installation is impossible on my machine 2021-02-22 00:41:40 UTC

Internal Links: 1418336

Description Gene Czarcinski 2014-05-05 19:44:38 UTC
Created attachment 892670 [details]
v1: add support for btrfs in grub2

Description of problem:
With grub2-2.02 and os-prober-1.58-5 in rawhide, only grubby support for booting of /boot on a subvol of a directory on a rootfs ("/") on a subvol is blocking.

No more!  Attached is the patch to provide that support.

This patch adds getSubvolPrefix() for handling a btrfs subvol
prefix on the filenames for grub2.  If get_Root_Specifier() results
in a NULL rootspec, then getSubvolPrefix() is executed to extract any
btrfs subvol prefix.  With this modification, booting off
/boot on a btrfs subvol is supported.

To determine if booting is to be performed off a btrfs volume
or subvolume, the lines of the entry are scanned to detect
if "insmod btrfs" is present.  If it is, then btrfs is assumed.

If the kernel filename includes only one slash, then there is
no btrfs prefix.  Otherwise, the first part defined by "/../"
will be the btrfs prefix if booting btrfs.  Unless, of course,
there are 2 slashes in the filename but bootPrefix is zero length
in which case we are booting off a btrfs volume!

Besides the kernel, the subvol prefix must also be on the
initrd filename.  The subvol prefix for initrd is based on
the entry's kernel's filename.  Note that the lines of
the entry must be scanned to determine if we are booting on
btrfs.

Code was added to addLine(tmpl() so that the subvol prefix not added
for an initrd since updateInitrd() does that already.

Besides the code needed to provide the functionality, this patch
includes debugging code to support the implementation.  This
debugging code will have no effect unless DEBUG is enabled.

This patch also includes a couple of minor fixes.  In findTemplate()
the saved_entry code is fixed so it works.

Add code findValidEntryByIndex() to test for the
comment "### END /etc/grub.d/10_linux ###" indicating that the
previous entry was the last "valid" entry.  This prevents findTemplate()
from looking at entries created by 30_os-prober and 40_custom.

Comment 1 Gene Czarcinski 2014-05-05 19:45:48 UTC
Created attachment 892671 [details]
Enable DEBUG

Lots of dbPrintf() message to aid debugging btrfs support.

Comment 2 Adam Williamson 2014-05-06 19:04:21 UTC
http://koji.fedoraproject.org/koji/taskinfo?taskID=6820037 is a Rawhide scratch build with the patch applied, for testing. I'll spin up a live image that includes it and run it through a few tests.

Comment 3 Gene Czarcinski 2014-05-06 21:00:58 UTC
Thank you.

I put an email out to test@lists.fedoraproject.org advertising the patch and asking for an volunteers but this build is a better source.

This is OK for testing if nothing currently working breaks but to really do anything with btrfs, you need an updates image for anaconda such as the ones I have on ftp://czarc.net

Comment 4 Adam Williamson 2014-05-06 23:10:15 UTC
oh, you did one already? I was about to do that next. That'll be the ones in ftp://czarc.net/pub/updates/ , I guess?

Comment 5 Adam Williamson 2014-05-06 23:55:31 UTC
So I built a live image with my patched grubby build, it also has os-prober 1.58-5. I applied ftp://czarc.net/pub/updates/anaconda-21.35-1a-updates.img , and used custom partitioning to create a layout where /boot was a btrfs subvol .

Installation was successful, but attempting to boot the installed system produces a kernel panic. Screenshot of the VM will be attached.

Comment 6 Adam Williamson 2014-05-06 23:56:18 UTC
Created attachment 893044 [details]
screenshot of kernel panic from attempt to boot system with /boot as btrfs subvol

Comment 7 Adam Williamson 2014-05-07 00:01:55 UTC
Created attachment 893046 [details]
grub.cfg from install where boot fails

Comment 8 Chris Murphy 2014-05-07 04:28:22 UTC
(In reply to Adam Williamson from comment #6 & #7)
The grub.cfg is malformed. It only contains a linux16 entry, no initrd entry. I'm not sure why it's using linux16 instead of linux, or why it doesn't have an initrd.

My recollection during F20 testing is that there was a change in anaconda, possibly threading, where it would call grub2-mkconfig before dracut finished building the initramfs and hence we get a grub.cfg routinely without an initrd line. But then grubby seemed to fix this problem for /boot on ext4 but doesn't fix it on Btrfs. So grubby is covering up an anaconda bug, grub2-mkconfig shouldn't be called until dracut is complete.

Comment 9 Gene Czarcinski 2014-05-07 04:42:46 UTC
Adam, first of all, you need to have DEBUG enabled so that the spue of messages can give some idea of what is going on.  The messages will be in anaconda.log for an install.

Second, I do not have your exact build but I was able to use a rawhide root.iso (both x86_64 and i686) top install with updates= pointed to one of my update images.

I looked at the koji cited but I cannot seems to find the related src.rpm so that I could see exactly what was included.

I have had some "strange" situations where things happened differently when DEBUG was enabled or not.  I will run a test on my side with DEBUG not enabled for a rawhide install.

Comment 10 Gene Czarcinski 2014-05-07 05:56:20 UTC
Adam, bad news ... I cannot duplicate your problem.

I just did a x86_64 qemu-kvm gui install using the rawhide root.iso with anaconda 21.34-1, my updates image anaconda-21.35-1a-updates.img, and the non-debug grubby in my local rpm repository which I added to the install.  Installed with no problems and booted with no problems with /, /home and /boot on btrfs subvols.

I selected a lxde desktop since this is easier to run on a virtual system.

BTW, the linux16/initrd16 is something new with grub2-2.02 and has something to do with the boot protocol ... I don't understand it, it does work, and the grub2 folks seem to believe it is important.  Also, if you have grub2-2.02 installed but an old format grub.cfg file with linux/initrd, things still work just fine.

Comment 11 Gene Czarcinski 2014-05-07 12:16:25 UTC
And now I am having another problem with anaconda.  When I attempt install using either i386 or x86_64 boot.iso with anaconda-21.35-1, I get a blank (gray) screen with nothing on it.

What is really strange is that I installed with these boot.iso earlier and it worked fine.

BTW, the boot parameter inst.debug=1 does not work.

Comment 12 Gene Czarcinski 2014-05-07 19:18:20 UTC
Strange problem with anaconda.  The patches to pyanaconda/bootloader.py and grubby.c are working but is "now" this very long pause entering and leaving custom disk configuration.  The virtual system is not loocked up in that you can switch to a virtual terminal.  The vcpu looks to be about 35% buzy so something is out there "spinning".  Then again, I was giving a livusb install a try (has patched anaconda and the updated grubby AND IT STARTED WORKING as normal again???

Anyway, if there is some way you could get me access to the iso image you had, maybe I can figure out what is wrong.

Comment 13 Gene Czarcinski 2014-05-07 20:48:33 UTC
OK, I created a small LXDE livecd and then installed that on a USB flash drive.  Booted the live image and check to make sure all of the packages and repos were correct.  Then did a live install.  That worked but when I rebooted I got boot errors.

I rebooted the live USB, mounted all of the subvols and chroot'ed into the system.  I then attempted to run grub2-install and grub2-mkconfig ... both errored out.

I then rebooted anaconda in rescue mode, chrooted in, ran both grub2-install and grub2-mkconfig successfully.

Reboot and it worked just fine.

BTW, I checked anaconda.program.log locatinging the execution of "new-kernel-pkg" and, sure enough. there were the huge number of grubby messages ending with a successful update.

I have not seen anything like this from a boot.iso.  I am now building a "full monty" rawhide DVD iso with patched anaconda and updated grubby.

Oh, and even better, the liveUSB had a "old" kernel [new kernel just installed in rawhide] so I got a chance to test the install ... worked great.

Comment 14 Adam Williamson 2014-05-07 23:01:36 UTC
Scratch build of a grubby package with the debugging patch applied failed: http://kojipkgs.fedoraproject.org//work/tasks/4236/6824236/build.log . I can probably disable 'make check' to make it work, but interesting that just enabling debug mode apparently causes the tests to fail.

Comment 15 Gene Czarcinski 2014-05-08 03:55:37 UTC
Sorry about that.  Should have mentioned that previously.  When DEBUG is enabled, there is some change to the output of grubby which causes some tests to fail.  You inded need to disable #%check when DEBUG is enabled.

When you do get something built and another iso built, is there a way I could get hold of that iso so that I could try and see what is happening?

I have a live iso I built myself but that will not be the same as yours.

Comment 16 Gene Czarcinski 2014-05-08 15:13:41 UTC
See https://bugzilla.redhat.com/show_bug.cgi?id=983685 for hang problem.  With patch applied and using the updated systemd, the install works great.

Comment 17 Gene Czarcinski 2014-05-08 17:15:27 UTC
OK, I looked at the grub.cfg and the kernel panic is because init16 is missing.  I need anaconda.program.log with DEBUG enabled so I can see if grubby is contributing to the problem.

I also had a problem running /usr/bin/liveinst.  With systemd-212-4 applied, the udevadm settle problem goes away so you can actually get through the install.  However, the boot failed.  It looks like grubby was OK but was handed a bad grub.cfg ... at least entry=0 was the rescue kernel and entry=1 the main kernel.  I am not sure what is going on here but I do not see a problem with grubby itself.

I am currently running pungi to build a new iso so I can test doing a regular install.

I also need to look into anaconda more.  While kickstart should work fine with just btrfs re-enabled, the gui needs some work so if it is btrfs AND you are allocating /boot AND there is no space left so you can allocate asmall ext4 partition, it will try using a subvol rather than erroring out.

Comment 18 Adam Williamson 2014-05-08 17:25:00 UTC
That GUI bit ought to work already, I think.

Comment 19 Adam Williamson 2014-05-08 19:31:09 UTC
Heh. I think I may have put grubby-debuginfo .rpm but not grubby .rpm in my first test iso. *oops*

building a new one now with the debugging patch included to see how that goes.

Comment 20 Gene Czarcinski 2014-05-09 11:53:38 UTC
Oops ... Houston, we have a problem ... but not with grubby.

Built a livecd-lxde iso with just "as of this morning 20140509" rawhide.

Booted up and ran /usr/bin/liveinst

produces something bad so that there is a boot error ... this can be corrected by booting up in rescue mode and running grub2-install /dev/vda as well as grub2-mkconfig -o /boot/grub2/grub.cfg

Opening a new BZ report as soon as I gather the supporting doc.

Comment 21 Gene Czarcinski 2014-05-15 19:43:58 UTC
OK, I am at a loss here.  What does " Custom partitioning screen rendering broken at 1024x768 in Russian" have to do with grubby and btrfs?

Also, rawhide testing resuming since I learned that the installer works with 2 or more vcpu.   I have also started testing on a dual core hardware.  So far, it just plain works.

Comment 22 Adam Williamson 2014-05-15 20:24:45 UTC
"OK, I am at a loss here.  What does " Custom partitioning screen rendering broken at 1024x768 in Russian" have to do with grubby and btrfs?"

Their tabs were open next to each other in my browser. =) Just a mistake, that's why I changed it.

Comment 23 Gene Czarcinski 2014-05-22 14:31:28 UTC
I have a new website http://czarc.org

updates.img files for anaconda-21.37 and updated patch files for grubby-8.35 are there.  There is also a yum repository with updated rpms:
grubby-8.35-1.gc742.v1.debug.fc21

Also, see https://bugzilla.redhat.com/show_bug.cgi?id=1099627
live install again has a good grub.cfg

Comment 24 Adam Williamson 2014-06-03 21:26:21 UTC
gene: can't seem to get to your site at present.

Comment 25 Gene Czarcinski 2014-06-04 18:17:04 UTC
Problem at my end.  Now fixed.

Comment 26 Gene Czarcinski 2014-06-04 18:29:01 UTC
NOTE:  The current anaconda (21.39-1) has the patches enable boot off btrfs and LVMlv as well as fixes for Live Install.

Comment 27 Adam Williamson 2014-06-04 22:13:08 UTC
I've built a live image with anaconda 21.39 and a patched grubby build, and done one successful install run already. However, on a second run, there seems to have been an exception in anaconda at run time. I believe this is affected by the existing layout of the disk:

18:03:50,064 DEBUG anaconda: running handleException
18:03:50,064 DEBUG anaconda: Traceback (most recent call last):

  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 227, in run
    threading.Thread.run(self, *args, **kwargs)

  File "/usr/lib64/python2.7/threading.py", line 766, in run
    self.__target(*self.__args, **self.__kwargs)

  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 189, in storageInitialize
    storage.reset()

  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 471, in reset
    self.devicetree.populate(cleanupOnly=cleanupOnly)

  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 2069, in populate
    self._populate()

  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 2133, in _populate
    self.addUdevDevice(dev)

  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1245, in addUdevDevice
    self.handleUdevDeviceFormat(info, device)

  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1859, in handleUdevDeviceFormat
    self.handleBTRFSFormat(info, device)

  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1703, in handleBTRFSFormat
    exists=True)

  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 4713, in __init__
    super(BTRFSVolumeDevice, self).__init__(*args, **kwargs)

  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 4627, in __init__
    super(BTRFSDevice, self).__init__(*args, **kwargs)

  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 2231, in __init__
    super(ContainerDevice, self).__init__(*args, **kwargs)

  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 567, in __init__
    self.format = fmt

  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 1038, in <lambda>
    lambda d,f: d._setFormat(f),

  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 4733, in _setFormat
    self.name = "btrfs.%d" % self.id

  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 406, in <lambda>
    lambda s, v: s._setName(v),

  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 686, in _setName
    raise errors.DeviceError("Cannot rename existing device.")

DeviceError: Cannot rename existing device.

Comment 28 Adam Williamson 2014-06-04 22:55:38 UTC
OK, I think that's not related to the btrfs /boot work. Well, so far this looks OK in my testing: I was able to install with /boot as a btrfs subvol, and anaconda correctly prevented me from making it a subvol of an *encrypted* btrfs volume. I can boot both regular and rescue kernels on the installed system. Next to check installing kernel updates.

Comment 29 Gene Czarcinski 2014-06-08 13:16:34 UTC
Created attachment 903279 [details]
add code to validate grub2 entry

Comment 30 Gene Czarcinski 2014-06-08 13:18:02 UTC
Created attachment 903280 [details]
v2 add support for btrfs when grub2 is bootloader

refactored with just update to support /boot on btrfs

Comment 31 Gene Czarcinski 2014-06-08 13:19:27 UTC
Created attachment 903281 [details]
v2 add lots of debugging

added code to support development and debugging of support for /boot on btrfs

Comment 32 Gene Czarcinski 2014-06-08 13:26:24 UTC
working on adding tests and will post that patch as soon as I get it.

So far, my tests with the refactoring of the single patch into three patches is working well.

Comment 33 Gene Czarcinski 2014-06-08 14:34:49 UTC
Created attachment 903283 [details]
v2 add code to validate a grub2 entry

Oops.  Fixed problem in src.rpm and forgot to update repository.  Now fixed.

Comment 34 Gene Czarcinski 2014-06-10 04:05:32 UTC
Created attachment 906996 [details]
v2.1 add support for btrfs when grub2 is bootloader

updated to support add-kernel & initrd in same execution

Comment 35 Gene Czarcinski 2014-06-10 04:06:47 UTC
Created attachment 906997 [details]
v2.1 add compile time enabled debugging code for btrfs

Comment 36 Gene Czarcinski 2014-06-10 04:07:36 UTC
Created attachment 906998 [details]
v2.1 add tests for btrfs support

Comment 37 Gene Czarcinski 2014-06-10 07:10:22 UTC
Created attachment 907052 [details]
v2.2 add support for btrfs when grub2 is bootloader

bugfix whitespace error

Comment 38 Adam Williamson 2014-06-10 15:50:38 UTC
as you seem to be revving the patches quite a bit, it might be interesting to carry your work as a git branch? you could fork grubby git upstream onto czarc.org, keep czarc's master branch synced with upstream, and add your work as a branch?

Comment 39 Jaroslav Reznik 2015-03-03 15:45:51 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 41 Fedora End Of Life 2016-11-24 11:09:42 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 42 Juan Orti 2016-11-24 11:25:28 UTC
This is still an issue in F25.

Comment 43 Manu 2017-02-08 23:15:37 UTC
What is the current remaining state of this issue?
Grub2 has been working with btrfs for years, I use btrfs for /boot on ubunntu and arch derivative distros all the time. What is holding Fedora back here?

Comment 44 Adam Williamson 2017-02-08 23:26:13 UTC
I don't think anyone who could potentially fix it is very interested in doing so. Note that the anaconda development team was drastically reduced in size last year.

The distinguishing feature in Fedora is grubby, which other distros don't use. We can't stop using it in Fedora for...various reasons.

Comment 45 Manu 2017-02-08 23:31:55 UTC
I think an awful lot of users who install /boot in btrfs also boot with something like rEFInd (I do).
Perhaps the shortest-path workable solution for btrfs users would be for anaconda to have a simple option to skip installation of a bootloader; then it doesn't need to complain where the user put /boot, and grubby isn't a problem.
I actually find it quite annoying when other distros don't have such an option; the result is 2 launchers in rEFInd for the same install, the /boot that it finds on its own, and also the bootloader that was installed.

Comment 46 Chris Murphy 2017-02-09 00:33:35 UTC
This is effectively a duplicate of bug 864198. Anyway, Gene Czarninski died two years ago, so he's not around to discuss the proposed patches which were submitted upstream and were initially accepted but then were rejected for unspecified reasons with work not progressing futher.

What's needed to progress it further? A volunteer who can fix the bug and submit it upstream. Whether the patches in this bug give a clue how to go about the problem, I don't know.

Comment 47 Fedora End Of Life 2017-12-12 10:18:11 UTC
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 48 Nathaniel McCallum 2018-03-02 20:58:21 UTC
https://github.com/rhboot/grubby/pull/32

I have updated the code and submitted a pull request.

Comment 49 Nathaniel McCallum 2018-03-03 05:57:00 UTC
COPR builds are available here:
https://copr.fedorainfracloud.org/coprs/npmccallum/btrfs/

Comment 50 Fedora Update System 2018-03-06 16:15:21 UTC
grubby-8.40-10.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c0e98e4635

Comment 51 Fedora Blocker Bugs Application 2018-03-06 16:21:20 UTC
Proposed as a Freeze Exception for 28-beta by Fedora user npmccallum using the blocker tracking app because:

 This was actually ready to go before the freeze, but I was advised to wait for bodhi to get testing. However, this means that we can't land in the beta, which is where we'd get most of our testing. This directly affects the ability to ship the parallel feature in anaconda in beta. So we'd like an exception.

The feature itself has multiple (upstream) tests that all pass during rpm build. It has also been manually tested by multiple people.

I believe this is a prime candidate for a freeze exception precisely because it affects the install process. In F27, it is impossible to install with this configuration. But, if this is accepted as a freeze exception, F28 will be able to install in this configuration.

Comment 52 Fedora Update System 2018-03-08 15:26:27 UTC
grubby-8.40-10.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c0e98e4635

Comment 53 Nathaniel McCallum 2018-03-08 15:50:16 UTC
*** Bug 864198 has been marked as a duplicate of this bug. ***

Comment 54 Geoffrey Marr 2018-03-12 20:53:59 UTC
Discussed during the 2018-03-12 blocker review meeting: [1]

The decision to classify this bug as an AcceptedFreezeException was made as this is a feature that people have been asking for for a long time that would add significant value to the Fedora 28 release, and if we want to add that feature, it would be best to test it in Beta instead of Final.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-03-12/f28-blocker-review.2018-03-12-16.01.txt

Comment 55 Fedora Update System 2018-03-12 22:36:48 UTC
grubby-8.40-10.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 56 Fedora Update System 2018-03-21 15:45:18 UTC
grubby-8.40-8.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-badf6d0f9e

Comment 57 Fedora Update System 2018-03-22 17:38:47 UTC
grubby-8.40-8.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-badf6d0f9e

Comment 58 Fedora Update System 2018-03-27 20:04:37 UTC
grubby-8.40-8.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 59 Christopher Patrick 2019-10-31 19:34:06 UTC
Still doesn't work in Fedora 31


Note You need to log in before you can comment on or make changes to this bug.