Description of problem: As per summary. I see no reason why install.sh should be touched during a kernel update, let alone run. All that is needed is that grub2-mkconfig should be run. I use a dedicated master boot partition that uses it's own install of grub2 to boot into various systems, so I do not want updates of grub2 or kernel updates to touch the machine's nvram. To this end I use "grub2-install --bootloader-id=tmp --no-nvram" as a workaround in install.sh. This works fine, ONCE but it is replaced with the default "grub2-install" on kernel update, why? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
assigning
Assignee: bugsquad => tmbCC: (none) => marja11
CC: (none) => thierry.vignaud
I see this behavior (replacing the existing default boot option with the M6 installation) in M6dev1-64 with Plasma. I did not notice it up to now in an M6dev1-32 installation as this one respects the existing grub (grub2 not being installed), just adds to it.
CC: (none) => herman.viaene
(In reply to Herman Viaene from comment #2) > I see this behavior (replacing the existing default boot option with the M6 > installation) in M6dev1-64 with Plasma. I did not notice it up to now in an > M6dev1-32 installation as this one respects the existing grub (grub2 not > being installed), just adds to it. You do not say whether this 64 bit install is in UEFI mode or not. This bug only concerns UEFI mode and the install.sh overwriting issue. If kernel updates are changing your regular grub2 default boot option then that is another issue and requires another bug report (unless one already exists).
Sorry, forgot to mention that. The affected laptop is in UEFI mode indeed. And the i586 installation which does not show this problem is an old legacy BIOS laptop. So i think this bug applies (correct me if needed).
(In reply to Herman Viaene from comment #4) > Sorry, forgot to mention that. The affected laptop is in UEFI mode indeed. > And the i586 installation which does not show this problem is an old legacy > BIOS laptop. So i think this bug applies (correct me if needed). So this is a different issue, your issue is that the default menu entry is changed by a kernel update. This bug is about install.sh being overwritten, so please create a new report with as much information as possible. Thanks.
This is still happening. On removal or update of a kernel /boot/grub2/install.sh is overwritten. (UEFI)
Priority: Normal => HighSeverity: normal => critical
The same occurs if|when XFdrake is run. (nvidia driver) Additionally this causes any|all kernel appends to be removed. GRUB_CMDLINE_LINUX_DEFAULT="foo' is completely removed from /etc/default/grub. Why is update-grub2 not being used. It does not cause /boot/grub2/install.sh to be overwritten nor are the appends lost.
CC: (none) => cae
install.sh was again overwritten on the last kernel update from 4.6.0.desktop-1 to 4.6.0.desktop-2. This is a real PITA! All grub modules in /boot/grub2/x86_64-efi are dated 30 mins ago when I updated, so it seems that grub2-install run, when there was no grub2-efi update. Why?
And NOW, grub2 is the ONLY bootloader choice allowed on ANY Mga6 install this will affect ALL systems both EFI and BIOS. Instead of only a few systems being affected now All systems will be and they will each require user intervention to ensure that the system remains bootable And usable, Pardon my English but this is BS.
(In reply to Barry Jackson from comment #0) And? We always overwrite /boot/grub/install.sh with grub-legacy. That's not an issue. We do NOT _run_ it on kernel updates. It's only run during initial installation. So what's the problem? We could we could move the call to write_grub2_install_sh() into install_grub2() but I want reasons before doing that. (In reply to Charles Edwards from comment #7) update-grub2 does be used. Check your facts About GRUB_CMDLINE_LINUX_DEFAULT: Writing /boot/grub2/install.sh has nothing to do with changing GRUB_CMDLINE_LINUX_DEFAULT About the later, we need to set a value as grub2-common cames with one. So we take the first kernel's one and set as default. I guess we could not alter it if /boot/grub2/install.sh already exist. But stop mixing different issues in the same bug report, that makes them unreadable.
Severity: critical => normalPriority: High => Normal
Summary: kernel updates overwrite existing /boot/grub2/install.sh in UEFI mode => kernel updates overwrite existing /boot/grub2/install.sh
(In reply to Thierry Vignaud from comment #10) > We do NOT _run_ it on kernel updates. > It's only run during initial installation. Or when one manuall runs drakboot.
Blocks: (none) => 416
(In reply to Thierry Vignaud from comment #10) > (In reply to Barry Jackson from comment #0) > And? > We always overwrite /boot/grub/install.sh with grub-legacy. > That's not an issue. > We do NOT _run_ it on kernel updates. > It's only run during initial installation. > So what's the problem? > > We could we could move the call to write_grub2_install_sh() into > install_grub2() but I want reasons before doing that. > > > > (In reply to Charles Edwards from comment #7) > update-grub2 does be used. Check your facts All I can say is that manually running update-grub2 Does Not alter /etc/default/grub Whatever is run when a new kernel is installed Does. > About GRUB_CMDLINE_LINUX_DEFAULT: > Writing /boot/grub2/install.sh has nothing to do with changing > GRUB_CMDLINE_LINUX_DEFAULT > > About the later, we need to set a value as grub2-common cames with one. > So we take the first kernel's one and set as default. > I guess we could not alter it if /boot/grub2/install.sh already exist. > > But stop mixing different issues in the same bug report, that makes them > unreadable. They are part and parcel of the same bug. Install a new kernel, run drakboot, run XFdrake; all will alter /boot/grub2/install.sh AND /etc/default/grub Test it see if you think I am wrong.
You said we don't use update-grub2. We do use it. This bug is about altering /boot/grub2/install.sh which is a drakx config file and this has nothing to do with altering /etc/default/grub so please stop mixing issues in this bug report.
CC: cae => (none)
Thierry, After further testing I agree that install.sh is not run on kernel update. The main issue here is https://bugs.mageia.org/show_bug.cgi?id=15583 for which no workaround has been implemented. The suggested workaround in that bug (grub2-install --bootloader-id=tmp --no-nvram) while maybe not working in the installer, DOES work for installed systems, so IMHO should be implemented. However this is rendered useless if a kernel update overwrites install.sh with the default, as the next kernel update clobbers nvram again. I would suggest: 1. If install.sh *must* be re-written (on kernel update) for some obscure reason then it's content should be left unchanged. 2. If a partition is specified for bootloader in drakboot then use grub2-install --bootloader-id=tmp --no-nvram for install.sh. (and grub2 install). 3. Try to do the same as above in installer but if this cannot be made to work just make sure that 1 and 2 are implemented so they work in installed systems. At least the nvram only gets clobbered on install that way. I hope that makes sense.
@ Barry I've been trying to understand what this whole discussion is all about, so my question/remark is: as far as I understand, bug15583 is also an installation bug, so you still would prefer to have my issue (as per Comment 2 and 4) reported as a separate bug??
(In reply to Herman Viaene from comment #15) > @ Barry > I've been trying to understand what this whole discussion is all about, so > my question/remark is: as far as I understand, bug15583 is also an > installation bug, so you still would prefer to have my issue (as per Comment > 2 and 4) reported as a separate bug?? Maybe you confused me in 2 & 4. If your issue is about the default option in the Mageia grub2 menu changing, then it's a different issue. If it is about the UEFI firmware booting into Mageia's grub2 rather than the system/partition that booted before the kernel update/install/use of drakboot then this is the issue here.
It's different from this bug, but I had it already in M6dev1 bug 18294.
commit cca8b7433a597970d1a463be377a3d9439a1b1cd Author: Thierry Vignaud <thierry.vignaud@...> Date: Mon Jun 6 11:15:19 2016 +0200 grub2: only overwrite install.sh when installing And only when actually installing boot loader, not when updating grub2 menu list (mga#17455) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=cca8b7433a597970d1a463be377a3d9439a1b1cd
Fixed in git
Source RPM: (none) => drakxtoolsStatus: NEW => RESOLVEDResolution: (none) => FIXEDAssignee: tmb => thierry.vignaud
(In reply to Barry Jackson from comment #8) > install.sh was again overwritten on the last kernel update from > 4.6.0.desktop-1 to 4.6.0.desktop-2. > > This is a real PITA! > > All grub modules in /boot/grub2/x86_64-efi are dated 30 mins ago when I > updated, > > so it seems that grub2-install run, when there was no grub2-efi update. Why? Is this issue still present? https://shortlife.co
CC: (none) => stickwargames