| Summary: | grub2-mkconfig generates wrong pointer to / of existing old install | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Patrick C. F. Ernzer <pcfe> |
| Component: | grub2 | Assignee: | Peter Jones <pjones> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 16 | CC: | dennis, mads, pjones, vserbine, w.deborger |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-14 00:26:49 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 494832 | ||
I have the same problem,
it seems that
/etc/grub.d/10_linux
assumes that the current root is the root for all linux installs
---
linux_root_device_thisversion="${LINUX_ROOT_DEVICE}"
linux_root_device_thisversion=${GRUB_DEVICE}
---
This should be made configurable
A shared /boot is in my opinion a very bad idea - for example for the reasons outlined above. The complexity of such a setup with multiple owners fighting over the same directory and different versions that has to be backward and forward compatible ... I can not image how that possibly could be reliable. (The idea of kernel entries generated with os-prober is not much better.) The only reliable solution would be to keep the boot loaders separate and do chain loading ... similar to how EFI has a master boot loader that can launch other bootloaders. In my opinion this is a "don't do that, then" NOTABUG WONTFIX. fair enough. I have no problem this being classified as a "don't do that" bug, but let's please make sure this is documented. (not sure if release notes or grub2 man pages are the better place, I'd lean towards the latter) grub2 do not have man pages ;-) Nobody installing an OS will start reading the boot loader documentation, so I think it would be better to address it in anaconda or in the release notes. But I doubt the Fedora VIPs will agree on a "chainload; don't reuse /boot" policy. Just tellin' that I doubt it will be fixed and I don't see how it could be fixed. (In reply to comment #2) I disagree that it can not possibly be reliable. It has been reliable since forever. There are a few requirements to get it reliable 1- config must be in /boot 2- updates should be conservative. Tools can only add or remove entries, never overwrite the entire config. 3- automatic configuration should be conservative: only add new entries. Wouter (In reply to comment #5) > It has been reliable since forever. Precisely what has been reliable? What did what do and why was it reliable? > I disagree that it can not possibly be reliable. "It" = the grub2-mkconfig approach of probing and guessing and using configuration both in /boot and different /etc's can not be reliable. It is of course possible to use a different approach that is reliable. Something where there is master boot loader and a protocol for how the different OS's can manage their own boot entries. Chaining of boot loaders is one such approach. I may not have expressed myself as clearly as I should. I will try again. There is a proposal to mark this bug as 'don't do that', based on the argument that a shared /boot can not be possibly reliable. I strongly object to this, based on personal experience of using a shared /boot for many years. I think chainloading is not an acceptable solution. By maintaining several bootloaders, the maintenance overhead is significantly increased. There is no longer a central location where the boot process can be managed. Simple tasks, like setting the default image become very complicated. The grub2-mkconfig approach would be much more reliable, if it used the existing config as basis for its guesses. So, in conclusion, it is possible to fix this bug by storing a table of parameters in /boot, to be used by grub2-mkconfig as defaults. This would make the grub2-mkconfig behavior more stable and allow manual tweaking if mkconfig makes a bad guess. If there is interest in this solution, I can implement it. My excuses for the bad wording, Wouter (In reply to comment #6) > (In reply to comment #5) > > It has been reliable since forever. > > Precisely what has been reliable? What did what do and why was it reliable? > > > I disagree that it can not possibly be reliable. > > "It" = the grub2-mkconfig approach of probing and guessing and using > configuration both in /boot and different /etc's can not be reliable. > > It is of course possible to use a different approach that is reliable. > Something where there is master boot loader and a protocol for how the > different OS's can manage their own boot entries. Chaining of boot loaders is > one such approach. (In reply to comment #7) > I think chainloading is not an acceptable solution. By maintaining several > bootloaders, the maintenance overhead is significantly increased. There is no > longer a central location where the boot process can be managed. Simple tasks, > like setting the default image become very complicated. What is "default image"? The choice between your f16, your f17, your ubuntu, your windows and "bios/setup/maintenance" would be in the master boot loader. The choice of the default kernel for f16 would be in your f16 boot loader, the choice of default kernel for f17 would be in the f17 boot loader independent of the f16 boot loader, and so on. That is IMHO as simple as it can be. An EFI boot manager could be seen as one example of such a 'master boot loader'. > The grub2-mkconfig approach would be much more reliable, if it used the > existing config as basis for its guesses. > > So, in conclusion, it is possible to fix this bug by storing a table of > parameters in /boot, to be used by grub2-mkconfig as defaults. This would make > the grub2-mkconfig behavior more stable and allow manual tweaking if mkconfig > makes a bad guess. If there is interest in this solution, I can implement it. That is not how grub-mkconfig works today, but it would of course in principle be possible to redefine grub-mkconfig and make more or less fundamental changes to it. Fedora will probably not carry a patch for that, but if such changes were made upstream in grub then they would automatically show up in Fedora. The most elegant way to make such changes would be to let grub-mkconfig generate a grub.cfg that contained scripting code for automatically picking up and prioritizing whatever kernels and sub-configurations that could be found in /boot. There would thus not be any need for touching the master boot configuration when a new kernel is installed ... and thus no risk that one os kernel could break anything for other os/kernels. @Kiilerich: Please stop recommending chainloading as "The Solution". It has several grave problems and should not be used. If os-prober approache isn't well enough for you you can include older config in newer GRUB using source, configfile or extractor directives. Actually changing os-prober approach to more config-fileinclusion driven is one of my goals but I haven't done it yet. This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 WONTFIX if it remains open with a Fedora 'version' of '16'. 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 prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 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 to click on "Clone This Bug" and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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. Thank you for reporting this bug and we are sorry it could not be fixed. |
Description of problem: When installing, I made Fedora 16's / a LV, keeping the F15 install's / and did not format /boot (so that I can easily boot into F15) grub2-mkconfig generates a file where the kernel line for my F15 kernel actually points at the F16 / Version-Release number of selected component (if applicable): grub2-1.99-12.fc16.x86_64 How reproducible: always Steps to Reproduce: 1. # grub2-mkconfig -o /tmp/banana Generating grub.cfg ... Found linux image: /boot/vmlinuz-3.1.2-1.fc16.x86_64 Found initrd image: /boot/initramfs-3.1.2-1.fc16.x86_64.img Found linux image: /boot/vmlinuz-3.1.0-7.fc16.x86_64 Found initrd image: /boot/initramfs-3.1.0-7.fc16.x86_64.img Found linux image: /boot/vmlinuz-2.6.41.1-1.fc15.x86_64 Found initrd image: /boot/initramfs-2.6.41.1-1.fc15.x86_64.img Found Windows NT/2000/XP on /dev/sda2 Found Fedora release 15 (Lovelock) on /dev/mapper/VG_x60_internal-LV_slash_F15 done 2. # lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert LV_home VG_x60_internal -wi-ao 49,06g LV_slash_F15 VG_x60_internal -wi-ao 12,00g LV_slash_F16 VG_x60_internal -wi-ao 10,00g LV_swap VG_x60_internal -wi-ao 2,91g LV_var_cache VG_x60_internal -wi-ao 4,00g 3.# grep '2.6.41.1-1.fc15.x86_64' /tmp/banana menuentry 'Fedora Linux, with Linux 2.6.41.1-1.fc15.x86_64' --class fedora --class gnu-linux --class gnu --class os { echo 'Loading Linux 2.6.41.1-1.fc15.x86_64 ...' linux /vmlinuz-2.6.41.1-1.fc15.x86_64 root=/dev/mapper/VG_x60_internal-LV_slash_F16 ro rd.md=0 rd.dm=0 KEYTABLE=us rd.lvm.lv=VG_x60_internal/LV_swap quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks.uuid=luks-3525a15a-0d72-4cfc-b9e4-2d4309fe6f15 rd.lvm.lv=VG_x60_internal/LV_slash_F16 LANG=en_US.UTF-8 initrd /initramfs-2.6.41.1-1.fc15.x86_64.img menuentry 'Fedora Linux, with Linux 2.6.41.1-1.fc15.x86_64 (recovery mode)' --class fedora --class gnu-linux --class gnu --class os { echo 'Loading Linux 2.6.41.1-1.fc15.x86_64 ...' linux /vmlinuz-2.6.41.1-1.fc15.x86_64 root=/dev/mapper/VG_x60_internal-LV_slash_F16 ro single rd.md=0 rd.dm=0 KEYTABLE=us rd.lvm.lv=VG_x60_internal/LV_swap quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks.uuid=luks-3525a15a-0d72-4cfc-b9e4-2d4309fe6f15 rd.lvm.lv=VG_x60_internal/LV_slash_F16 LANG=en_US.UTF-8 initrd /initramfs-2.6.41.1-1.fc15.x86_64.img menuentry "Fedora (2.6.41.1-1.fc15.x86_64) (on /dev/mapper/VG_x60_internal-LV_slash_F15)" --class gnu-linux --class gnu --class os { linux /vmlinuz-2.6.41.1-1.fc15.x86_64 ro root=/dev/mapper/VG_x60_internal-LV_slash_F15 rd_LVM_LV=VG_x60_internal/LV_slash_F15 rd_LUKS_UUID=luks-3525a15a-0d72-4cfc-b9e4-2d4309fe6f15 rd_LVM_LV=VG_x60_internal/LV_swap rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb crashkernel=128M initrd /initramfs-2.6.41.1-1.fc15.x86_64.img Actual results: the above will obviously use LV_slash_F16, I presume it pulls it in from GRUB_CMDLINE_LINUX in /etc/default/grub Expected results: If grub2-mkconfig finds a linux installation on a partion/LV different from the current /, it should at least spit out a warning. (I am not sure if it can be made to match kernels left over in /boot, maybe parsing the old /boot/grub/grub.conf ?) Additional info: ran into this because I had forgotten to rpm -e all but latest of the F15 kernels and had not enough space on /boot at the first 'yum update kernel' under F16. I wanted to boot F15 to remove it cleanly. Simply editing the kernel line on the fly inside grub worked of course, but the lack of warning message may still leave some users unable to easily boot their old install. Suggested text: grub2-mkconfig detected /Fedora release 15 (Lovelock)/ [well, the text it used above to print what it found], please manually adjust /boot/grub/grub.conf You may ignore the 'do not edit' warning at the top of that file, but will have to re-do the adjustment for /Fedora release 15 (Lovelock)/ afer each re-run of this tool.