Bug 886502
| Summary: | create grub.cfg and /etc/default/grub even when not installing bootloader (BIOS installs) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Eric Blake <eblake> |
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | anaconda-maint-list, awilliam, bugzilla, daniell1, djasa, dkbatson, eblake, fropeter, gczarcinski, g.kaviyarasu, herrold, jonathan, mads, massi.ergosum, michel, mishu, mrmazda, Per.t.Sjoholm, pf.rhlists, pjones, rdieter, robatino, rtguille, sbueno, stephent98, vanmeeuwen+fedora, vilius, vpodzime |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | anaconda-22.9-1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 885240 | Environment: | |
| Last Closed: | 2014-12-09 17:04:47 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 885240 | ||
| Bug Blocks: | |||
|
Description
Eric Blake
2012-12-12 12:56:32 UTC
-1 blocker +1 NTH - I can't justify multi-boot OS using grub's 'configfile grub.cfg' or 'kernel core.img' to "chain-load" a grub image via any of the blocker criteria, but it sure seems like a simple request to make life easier for those that do want to chain-load in a manner that obeys upstream grub recommendations. Does this one only have the AcceptedBlocker whiteboard because it was cloned from an existing AcceptedBlocker? If, that should get blanked out until they've had time to do the meeting. (In reply to comment #2) > Does this one only have the AcceptedBlocker whiteboard because it was cloned > from an existing AcceptedBlocker? If, that should get blanked out until > they've had time to do the meeting. Yes, looks like a cloning artifact. I blanked the whiteboard so the meeting can discuss it properly. -1 blocker, it clearly isn't. +1 NTH, this would be a useful thing to add, so long as we don't do it crazy late - AFAICS it can only break the 'not installing a bootloader at all' path, the code shouldn't be touched outside of that path. Eric, if you want to write a patch for this, it shouldn't be too terribly hard. The code you need to look at is in pyanaconda/bootloader.py . Note there are 'classes' within this code for different bootloaders, make sure you poke the right one. You'd want to write the patch against origin/f18-branch branch - *not* master. Chris, the 'discussed at 20XX-XX-XX blocker review meeting...' comments act as a 'check' on the blocker status - if a bug has AcceptedBlocker in whiteboard but no explicit comment explaining when it was discussed and that status was granted, you can assume the status is bogus. +1 NTH A useful addition for sophisticated users, especially since I'll no longer be able to put the bootloader in sector zero of the Fedora partition, as I have done for years. (In reply to comment #6) You can put a boot loader in sector 0 and 1 of an ext[234] partition, but GRUB can't fit in only 1024 bytes. Historically GRUB was forced into free space in the file system without its awareness, using block lists, and therefore GRUB could be clobbered at any time. You can still install it this way yourself, e.g. grub2-install --force /dev/sda1 for ext file systems. Force is proscribed for XFS and btrfs. Forcing is also unnecessary for btrfs since it has a sufficiently large (64KB) boot code region. (In reply to comment #7) > (In reply to comment #6) > You can put a boot loader in sector 0 and 1 of an ext[234] partition, but > GRUB can't fit in only 1024 bytes. Historically GRUB was forced into free > space in the file system without its awareness, using block lists, and > therefore GRUB could be clobbered at any time. You can still install it this > way yourself, e.g. grub2-install --force /dev/sda1 for ext file systems. > Force is proscribed for XFS and btrfs. Forcing is also unnecessary for btrfs > since it has a sufficiently large (64KB) boot code region. But that information is unrelated to the point of this bug, which is about creating grub.cfg even when NOT installing grub into MBR or file system gaps. That is, this bug exists so that we DON'T need to use grub2-install --force. A couple of points that might or might not be tracked elsewhere: It seems like everything discussed here is for BIOS. That should perhaps be written in big letters in the subject. grub2 for BIOS on Fedora uses /boot/grub2/grub.cfg, but the standard fedora EFI grub uses /boot/efi/EFI/fedora/grub.cfg. It could thus be argued that both should be created if possible. There is no reason it shouldn't be easy to change between booting a Fedora installation both as BIOS and as EFI. But also: Fedora will unfortunately install the "efi bootloader" directly in /boot/efi/EFI/fedora when the grub2-efi package is installed. There is thus no way to avoid installating a bootloader on EFI. Anaconda on EFI should thus perhaps not ask the question, and it could just as well always create this strange /boot/efi/EFI/fedora/grub.cfg. (And before that it should run a dummy grub2-install to populate /boot/grub2 correctly.) And keep in mind that running grub2-install on an EFI system probably will do something completely different from what it does on a BIOS system. I'm sorry that this didn't make it simpler, but I think it raised some valid points. Discussed at 2012-12-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-17/f18final-blocker-review-5.2012-12-17-16.40.log.txt . Rejected as a blocker, it clearly doesn't violate the release criteria, but accepted as NTH as this would be useful for multi-booters and cannot be fixed post-release. (In reply to comment #9) > grub2 for BIOS on Fedora uses /boot/grub2/grub.cfg, but the standard fedora > EFI grub uses /boot/efi/EFI/fedora/grub.cfg. It could thus be argued that > both should be created if possible. There is no reason it shouldn't be easy > to change between booting a Fedora installation both as BIOS and as EFI. Well except I think grub2-install fails if efibootmgr fails, which it does if the computer is BIOS mode boot. And grub2-mkconfig produces a rather different grub.cfg depending on whether the boot mode is BIOS vs UEFI. > But also: Fedora will unfortunately install the "efi bootloader" directly in > /boot/efi/EFI/fedora when the grub2-efi package is installed. There is thus > no way to avoid installating a bootloader on EFI. Anaconda on EFI should > thus perhaps not ask the question, Agreed. Filed this as Bug 888106. *** Bug 901373 has been marked as a duplicate of this bug. *** Note that in addition to creating grub.cfg, /etc/default/grub also needs to be written -- the latter by Anaconda since grub doesn't create it and it contains Fedora-specific defaults. FWIW, the anaconda code to write /etc/default/grub is here: http://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/bootloader.py?id=anaconda-18.37.11-1#n1429 Bumping out to Rawhide, cleaning the blocker bureaucracy. It would be very helpful if anaconda created /etc/default/grub as there is no other possibility to generate that file automatically (as far as I know). I've just installed Fedora 18 without installing GRUB2 and ran grub2-install and grub2mk-config manually on a live cd (via chroot). Creating /etc/default/grub by hand though was unfriendly. There is more to it, not just the files. I installed grub afterwards and the machine didn't run firstboot. It's doesn't start in graphical mode and graphical(gdm) starts ok manually. I installed an other machine and got the same behavior. Re-installed with grub installed i (MBR) and then no problem. I've installed two system without installing GRUB. On the very first boot SELinux relabeled the filesystem on both systems. Afterwards both rebooted and ran into firstboot. (In reply to comment #16) > It would be very helpful if anaconda created /etc/default/grub as there is > no other possibility to generate that file automatically (as far as I know). > > I've just installed Fedora 18 without installing GRUB2 and ran grub2-install > and grub2mk-config manually on a live cd (via chroot). Creating > /etc/default/grub by hand though was unfriendly. Yes indeed! I copied an existing /etc/default/grub from Arch installed on another partition, and edited that file accordingly. Even so, I am not sure it is exactly as it should be. For the record, /etc/default/grub is not necessarily required. A test in a VM shows that a default, Gnome desktop install boots fine without it. Test procedure (using the F18 DVD): Complete a default, Gnome desktop install (with bootloader install enabled). Before rebooting, switch to the installer shell (ctrl-alt-f2). # chroot /mnt/sysimage # mv /etc/default/grub /etc/default/grub.BAK1 # grub2-mkconfig -o /boot/grub2/grub.cfg # exit # reboot Tested with: $ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice mouse (In reply to comment #20) > For the record, /etc/default/grub is not necessarily required. A test in a > VM shows that a default, Gnome desktop install boots fine without it. > > Test procedure (using the F18 DVD): > Complete a default, Gnome desktop install (with bootloader install enabled). > Before rebooting, switch to the installer shell (ctrl-alt-f2). > # chroot /mnt/sysimage > # mv /etc/default/grub /etc/default/grub.BAK1 > # grub2-mkconfig -o /boot/grub2/grub.cfg > # exit > # reboot > > Tested with: > $ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom > ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice > mouse True, you can boot without /etc/default/grub but you lose a number of grub options such as disabling os-prober, grub hiddenmenu, default os boot, grub themes, etc. For reference, here is /etc/default/grub after a default F18 install[1]: GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rd.luks=0 vconsole.keymap=us rd.lvm.lv=fedora/root rhgb quiet" GRUB_DISABLE_RECOVERY="true" GRUB_THEME="/boot/grub2/themes/system/theme.txt" The F18 anaconda code to write /etc/default/grub is here: http://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/bootloader.py?id=anaconda-18.37.11-1#n1429 [1] Tested with: $ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice mouse I'm uncertain the theme.txt exists without grub2-install being run first. GRUB devs have said there are some dependencies on grub2-install being run before grub2-mkconfig. Hence to fulfill the RFE for this bug, anaconda should do the same things it does when the (default) option to install boot loader is selected, except to add the flag --grub-setup=/bin/true when calling grub2-install. The only thing that does is suppress stomping on the MBR and MBR gap (or BIOS Boot). This way /etc/default/grub, core.img, all modules, themes, support files, and grub.cfg are still created and available. (In reply to comment #23) > I'm uncertain the theme.txt exists without grub2-install being run first. > GRUB devs have said there are some dependencies on grub2-install being run > before grub2-mkconfig. ... Thanks for raising that issue. 1. The file "/boot/grub2/themes/system/theme.txt" exists after an F18 minimal install with bootloader installation disabled.[1] 2. The directory "/boot/grub2/themes/system/" contains 31 files, most of which are png and pf2 files. 3. No other directories under "/boot/grub2/" are populated. 4. grub2-mkconfig runs without error and writes "/boot/grub2/grub.cfg".[2] 5. Booting with "configfile /boot/grub2/grub.cfg" succeeds. [1] Tested with: $ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice mouse [2] The grub2-mkconfig command was run after chrooting to "/mnt/sysimage" before rebooting from the installer. (In reply to comment #24) ... > 3. No other directories under "/boot/grub2/" are populated. > 4. grub2-mkconfig runs without error and writes "/boot/grub2/grub.cfg".[2] > 5. Booting with "configfile /boot/grub2/grub.cfg" succeeds. ... Here is my test configuration: sda1 /boot (Installation 1) sda2 / (Installation 1) sda3 / (Installation 2, which does not use a separate boot partition.) sda4 swap Installation 2 does not have any grub2 modules installed, yet it can be booted from sda1 using the grub2 "configfile" command, so the grub2 modules must be coming from the grub2 installation on sda1. Tip: Set different time zones for the two installations, so they can be distinguished by running the date command after logging in. (In reply to comment #24) > 1. The file "/boot/grub2/themes/system/theme.txt" exists after an F18 > minimal install with bootloader installation disabled.[1] > 2. The directory "/boot/grub2/themes/system/" contains 31 files, most of > which are png and pf2 files. > 3. No other directories under "/boot/grub2/" are populated. > 4. grub2-mkconfig runs without error and writes "/boot/grub2/grub.cfg".[2] > 5. Booting with "configfile /boot/grub2/grub.cfg" succeeds. > > [1] Tested with: > $ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom > ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice > mouse > > [2] The grub2-mkconfig command was run after chrooting to "/mnt/sysimage" > before rebooting from the installer. Same here *except* #3. All my directories under /boot/grub2/ are populated. Used the Fedora-18-x86_64-DVD.iso to install Fedora. One difference, I booted the DVD again in rescue mode to run grub2-mkconfig. (In reply to comment #26) ... > > 3. No other directories under "/boot/grub2/" are populated. ... > Same here *except* #3. All my directories under /boot/grub2/ are populated. > Used the Fedora-18-x86_64-DVD.iso to install Fedora. > > One difference, I booted the DVD again in rescue mode to run grub2-mkconfig. Thanks for your comments. Item 3 in Comment 24 is referring to the configuration of Installation 2, which does not have a bootloader installed. That was not clear in Comment 24; sorry about that. Confirming that running grub2-mkconfig from the DVD in rescue mode works. After completing Installation 2 and rebooting from the DVD into rescue mode, there are two installations listed for mounting. They have identical names, so you have to guess which one is Installation 2. One minor problem is that, before rebooting into Installation 2, selinux relabeling is done ... (In reply to comment #27) > (In reply to comment #26) > Item 3 in Comment 24 is referring to the configuration of Installation 2, > which does not have a bootloader installed. That was not clear in Comment > 24; sorry about that. > > Confirming that running grub2-mkconfig from the DVD in rescue mode works. In my case, I have 4 OS's installed. I have been using Arch Linux GRUB2 for some months now, installed to the MBR. When I first installed Fedora 18, it replaced Arch's GRUB2 bootloader before I knew it. I was booting Fedora's GRUB2. I booted back into Arch Linux and reinstalled the Arch Linux GRUB2 bootloader. Later I decided to reinstall Fedora to change from E16 to Gnome, and during installation I formatted the Fedora partition. This time I did not install Fedora 18's GRUB2 bootloader, but created /boot/grub2/grub.cfg from the DVD rescue mode. I wouldn't think that pieces of the original Fedora GRUB2 bootloader would be left in the MBR... FWIW, the path to Fedora's themes is different than Arch. Arch is /boot/grub/... while Fedora is /boot/grub2/.... (In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #26) > > Item 3 in Comment 24 is referring to the configuration of Installation 2, > > which does not have a bootloader installed. That was not clear in Comment > > 24; sorry about that. > > > > Confirming that running grub2-mkconfig from the DVD in rescue mode works. > > In my case, I have 4 OS's installed. I have been using Arch Linux GRUB2 for > some months now, installed to the MBR. When I first installed Fedora 18, it > replaced Arch's GRUB2 bootloader before I knew it. I was booting Fedora's > GRUB2. I booted back into Arch Linux and reinstalled the Arch Linux GRUB2 > bootloader. > > Later I decided to reinstall Fedora to change from E16 to Gnome, and during > installation I formatted the Fedora partition. This time I did not install > Fedora 18's GRUB2 bootloader, but created /boot/grub2/grub.cfg from the DVD > rescue mode. > > I wouldn't think that pieces of the original Fedora GRUB2 bootloader would > be left in the MBR... FWIW, the path to Fedora's themes is different than > Arch. Arch is /boot/grub/... while Fedora is /boot/grub2/.... Thanks for the additional details. Did you run grub2-install on your Fedora partition? That could explain why you are seeing grub2 files in /boot/grub2/ ... (In reply to comment #25) ... > Installation 2 does not have any grub2 modules installed, yet it can be > booted from sda1 using the grub2 "configfile" command, so the grub2 modules > must be coming from the grub2 installation on sda1. ... For testing, I am using this menu entry in /boot/grub2/grub.cfg on Installation 1: menuentry 'Boot Fedora Installation 2 with configfile' { set root='hd0,msdos3' configfile /boot/grub2/grub.cfg } No, I did not run grub2-install on my Fedora partition. (In reply to comment #31) > No, I did not run grub2-install on my Fedora partition. Oops, I was wrong. Here is what I did. https://bugzilla.redhat.com/show_bug.cgi?id=872826#c99 This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 This is strange in my F18 (I have not installed grub2 MBR through anaconda): # file /etc/default/grub /etc/default/grub: ERROR: cannot open `/etc/default/grub' (No such file or directory) # rpm -q --whatprovides /etc/default/grub grub2-tools-2.00-15.fc18.x86_64 # rpm -q --list grub2-tools | grep default /etc/default/grub /usr/sbin/grub2-set-default But if I get the package... # yumdownloader grub2-tools ... I can't find any /etc/default/grub inside it. This is how I fixed this mess. MBR overwritten by grub2, use syslinux rpm and dd. From syslinux http://www.syslinux.org/wiki/index.php/Mbr dd bs=440 count=1 conv=notrunc if=mbr/mbr.bin of=/dev/sda Install fedora with no grub2 Before rebooting. open a shell terminal chroot /mnt/sysimage grub2-install --grub-setup=/bin/true /dev/sda grub2-mkconfig -o /boot/grub2/grub.cfg reboot and boot http://www.sysresccd.org/ Set boot flag for the partition you want to boot. install grub1 on the partition boot, use the version in sysrecoverycd and let that boot grub2 core.img Copy /boot/grub/ files and run to install to partition assume sda2 (hd0,1) grub root (hd0,1) setup (hd0,1) quit Create menu.lst or grub.conf cat >>/boot/grub/menu.lst <<EOF title Fedora root (hd0,1) kernel /boot/grub2/i386-pc/core.img EOF In Fedora Write /etc/default/grub grub2-mkconfig -o /boot/grub2/grub.cfg by moving bootflag you can now chose which partition to boot as before. *** Bug 893106 has been marked as a duplicate of this bug. *** (In reply to Per Sjoholm from comment #35) > This is how I fixed this mess. Grub setup valid for Fedora 20, follow comment #35 /etc/default/grub is still missing What should it be ? Here is mine from a normal install of Fedora 20, installing GRUB2 to the MBR. /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb quiet" GRUB_DISABLE_RECOVERY="true" 1. Changed release as this should be open until fixed. 2. If syslinux/extlinux is being used instead of grub2, then the comparable syslinux/extlinux configuration files should be created but nothing isntalled into the MBR. What about RHEL systems? Just upgraded RHEL6 system to RHEL7 using official RedHat upgrade tool (which I believe doesn't install grub2 into MBR) and now my system doesn't have /etc/default/grub file + /boot/grub2 is almost empty with the exception of themes folder. grub2 still boots from old /boot/grub/grub.conf file. if the 'official upgrade tool' for RHEL 7 is based on fedup (IIRC it is), it does not involve anaconda at all. *** Bug 1033550 has been marked as a duplicate of this bug. *** This change in Rawhide is backwards compatible according to this patch: http://git.savannah.gnu.org/cgit/grub.git/commit/?id=55e2c84fe32f49242b54fc90e0b6a5ade1dc1ab0 But the new/preferred and more discoverable option is to use --no-bootsector instead. |