Re: TW slow to process "post trans script" grub2-i386????
Is he using Apple hardware? I didn't notice. Then of course, that's the cause of the problem.
Yes, now I notice "OSX" above; it is not "OSes".
et al:
The scourge of using linux on Apple hardware . . . !!! Mr Miata has pointed out the "apple" problem before, but I have been running grub on this machine for years without the level of slowness in the processing that seems to have crept in recently . . . to an extent that is diffficult to provide the time for. I don't use grub to boot OSX, so nothing in OSX is connected back into grub . . . .
AFAIK, it is not grub, it is os-prober, which is run by part of the grub installation process to find out what other bootable partitions are there. And as I recall, some types of partitions drive os-prober bonkers. AFAIK, that includes some Apple partitions.
Of course, you can simply not run os-prober, ever again, and create manual entries in grub for whatever other bootable partitions you have, in /boot/grub2/custom.cfg.
@Carlos, et al: Thanks for that suggestion on going to the manual entries in grub idea. I think that Felix M. made that suggestion to me previously, but I have a lot going on in my life these days and making yet more time to go manual (editing with each kernel upgrade, etc) seemed to require more time and thought energy than I have to spare at the moment . . . . It may turn out to be "the solution" . . . but these days if I can just "move it around" to another OS that somehow seems easier . . . at the moment. I can face into the fact that "pilot error" is involved, but previously that error did not take up such huge swathes of time to . . . compensate. Seems like something has changed on the software side that has increased the magnitude of the "bonkerism" in regards to os-prober. I'll try to post back if and when adjustments have been made, that have made a difference . . . . Thanks for the bandwidth.
Hi Fritz, On Thu, 16 Mar 2023, 15:35:11 +0100, Fritz Hudnut wrote:
[...] It may turn out to be "the solution" . . . but these days if I can just "move it around" to another OS that somehow seems easier . . . at the moment. I can face into the fact that "pilot error" is involved, but previously that error did not take up such huge swathes of time to . . . compensate. Seems like something has changed on the software side that has increased the magnitude of the "bonkerism" in regards to os-prober.
I might suggest/propose a different way to avoid running os-prober at all. As all UEFI Bios'es offer the way to boot a specific OS by selecting it from the list of OSes installed in the "EFI System" partition, it is probably as easy as choosing it from the Grub list generated by os-prober. Using Linux it's even possible to define the OS to be booted next, just for one go, leaving the "standard/default" OS as is: : Get the list of installed OSes: efibootmgr : Choose the next one: efibootmgr -n openSUSE-Tumbleweed The "standard/default" OS can be defined by moving its number to be front of the "BootOrder:" list: : Move Boot0002 to the front: efibootmgr -o 2,... # Replace ... with your actual values If you can live with this, you just need to add GRUB_DISABLE_OS_PROBER="true" to /etc/default/grub and re-generate your /boot/grub2/grub.cfg: grub2-mkconfig -o /boot/grub2/grub.cfg You might need to do similar stuff on all your other Linux installations. HTH, cheers. l8er manfred
On Thu, 16 Mar 2023, 15:55:08 +0100, Manfred Hollstein wrote:
Hi Fritz,
On Thu, 16 Mar 2023, 15:35:11 +0100, Fritz Hudnut wrote:
[...] It may turn out to be "the solution" . . . but these days if I can just "move it around" to another OS that somehow seems easier . . . at the moment. I can face into the fact that "pilot error" is involved, but previously that error did not take up such huge swathes of time to . . . compensate. Seems like something has changed on the software side that has increased the magnitude of the "bonkerism" in regards to os-prober.
I might suggest/propose a different way to avoid running os-prober at all. As all UEFI Bios'es offer the way to boot a specific OS by selecting it from the list of OSes installed in the "EFI System" partition, it is probably as easy as choosing it from the Grub list ^by pressing some BIOS specific key - usually Alt-F2 or Alt-F12 on Dell PCs generated by os-prober. Using Linux it's even possible to define the OS to be booted next, just for one go, leaving the "standard/default" OS as is:
: Get the list of installed OSes: efibootmgr : Choose the next one: efibootmgr -n openSUSE-Tumbleweed
The "standard/default" OS can be defined by moving its number to be front of the "BootOrder:" list:
: Move Boot0002 to the front: efibootmgr -o 2,... # Replace ... with your actual values
If you can live with this, you just need to add
GRUB_DISABLE_OS_PROBER="true"
to /etc/default/grub and re-generate your /boot/grub2/grub.cfg:
grub2-mkconfig -o /boot/grub2/grub.cfg
You might need to do similar stuff on all your other Linux installations.
HTH, cheers.
l8er manfred
Fritz Hudnut composed on 2023-03-16 07:35 (UTC-0700):
I have a lot going on in my life these days and making yet more time to go manual (editing with each kernel upgrade, etc) seemed to require more time and thought energy than I have to spare at the moment . . . .
It may turn out to be "the solution"
Maybe your optimal solution is to cut the number of different operating systems down and spend more time in each one. Under the covers, except for package management, it's just Linus' kernel and systemd running most shows. The big differences are in the various DE's. By now you should have been able to name a favorite and exclude the others. It's like you intend your time to be spread thin. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2023-03-16 19:01, Felix Miata wrote:
Fritz Hudnut composed on 2023-03-16 07:35 (UTC-0700):
I have a lot going on in my life these days and making yet more time to go manual (editing with each kernel upgrade, etc) seemed to require more time and thought energy than I have to spare at the moment . . . .
It may turn out to be "the solution"
Maybe your optimal solution is to cut the number of different operating systems down and spend more time in each one. Under the covers, except for package management, it's just Linus' kernel and systemd running most shows. The big differences are in the various DE's. By now you should have been able to name a favorite and exclude the others. It's like you intend your time to be spread thin.
Maybe find out if os-prober has a way to tell it to ignore certain partitions. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Side note: The way you post, using digests, breaks threading and makes difficult to follow your posts. I can not easily go back and find out how this issue started. On 2023-03-16 15:35, Fritz Hudnut wrote:
Thanks for that suggestion on going to the manual entries in grub idea. I think that Felix M. made that suggestion to me previously, but I have a lot going on in my life these days and making yet more time to go manual (editing with each kernel upgrade, etc)
No, you don't have to edit entries ever. There are two ways. One, you use the kernel link: Telcontar:~ # ls -l /boot/vmlinuz lrwxrwxrwx 1 root root 36 Feb 19 22:27 /boot/vmlinuz -> vmlinuz-5.14.21-150400.24.46-default Telcontar:~ # ls -l /boot/initrd lrwxrwxrwx 1 root root 35 Feb 19 22:27 /boot/initrd -> initrd-5.14.21-150400.24.46-default Telcontar:~ # Two, you don't create entries for the kernels, but to the grub of those partitions: cat /boot/grub2/custom.cfg # If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update # /boot/grub2/grub.cfg. # Needed for changes to the default boot to hold. menuentry 'Gestor (por uuid)' --id cer-gestor-001 { insmod part_gpt insmod ext2 set root='hd2,gpt2' if search --no-floppy --fs-uuid --set=root 943d6... ; then chainloader +1 else echo Could not find this OS instance, will not boot (3) sleep 1 fi } menuentry 'oS 12.3, sda1 (label aux_extrasys)' --id cer-sda1-001 { insmod part_msdos insmod ext2 set root='hd0,msdos1' if search --no-floppy --fs-uuid --set=root 3f87... ; then chainloader +1 else echo Could not find this OS instance, will not boot (3) sleep 1 fi } -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
participants (4)
-
Carlos E. R.
-
Felix Miata
-
Fritz Hudnut
-
Manfred Hollstein