[opensuse] What changed in the 10/2/18 updates to grub2 causing unwanted os-proper to run?
All, Updates dated 10/2/18 in /etc/grub cause os-prober to run when it has not run in the year prior adding a windows entry to my grub.cfg? This is completely unwanted behavior. What changed? os-prober was installed automatically when Leap 42.3 was installed, but has been well-behaved up until these 10/2/18 updates. Why was this changed? Is it better to rpm -e os-prober? Or, can /etc/default/grub be trusted not to be overwritten so that GRUB_DISABLE_OS_PROBER="true" will be respected going forward? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Carlos E. R. <robin.listas@telefonica.net> [10-13-18 21:15]:
On 13/10/2018 22.03, David C. Rankin wrote:
All,
Updates dated 10/2/18 in /etc/grub cause os-prober to run when it has not
Clarification needed. Is that the 10 day of February of 2018?
perhaps since he resides in the USA, 2nd day of October of 2018. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/10/2018 10.49, David C. Rankin wrote:
On 10/13/2018 08:13 PM, Carlos E. R. wrote:
Clarification needed. Is that the 10 day of February of 2018?
No no... Oct 2, 2018 in Yankee format.
Well... as we are here from many countries, a date like that is not clear, better use the ISO standard >:-)
Updates dated 2018-10-02 in /etc/grub cause os-prober to run when it has not run in the year prior adding a windows entry to my grub.cfg? This is completely unwanted behavior. What changed?
Then new question: what are you using? 42.3, 15.0, Tw?
os-prober was installed automatically when Leap 42.3 was installed, but has been well-behaved up until these 2018-10-02 updates. Why was this changed?
Is it better to rpm -e os-prober? Or, can /etc/default/grub be trusted not to be overwritten so that GRUB_DISABLE_OS_PROBER="true" will be respected going forward?
If you do not want os-prober to run, you have to disable it. That entry in grub config should work; has worked for me always. Otherwise an update of grub, which I think usually triggers a grub rerun, will also do an os-prober run- -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 10/14/2018 04:30 AM, Carlos E. R. wrote:
os-prober was installed automatically when Leap 42.3 was installed, but has been well-behaved up until these 2018-10-02 updates. Why was this changed?
Is it better to rpm -e os-prober? Or, can /etc/default/grub be trusted not to be overwritten so that GRUB_DISABLE_OS_PROBER="true" will be respected going forward?
If you do not want os-prober to run, you have to disable it. That entry in grub config should work; has worked for me always.
Otherwise an update of grub, which I think usually triggers a grub rerun, will also do an os-prober run-
:) err, umm 42.3 like I said above (but granted, I could have done a zypper dup in the interim) Yes, I understand the grub rerun. What I don't understand is why for over a year of grub reruns, os-prober never included the Win10 boot entry until the last rerun. I recall a thread in the last couple of weeks where somebody complained that windows wasn't added, so I suspect there was a change made that now automatically causes it to run os-prober, but this is wrong as it will overwrite your windows bootloader if you are booting MBR from /dev/sda for both Windows and Linux. That is what prompted my question of "What changed in the Oct. 2, 2018 update to grub2 so as to invoke os-prober causing it to populate grub.cfg with the Windows entry. More importantly, if this is desired behavior now, will GRUB_DISABLE_OS_PROBER="true" be respected and not overwritten by subsequent grub2 updates, or should I just rpm -e os-prober to make sure? -- David C. Rankin, J.D.,P.E.
On 15/10/2018 07.49, David C. Rankin wrote:
On 10/14/2018 04:30 AM, Carlos E. R. wrote:
os-prober was installed automatically when Leap 42.3 was installed, but has been well-behaved up until these 2018-10-02 updates. Why was this changed?
Is it better to rpm -e os-prober? Or, can /etc/default/grub be trusted not to be overwritten so that GRUB_DISABLE_OS_PROBER="true" will be respected going forward?
If you do not want os-prober to run, you have to disable it. That entry in grub config should work; has worked for me always.
Otherwise an update of grub, which I think usually triggers a grub rerun, will also do an os-prober run-
:) err, umm 42.3 like I said above (but granted, I could have done a zypper dup in the interim)
Yes, I understand the grub rerun. What I don't understand is why for over a year of grub reruns, os-prober never included the Win10 boot entry until the last rerun.
I recall a thread in the last couple of weeks where somebody complained that windows wasn't added, so I suspect there was a change made that now automatically causes it to run os-prober, but this is wrong as it will overwrite your windows bootloader if you are booting MBR from /dev/sda for both Windows and Linux.
That is what prompted my question of "What changed in the Oct. 2, 2018 update to grub2 so as to invoke os-prober causing it to populate grub.cfg with the Windows entry.
More importantly, if this is desired behavior now, will
GRUB_DISABLE_OS_PROBER="true"
be respected and not overwritten by subsequent grub2 updates, or should I just rpm -e os-prober to make sure?
I expect that variable to be obeyed. I don't know if I have applied that update to my machines having Windows, so I'll find out later. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 10/15/2018 07:45 AM, Carlos E. R. wrote:
More importantly, if this is desired behavior now, will
GRUB_DISABLE_OS_PROBER="true"
be respected and not overwritten by subsequent grub2 updates, or should I just rpm -e os-prober to make sure? I expect that variable to be obeyed. I don't know if I have applied that update to my machines having Windows, so I'll find out later.
Yes, and this is somewhat a typical setup. I have win10 on sda and opensuse on sdb. I do not want grub2 or any bootloader messing with sda. I specifically installed opensuse on sdb with grub2 in the mbr of sdb to prevent any hint of the Linux install being visible should somebody steal by laptop. So to reach sdb to boot I use the bios selection to boot from sdb. It is pointless to have os-prober put a windows entry in grub.cfg for just that reason. The only way I get to grub is to choose a custom boot option. Ever since I installed 42.3, there has been no issue of os-prober putting windows in grub.cfg, but starting with my last update and the updated grub2 package, os-prober now inserts windows for some bewildering reason. To get rid of what os-prober added, I just commented the entry out in grub.cfg, but I would like to avoid having to do that again. If it is not an initial install, os-prober shouldn't be adding anything unless it is specifically told to do it. -- David C. Rankin, J.D.,P.E.
On 16/10/2018 00.41, David C. Rankin wrote:
On 10/15/2018 07:45 AM, Carlos E. R. wrote:
More importantly, if this is desired behavior now, will
GRUB_DISABLE_OS_PROBER="true"
be respected and not overwritten by subsequent grub2 updates, or should I just rpm -e os-prober to make sure? I expect that variable to be obeyed. I don't know if I have applied that update to my machines having Windows, so I'll find out later.
Yes, and this is somewhat a typical setup. I have win10 on sda and opensuse on sdb. I do not want grub2 or any bootloader messing with sda. I specifically installed opensuse on sdb with grub2 in the mbr of sdb to prevent any hint of the Linux install being visible should somebody steal by laptop. So to reach sdb to boot I use the bios selection to boot from sdb. It is pointless to have os-prober put a windows entry in grub.cfg for just that reason. The only way I get to grub is to choose a custom boot option.
Why not simply encrypt the disk?
Ever since I installed 42.3, there has been no issue of os-prober putting windows in grub.cfg, but starting with my last update and the updated grub2 package, os-prober now inserts windows for some bewildering reason.
To get rid of what os-prober added, I just commented the entry out in grub.cfg, but I would like to avoid having to do that again. If it is not an initial install, os-prober shouldn't be adding anything unless it is specifically told to do it.
No, that should not work. Set it to TRUE. Commenting the entry sets default value, which appears to be "false". -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))
On 10/15/2018 06:46 PM, Carlos E. R. wrote:
On 16/10/2018 00.41, David C. Rankin wrote:
To get rid of what os-prober added, I just commented the entry out in grub.cfg, but I would like to avoid having to do that again. If it is not an initial install, os-prober shouldn't be adding anything unless it is specifically told to do it.
No, that should not work. Set it to TRUE.
Commenting the entry sets default value, which appears to be "false".
Oh, Sorry Carlos, I mean I commented the following: ### BEGIN /etc/grub.d/30_os-prober ### # menuentry 'Windows 10 (loader) (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-chain-6C1A63A81A636E50' { # insmod part_msdos # insmod ntfs # set root='hd0,msdos1' # if [ x$feature_platform_search_hint = xy ]; then # search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1' 6C1A63A81A636E50 # else # search --no-floppy --fs-uuid --set=root 6C1A63A81A636E50 # fi # parttool ${root} hidden- # drivemap -s (hd0) ${root} # chainloader +1 # } ### END /etc/grub.d/30_os-prober ### Why would that cause the entry to be changed? -- David C. Rankin, J.D.,P.E.
On 16/10/2018 07.32, David C. Rankin wrote:
On 10/15/2018 06:46 PM, Carlos E. R. wrote:
On 16/10/2018 00.41, David C. Rankin wrote:
To get rid of what os-prober added, I just commented the entry out in grub.cfg, but I would like to avoid having to do that again. If it is not an initial install, os-prober shouldn't be adding anything unless it is specifically told to do it.
No, that should not work. Set it to TRUE.
Commenting the entry sets default value, which appears to be "false".
Oh, Sorry Carlos, I mean I commented the following:
### BEGIN /etc/grub.d/30_os-prober ### # menuentry 'Windows 10 (loader) (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-chain-6C1A63A81A636E50' { # insmod part_msdos # insmod ntfs # set root='hd0,msdos1' # if [ x$feature_platform_search_hint = xy ]; then # search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1' 6C1A63A81A636E50 # else # search --no-floppy --fs-uuid --set=root 6C1A63A81A636E50 # fi # parttool ${root} hidden- # drivemap -s (hd0) ${root} # chainloader +1 # } ### END /etc/grub.d/30_os-prober ###
Why would that cause the entry to be changed?
Why are you so complicated? :-) Just edit "/etc/default/grub": GRUB_DISABLE_OS_PROBER="true" It is that simple. And yes, it has to work, else it is a bug and report in bugzilla. I will test that upgrade later in the day. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 16/10/2018 13.28, Carlos E. R. wrote:
On 16/10/2018 07.32, David C. Rankin wrote:
On 10/15/2018 06:46 PM, Carlos E. R. wrote:
Just edit "/etc/default/grub":
GRUB_DISABLE_OS_PROBER="true"
It is that simple. And yes, it has to work, else it is a bug and report in bugzilla.
I will test that upgrade later in the day.
I updated a 15.0 laptop with no issue. Later I'll do my 42.3 laptop. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 10/16/2018 06:28 AM, Carlos E. R. wrote:
Why are you so complicated? :-)
Just edit "/etc/default/grub":
GRUB_DISABLE_OS_PROBER="true"
It is that simple. And yes, it has to work, else it is a bug and report in bugzilla.
I will test that upgrade later in the day.
I'm just difficult.... ;) I've already added GRUB_DISABLE_OS_PROBER="true" to /etc/default/grub before posting this thread. My point what "What changed?" I have not had GRUB_DISABLE_OS_PROBER="true" since my install of 42.3 over a year ago, and os-prober has never run adding win10 to grub.cfg before, so why now? Whatever the grub2 update on Oct 2, 18 was it created: l /etc/default total 60 drwxr-xr-x 2 root root 4096 Oct 13 14:55 . drwxr-xr-x 142 root root 12288 Oct 16 07:50 .. -rw-r--r-- 1 root root 1836 Oct 13 14:55 grub <=== -rw-r--r-- 1 root root 1392 Mar 6 2018 grub.old <=== -rw-r--r-- 1 root root 76 Apr 2 2018 grub_installdevice (the grub file was dated Oct 2, 2018 before I changed GRUB_DISABLE_OS_PROBER="true") So this new grub2 package replaced my defaults and added the following lines: GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt SUSE_BTRFS_SNAPSHOT_BOOTING="true" # GRUB_DISABLE_OS_PROBER="false" GRUB_DISABLE_OS_PROBER="true" GRUB_ENABLE_CRYPTODISK="n" GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16" (I commented the "false" that was addeded to set GRUB_DISABLE_OS_PROBER="true") If this overwrote my prior defaults -- then what the heck is going to prevent the next nonsensical change from overwriting them again? Why the hell would I want SUSE_BTRFS_SNAPSHOT_BOOTING="true", when my system is ext4?? At least the system was smart enough to limit the damage to grub_installdevice this time and not wipe my win10 bootloader as it did on 42.2 when this problem was fixed the last time. os-prober should not be running on update, unless I tell it to. New /etc/default/grub should not set os-prober to run by default and it should not replace or add options. I can't believe the /etc/defaults/grub was not installed as a .rpmnew instead of adding options without doing so. This is what prompted the question -- What changed? -- David C. Rankin, J.D.,P.E.
On 16/10/2018 18.40, David C. Rankin wrote:
On 10/16/2018 06:28 AM, Carlos E. R. wrote:
Why are you so complicated? :-)
Just edit "/etc/default/grub":
GRUB_DISABLE_OS_PROBER="true"
It is that simple. And yes, it has to work, else it is a bug and report in bugzilla.
I will test that upgrade later in the day.
I'm just difficult.... ;)
I've already added GRUB_DISABLE_OS_PROBER="true" to /etc/default/grub before posting this thread.
My point what "What changed?" I have not had GRUB_DISABLE_OS_PROBER="true" since my install of 42.3 over a year ago, and os-prober has never run adding win10 to grub.cfg before, so why now?
Whatever the grub2 update on Oct 2, 18 was it created:
l /etc/default total 60 drwxr-xr-x 2 root root 4096 Oct 13 14:55 . drwxr-xr-x 142 root root 12288 Oct 16 07:50 .. -rw-r--r-- 1 root root 1836 Oct 13 14:55 grub <=== -rw-r--r-- 1 root root 1392 Mar 6 2018 grub.old <=== -rw-r--r-- 1 root root 76 Apr 2 2018 grub_installdevice
(the grub file was dated Oct 2, 2018 before I changed GRUB_DISABLE_OS_PROBER="true")
So this new grub2 package replaced my defaults and added the following lines:
GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt SUSE_BTRFS_SNAPSHOT_BOOTING="true" # GRUB_DISABLE_OS_PROBER="false" GRUB_DISABLE_OS_PROBER="true" GRUB_ENABLE_CRYPTODISK="n" GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16"
(I commented the "false" that was addeded to set GRUB_DISABLE_OS_PROBER="true")
Let me get this straight, because it is not clear. You can prove, via dates on the files grub and grub.old (one is older than the update, and one newer), that the update changed GRUB_DISABLE_OS_PROBER to false on file /etc/default/default? Then what the heck are you waiting to report this fact, and this fact alone, to Bugzilla? Why this long post without saying this simple fact clearly in a short paragraph here, in the first post, heinn? ;-) Now go and store yast logs (run "save_y2logs") safely before they get rotated out.
If this overwrote my prior defaults -- then what the heck is going to prevent the next nonsensical change from overwriting them again?
Why the hell would I want SUSE_BTRFS_SNAPSHOT_BOOTING="true", when my system is ext4??
It does no harm, either. It is easier to add an entry every time than checking to see if it necessary. That logic is delayed to runtime instead. And if you reformat the disk, the entry is already there.
At least the system was smart enough to limit the damage to grub_installdevice this time and not wipe my win10 bootloader as it did on 42.2 when this problem was fixed the last time.
os-prober should not be running on update, unless I tell it to. New /etc/default/grub should not set os-prober to run by default and it should not replace or add options. I can't believe the /etc/defaults/grub was not installed as a .rpmnew instead of adding options without doing so.
This is what prompted the question -- What changed?
os-prober run because the setting on file /etc/default/default had been altered to tell it to run. That's not the original problem and you can ignore it. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 16/10/2018 07.32, David C. Rankin wrote:
On 10/15/2018 06:46 PM, Carlos E. R. wrote:
On 16/10/2018 00.41, David C. Rankin wrote:
To get rid of what os-prober added, I just commented the entry out in grub.cfg, but I would like to avoid having to do that again. If it is not an initial install, os-prober shouldn't be adding anything unless it is specifically told to do it.
No, that should not work. Set it to TRUE.
Commenting the entry sets default value, which appears to be "false".
Oh, Sorry Carlos, I mean I commented the following:
### BEGIN /etc/grub.d/30_os-prober ### # menuentry 'Windows 10 (loader) (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-chain-6C1A63A81A636E50' { # insmod part_msdos # insmod ntfs # set root='hd0,msdos1' # if [ x$feature_platform_search_hint = xy ]; then # search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1' 6C1A63A81A636E50 # else # search --no-floppy --fs-uuid --set=root 6C1A63A81A636E50 # fi # parttool ${root} hidden- # drivemap -s (hd0) ${root} # chainloader +1 # } ### END /etc/grub.d/30_os-prober ###
Why would that cause the entry to be changed?
Notice that that file can be replaced by an update. There you have the reason for your problem. Just edit "/etc/default/grub" -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 16/10/18 9:41 am, David C. Rankin wrote:
More importantly, if this is desired behavior now, will
GRUB_DISABLE_OS_PROBER="true"
be respected and not overwritten by subsequent grub2 updates, or should I just rpm -e os-prober to make sure? I expect that variable to be obeyed. I don't know if I have applied that update to my machines having Windows, so I'll find out later. Yes, and this is somewhat a typical setup. I have win10 on sda and opensuse on sdb. I do not want grub2 or any bootloader messing with sda. I specifically installed opensuse on sdb with grub2 in the mbr of sdb to prevent any hint of
On 10/15/2018 07:45 AM, Carlos E. R. wrote: the Linux install being visible should somebody steal by laptop. So to reach sdb to boot I use the bios selection to boot from sdb. It is pointless to have os-prober put a windows entry in grub.cfg for just that reason. The only way I get to grub is to choose a custom boot option.
Ever since I installed 42.3, there has been no issue of os-prober putting windows in grub.cfg, but starting with my last update and the updated grub2 package, os-prober now inserts windows for some bewildering reason.
To get rid of what os-prober added, I just commented the entry out in grub.cfg, but I would like to avoid having to do that again. If it is not an initial install, os-prober shouldn't be adding anything unless it is specifically told to do it.
David, I have a similar setup as you have -- but in reverse :-), ie Win7 Pro is on sdb and Linux OSs on sda. It may help if you read the article to be found here: http://www.linuxidentity.com/us/index.php?name=Downloads and it is the first one on the right hand side of the 2 bottom columns and called, "Linux Starter :: Installing Multipl..." which, in fact, is a pdf file; the full title is "Installing Multiple Distributions on the same computer", author Sankret Totewar. This article used to have its own URL but is now on this linuxidentity.com site. BC -- "One of the wettest we've ever seen from the standpoint of water". Donald Trump's observation on Hurricane Florence, 19 September 2018. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/17/2018 03:02 AM, Basil Chupin wrote:
David, I have a similar setup as you have -- but in reverse :-), ie Win7 Pro is on sdb and Linux OSs on sda.
It may help if you read the article to be found here:
http://www.linuxidentity.com/us/index.php?name=Downloads
and it is the first one on the right hand side of the 2 bottom columns and called, "Linux Starter :: Installing Multipl..." which, in fact, is a pdf file; the full title is "Installing Multiple Distributions on the same computer", author Sankret Totewar. This article used to have its own URL but is now on this linuxidentity.com site.
Thank you BC, Will give it a full read and see if it sheds light on why os-prober to start mucking with my grub.cfg. It was one of these packages that cause the problems (from rpm -queryformat) Sat 06 Oct 2018 02:08:25 AM CDT grub2 2.02-13.1 Sat 06 Oct 2018 02:08:25 AM CDT os-prober 1.61-22.1 Sat 06 Oct 2018 02:08:26 AM CDT grub2-i386-pc 2.02-13.1 Sat 06 Oct 2018 02:08:30 AM CDT grub2-x86_64-efi 2.02-13.1 Sat 06 Oct 2018 02:08:31 AM CDT grub2-snapper-plugin 2.02-13.1 Sat 06 Oct 2018 02:08:31 AM CDT grub2-systemd-sleep-plugin 2.02-13.1 If anyone is familiar with which package may have done that or could narrow it down, it would be appreciated. Something changed. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17/10/2018 10.45, David C. Rankin wrote:
On 10/17/2018 03:02 AM, Basil Chupin wrote:
David, I have a similar setup as you have -- but in reverse :-), ie Win7 Pro is on sdb and Linux OSs on sda.
It may help if you read the article to be found here:
http://www.linuxidentity.com/us/index.php?name=Downloads
and it is the first one on the right hand side of the 2 bottom columns and called, "Linux Starter :: Installing Multipl..." which, in fact, is a pdf file; the full title is "Installing Multiple Distributions on the same computer", author Sankret Totewar. This article used to have its own URL but is now on this linuxidentity.com site.
Thank you BC,
Will give it a full read and see if it sheds light on why os-prober to start mucking with my grub.cfg.
It was one of these packages that cause the problems (from rpm -queryformat)
Sat 06 Oct 2018 02:08:25 AM CDT grub2 2.02-13.1 Sat 06 Oct 2018 02:08:25 AM CDT os-prober 1.61-22.1 Sat 06 Oct 2018 02:08:26 AM CDT grub2-i386-pc 2.02-13.1 Sat 06 Oct 2018 02:08:30 AM CDT grub2-x86_64-efi 2.02-13.1 Sat 06 Oct 2018 02:08:31 AM CDT grub2-snapper-plugin 2.02-13.1 Sat 06 Oct 2018 02:08:31 AM CDT grub2-systemd-sleep-plugin 2.02-13.1
If anyone is familiar with which package may have done that or could narrow it down, it would be appreciated. Something changed.
Just write the bugzilla I told you and add that list. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
participants (4)
-
Basil Chupin -
Carlos E. R. -
David C. Rankin -
Patrick Shanahan