On Dec 2, 2015 8:15 AM, "Josh Boyer" <jwboyer(a)fedoraproject.org&gt; wrote: Could we switch for grub2 architectures and keep using grubby for other architectures? --Andy

On Dec 2, 2015 8:38 AM, "Reindl Harald" <h.reindl(a)thelounge.net&gt; wrote: enumerate switch Then let's make the same change across all bootloaders. For grub2, use grub2-mkconfig. For syslinux, use whatever Anaconda uses to generate the config in the first place. Frankly, I'd like to see Fedora move away from grub2 even on x86. But I'd also like to see grubby go away. --Andy

On Wed, Dec 2, 2015 at 12:50 PM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote: ​My big pain point right now is that we can't have /boot be a subvolume on btrfs and boot properly. GRUB2 and ExtLinux both support booting from btrfs just fine, but we don't seem to support it for some reason? I can't recall the issue off the top of my head, but I *think* the issue was related to grubby. Perhaps using grub2-mkconfig would fix this?​ -- 真実はいつも一つ！/ Always, there's only one truth!

On Wed, Dec 2, 2015 at 1:44 PM, Tomasz Torcz <tomek(a)pipebreaker.pl&gt; wrote: Is the issue that grub2-mkconfig can handle useful configs that grubby can't? If so, maybe that's another reason to switch to grub2-mkconfig. --Andy

On Wed, Dec 2, 2015 at 9:50 AM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote: But it's not. grubby does things like adding kernels and removing kernels. grub2-mkconfig enumerates kernels and generates a config. Fair enough. Two major problems come to mind: 1. grubby puts the most recently-installed kernel on top. grub2-mkconfig puts the highest version on top. In the cases where they differ, I'd argue that the latter is better. 2 .If I want to edit boot options, grubby makes it unnecessarily painful, and the directions are simply wrong. For example, my /etc/grub2-efi.cfg says: # # DO NOT EDIT THIS FILE # # It is automatically generated by grub2-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub # That's grossly misleading. It *was* automatically generated, but it is certainly not automatically generated on an ongoing basis. If I change settings in /etc/default/grub, nothing happens. If I actually want to change boot options, I have to either manually edit every instance (or somehow, magically, the correct subset of copies) in /etc/grub2-efi.cfg, which is a real pain and easy to screw up. Or I can cross my fingers any try to figure out the right invocation to just regenerate the whole thing (grub2-mkconfig >/etc/grub2-efi.cfg, presumably). Assuming that such an incantation exists (which it does these days!), one wonders why it's not happening automatically on kernel upgrades. To the extent that I do it wrong and grub2-efi.cfg diverges from that which is implied by /etc/default/grub, etc, we have a mess. This can happen due to settings editing and presumably due to other things. In fact, looking more closely, there's already a divergence. grub2-mkconfig doesn't emit LANG=en_US.UTF-8. The grubby-generated config has LANG=en_US.UTF-8 on all entries except vmlinuz-0-rescue. I would argue that that's a bug. If grubby went away or started using grub2-mkconfig internally, this bug and all bugs like it would become impossible. A more minor (from my POV) problem: 3. More critical-path code. grub2-mkconfig must work for Anaconda to work. ostree requires it, too. But grubby is a separate and presumably rather more complicated codebase, and it needs to be kept in sync for kernel upgrades to work, and those are also critical path. --Andy

On Wed, Dec 2, 2015 at 11:54 AM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote: I'm talking about grubby the binary and grubby the approach of incrementally editing the config rather than regenerating it each time. Or file an RFE for grub2 to have an option to use the file timestamps instead of the version for the sort order. In my case, I do a lot of kernel compiling, and I don't like the RPM-provided 4.2-whatever kernels to end up above my 4.4+patches kernel whenever dnf pulls in a new kernel. I do that to. I find it to be extremely tedious and error prone. In comparison, managing /etc/default/grub on the Ubuntu servers I maintain is a piece of work, works every time, and requires no thought about exactly how many copies of the same thing I have to change. And that file exists on Fedora, with the same contents, but uselessly, unlike Ubuntu. Debian/Ubuntu's update-grub tool is wonderful, and it's really quite simple: #!/bin/sh set -e exec grub-mkconfig -o /boot/grub/grub.cfg "$@" Of course, the paths would be a bit different for Fedora. I generally update for all because I don't trust grubby to propagate them if I don't or I edit for all because I'm sometimes fastidious. If I only do one, it's because I'm lazy. Depends which stanza I edit in my experience. Certainly the status quo seems to work for the most part, especially if users don't do anything fancy. But Fedora's approach really seems to be considerably more complicated than what everyone else does, and Fedora also packages all the code for the simpler approach already. Other than some people having a preference for a different sort order (which could easily be added to grub2-mkconfig), what's the benefit, if any, of Fedora's incremental update approach? --Andy

On Wed, Dec 2, 2015 at 12:21 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote: Can you please try to reduce your level of sarcasm on the list? It's especially irritating when you're simultaneously sarcastic and factually incorrect: $ stat /boot/vmlinuz-4.2.6-301.fc23.x86_64 File: ‘/boot/vmlinuz-4.2.6-301.fc23.x86_64’ Size: 5980440 Blocks: 11688 IO Block: 4096 regular file Device: 10302h/66306d Inode: 13 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:modules_object_t:s0 Access: 2015-11-20 14:35:27.000000000 -0800 Modify: 2015-11-20 14:35:27.000000000 -0800 Change: 2015-11-29 13:02:59.410471082 -0800 ^^^^^^^^^^^^^^^^^^^^^^ Note the ctime Birth: - For something more reliable, grub2-mkconfig for similar could do something like: $ rpm -qf /boot/vmlinuz-4.2.6-301.fc2-queryformat '%{installtime}\n' with some appropriate provision for packages that don't come from RPM in the first place. For human readability: $ rpm -qf /boot/vmlinuz-4.2.6-301.fc23.x86_64 --queryformat '%{installtime:date}\n' Sun 29 Nov 2015 01:01:52 PM PST Note that this is suspiciously similar to ctime above. --Andy

On Wed, Dec 2, 2015 at 12:37 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote: You're not 100% correct. Try ls -lhca. Note the 'c' in there. And maybe try at least searching the manpage for the most obvious keywork ('ctime' in this case) before digging in your heels. (Or even try the exact commands I put in my email, which would have lead to much the same conclusion.) The fact that you assert your absolute correctness on a frequent basis even when you're not correct makes me, and probably other people, likely to discount everything you say even in the cases when you are correct. If you want your opinion to be helpful, please reconsider how you write your emails. Anyway, I filed an RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1287854 --Andy

On Wed, Dec 2, 2015 at 3:16 PM, Andrew Lutomirski <luto(a)mit.edu&gt; wrote: Hm. OK. Could you elaborate on that grub2 part? That sounds reasonable. *shrug*. I guess we're going to disagree on that point, but that isn't the end of the world. I have no experience with other distros. That may be why I don't understand the desire to rip everything up. However, even in thinking about it some I can't see where I would personally care that much. How funny! I only edit one because I'm lazy. Grubby propagates the change to every kernel thereafter. Also, I'm not sure I'd blindly want an option passed to all existing kernels. Quite often it is something I'm trying that is new enough to only exist in certain kernels, or a debug setting I only want on certain kernels. But your point is certainly valid. I still think this is an issue. It might be worth focusing on documentation. It leaves existing configs which are known to work alone and doesn't blow them away if you happen to make a typo in /etc/grub.cfg or whatever? Breaking a single kernel boot because of a typo is fine. Making your machine unbootable because you regenerated an entire config file with a typo just seems silly. Why would you want to expose users to that? josh

Am 02.12.2015 um 20:35 schrieb Andrew Lutomirski: and if it has a bug you are lot with *all* entries borked no - if you want them all identically just run grub2-mkconfig manually but don't expect that i am happy when something put's the same error into every entry https://bugzilla.redhat.com/show_bug.cgi?id=840204 is probably the best example - with grubby you where able to add the needed option to the most recent entry and survived kernel updates with grub2-mkconfig *every* single kernel update without edit the config before reboot meant go to your car and drive 300 miles to the remote machine or explain somebody how to get screen and keyboard on the headless machine and hand out the password

Andrew Lutomirski wrote: There are several issues with the current approach: * Our approach to updating grub.cfg differs from the approach recommended and documented by upstream. * As you pointed out, even the documentation IN the file we ship misleadingly documents the upstream approach and not the one we are actually using. (At least that part would be easily fixable though, by patching the boilerplate grub.cfg header in grub2-mkconfig.) * Any third-party configuration tools such as kcm_grub2 expect the upstream mechanisms, because we are pretty much the only distro that bypasses them. Thus, they WILL rerun grub2-mkconfig, and any changes you or grubby manually made to the file will be overwritten. Now our approach does have the advantage that you have more detailed control over the contents of the file than with grub2-mkconfig (though you have to be careful not to confuse grubby). I am torn as to whether this is enough justification for continuing to ignore upstream's recommended configuration system. Kevin Kofler

On Tue, Dec 1, 2015, at 10:30 PM, Andrew Lutomirski wrote: Note this is what ostree (as used by Fedora Atomic Host) does.

On Wed, Dec 2, 2015 at 4:30 AM, Andrew Lutomirski <luto(a)mit.edu&gt; wrote: Well mkconfig can produce a configuration that does not actually work when grub2 itself gets updated (in which case the bootloader does not get rewritten). Until this is fixed grub2-mkconfig is dangerous and should not be used.

On Sun, Dec 6, 2015 at 6:20 PM, Andrew Lutomirski <luto(a)mit.edu&gt; wrote: No that has nothing to do with the installation process. The events are: 1) You install Fedora -- grub2-mkconfig creates a config that matches the bootloader 2) The grub package gets updated / upgraded --- grub2-mkconfig is no longer guaranted to generate a config file that works with the grub that is actually installed (i.e you'd have to rerun grub2-install to be sure). Yes in most of the cases that works but it is fragile and therefore dangerous to do that by default.

On Sun, Dec 6, 2015 at 7:02 PM, Tomasz Torcz <tomek(a)pipebreaker.pl&gt; wrote: I got bitten by it before so its not theoretical ... unfortunately I do not remember the exact versions.

Am 06.12.2015 um 21:22 schrieb Chris Murphy: that's wrong because grubby *clones* the last recent entry with all it's parameters and don't touch other boot entrie snor the rest of the configuration

Am 06.12.2015 um 21:06 schrieb Chris Murphy: the world don't turn around UEFI he told you he was personally affected and you are going to change existing systems running for many years and surivived all dist-upgrades to UEFI *without* reinstall or lose /boot redundancy by RAID1? grub2-install needs to be manually done on all 4 drives frankly my current workstations where installed with F14 and RAID1 for /boot as well as RAID10 for anything else, they support UEFI but i gave up with Anaconda, now they happily run Fedora 23 with dist-upgrades and will as long some jerk decides to kill BIOS support or i die the same applies to more than 30 production servers installed with Fedora 9 years ago and currentyl on F22 on top of VMware - fine, Vmware now supports UEFI too - but tell me *one valid* reason to change them!