Page 11 of 15 FirstFirst ... 910111213 ... LastLast
Results 101 to 110 of 144

Thread: Install followed by fresh upgrade couple days later--lost by grub/EFI boot??

  1. #101

    Default Re: Install followed by fresh upgrade couple days later--lost by grub/EFI boot??

    Quote Originally Posted by mrmazda View Post
    Let's pretend post #101 is a clean new thread on a new page, no more need to backtrack to try to figure out what is going on.
    @mrmazda:

    OK, deal . . . I'm trying to respond to the requests for data in order in which made . . . since I did so well with your requests I'm now trying to catch up with karl's. I'll look into messing with the whitespace stuff . . . later on . . . .

    @karlm:

    Ran your commands, which did show something interesting in the first line . . . TW install was pointed to the HDD in which it is installed sdb1, but this data is showing it in sdc1????

    Code:
    butoh-mind@linux:~> su
    Password: 
    
    linux:/home/butoh-mind # df -h /boot/efi/ /
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sdc1       197M   30M  168M  16% /boot/efi
    /dev/sdb8        48G  5.6G   40G  13% /
    
    linux:/home/butoh-mind # grub2-install
    Installing for x86_64-efi platform.
    Installation finished. No error reported.
    
    linux:/home/butoh-mind # grub2-mkconfig -o /boot/grub2/grub.cfg
    Generating grub configuration file ...
    Found theme: /boot/grub2/themes/openSUSE/theme.txt
    Found linux image: /boot/vmlinuz-5.3.12-1-default
    Found initrd image: /boot/initrd-5.3.12-1-default
    Found linux image: /boot/vmlinuz-5.3.9-1-default
    Found initrd image: /boot/initrd-5.3.9-1-default
    Found Manjaro Linux (18.1.3) on /dev/sdb6
    Found openSUSE Tumbleweed on /dev/sdb7
    Found Mac OS X on /dev/sdc2
    Found Ubuntu 19.10 (19.10) on /dev/sdc5
    Found Ubuntu 19.10 (19.10) on /dev/sdc6
    done
    
    linux:/home/butoh-mind # ll /boot/efi/EFI/opensuse/
    total 3664
    -rwxr-xr-x 1 root root      58 Nov  9 13:07 boot.csv
    -rwxr-xr-x 1 root root     155 Nov  9 13:07 grub.cfg
    -rwxr-xr-x 1 root root 1238880 Nov  9 13:07 grub.efi
    -rwxr-xr-x 1 root root  143360 Nov  9 13:07 grubx64.efi
    -rwxr-xr-x 1 root root 1158688 Nov  9 13:07 MokManager.efi
    -rwxr-xr-x 1 root root 1208968 Nov  9 13:07 shim.efi
    
    linux:/home/butoh-mind # efibootmgr -v |grep 7f39c61b-b9d1-4378-8478-a5e99ae6079d
    Boot0000* opensuse    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\opensuse\grubx64.efi)
    Boot0005* Manjaro    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\Manjaro\grubx64.efi)
    Boot0006* grub-secureboot    HD(1,GPT,7f39c61b-b9d1-4378-8478-a5e99ae6079d,0x28,0x64000)/File(\EFI\grub\shim.efi)
    linux:/home/butoh-mind #

  2. #102
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    1,122

    Default Re: Install followed by fresh upgrade couple days later--lost by grub/EFI boot??

    Quote Originally Posted by non_space View Post
    Ran your commands, which did show something interesting in the first line . . . TW install was pointed to the HDD in which it is installed sdb1, but this data is showing it in sdc1?
    Code:
    butoh-mind@linux:~> su
    Password: 
    
    linux:/home/butoh-mind # df -h /boot/efi/ /
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sdc1       197M   30M  168M  16% /boot/efi
    /dev/sdb8        48G  5.6G   40G  13% /
    Yes. Your EFI system partition is sdc1 and Tumbleweed's system partition is sdb8.

    I suggest to have sdb1 as Tumbleweed's EFI system partition. To avoid further confusion and misunderstanding do exactly the following. Don't omit or change any step.

    Unmount: umount /boot/efi

    Check /etc/fstab for mountpoint:

    Code:
    erlangen:~ # grep /boot/efi /etc/fstab 
    UUID=4A24-B10D                             /boot/efi               vfat   defaults                      0  0
    erlangen:~ #
    Find file system UUID of sdb1:

    Code:
    erlangen:~ # lsblk -o PATH,UUID /dev/sdb
    PATH      UUID
    /dev/sdb  
    /dev/sdb1 4A24-B10D
    /dev/sdb2 690b51d7-7034-4585-b362-615f8056be45
    /dev/sdb3 492c5d5e-5d9b-4a99-9d34-e1f9cee09fe9
    /dev/sdb4 f4c5463f-f43d-420a-a0ea-4456cfbc54fa
    /dev/sdb5 204f7d0f-979a-41e1-a483-a597d0357e0b
    erlangen:~ #
    Change /etc/fstab to match the value displayed by lsblk output.

    Run 'mount -a'.

    Verify mount:

    Code:
    erlangen:~ # mount /boot/efi/
    mount: /boot/efi: /dev/sdb1 already mounted on /boot/efi.
    erlangen:~ #
    Check for GRUB_DISTRIBUTOR, value should be unique, not used by any other installation, no spaces.
    Code:
    erlangen:~ # grep DISTRIBUTO /etc/default/grub
    GRUB_DISTRIBUTOR=Tumbleweed-btrfs 
    erlangen:~ #
    Run the following:

    Code:
    grub2-install 
    grub2-mkconfig -o /boot/grub2/grub.cfg
    Verify contents of folder got updated:

    Code:
    erlangen:~ # ll /boot/efi/EFI/tumbleweed-btrfs/
    total 300
    -rwxr-xr-x 1 root root 307200 Dec  1 05:42 grubx64.efi
    erlangen:~ #
    Reboot into Tumbleweed's grub.
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), openSUSE Tumbleweed, KDE Plasma 5

  3. #103
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    1,835

    Default Re: Install followed by fresh upgrade couple days later--lost by grub/EFI boot??

    Do what karlmistelberger wrote in message #102.
    Reg. Linux User #211409 *** multibooting since 1992
    Primary: 42.3,TW,15.0 & 13.1 on Haswell w/ RAID
    Secondary: eComStation (OS/2)&42.3 on 965P/Radeon
    Tertiary: TW,15.0,42.3,Fedora,Debian,more on Kaby Lake,Q45,Q43,G41,G3X,965G,Cedar,Caicos,Oland,GT218&&&

  4. #104

    Default Re: Install followed by fresh upgrade couple days later--lost by grub/EFI boot??

    @karlm:

    OK, thanks for posting the commands to run, I will fiddle with it, just not today. I still don't think this points away from some fundamental error in the TW installer and how it handles grub among possibly other things. Why do I say that? Because the two "ubuntu 19.10" installs each are installed in sdc, they each have their own "EFI" disk that boots exclusively them, AND they each are listed in the main "EFI" disk that loads grub, and they can be selected to boot there, or any of the other sdb installs can be selected and booted via grub. Only the TW install fails to boot from grub.

    So, other busyness to take care of today, but when I get there I'll run through your list . . . and we'll see how it turns out . . . thoughts and prayers, etc.

    Also, there was the essentially month of Nov, mid and late where the live iso wouldn't boot at all via flash drive . . . although one did with burned DVD . . . . Point is there were "issues" going on, whether I failed to handle them or something in the data was in error is another story, seemingly yet to be determined.

    Quote Originally Posted by mrmazda View Post
    Do what karlmistelberger wrote in message #102.
    @mrmazda:

    I shall attempt to do so . . . when the time arrives . . . .

  5. #105
    Join Date
    Jun 2009
    Location
    Mangfall, Germany
    Posts
    1,507

    Default Re: Install followed by fresh upgrade couple days later--lost by grub/EFI boot??

    hi non_space,

    sugestion try,

    log into /dev/sdb

    mount /dev/sdc

    change line in fstab on /dev/sdc

    from
    UUID=4A24-B10D /boot/efi vfat defaults 0 0
    to
    UUID=67E3-17ED /boot/efi vfat defaults 0 0

    then run
    grub2-mkconfig -o /boot/grub2/grub.cfg

    then re-boot

    if grub menu and /dev/sdc still cannot be accessed,
    reverse the above and sorry for wasting your time

    hth

  6. #106

    Default Re: Install followed by fresh upgrade couple days later--lost by grub/EFI boot??

    Ran through Karl's requested series of commands, something interesting showed in the UUID data . . . listing the sdb1 location as the location?? rather than sdc1 as it did the last time?? I also edited the GRUB_DISTRIBUTOR id for TW . . . and I'm posting this data before rebooting out of it . . . . For good measure I went into Yast Bootloader and I changed the log out time as per mrmazda's suggestion in post #4??? or wherever . . . to generate new grub & initrd file??

    Keeping fingers crossed, not holding my breath . . . smiling . . . .

    Code:
    butoh-mind@linux:~> su
    Password: 
    linux:/home/butoh-mind # umount /boot/efi
    linux:/home/butoh-mind # grep /boot/efi /etc/fstab
    UUID=67E3-17ED                             /boot/efi  vfat  defaults      0  0
    
    linux:/home/butoh-mind # lsblk -o PATH,UUID /dev/sdb
    PATH       UUID
    /dev/sdb   
    /dev/sdb1  67E3-17ED
    /dev/sdb2  632a31b3-7430-3c28-a992-c92271adfa58
    /dev/sdb3  93f0ad8c-baed-3a31-8811-56b4a5cc6765
    /dev/sdb4  11b8a168-b278-3d38-8df7-daee4fec3d35
    /dev/sdb5  4bc32144-c9ad-3c87-9b64-44e2f89dd31b
    /dev/sdb6  078658fb-f9ce-42e1-a2d5-05b316a268de
    /dev/sdb7  56e0c14d-22ed-4466-b69c-2f62e5065bfc
    /dev/sdb8  d8c52ffb-c429-46c4-bb8f-b786ca361672
    /dev/sdb9  64c5dba2-bacd-4459-9904-6bda0fbe24e7
    /dev/sdb10 dac6d73c-5e42-47ce-af39-ba762532645d
    
    linux:/home/butoh-mind # mount -a
    linux:/home/butoh-mind # mount /boot/efi
    mount: /boot/efi: /dev/sdb1 already mounted on /boot/efi.
    
    linux:/home/butoh-mind # grep DISTRIBUTO /etc/default/grub
    GRUB_DISTRIBUTOR="TUMBLEWEED OpenSUSE"
    
    linux:/home/butoh-mind # sudo nano /etc/default/grub
    
    linux:/home/butoh-mind # grub2-install 
    Installing for x86_64-efi platform.
    Installation finished. No error reported.
    
    linux:/home/butoh-mind # grub2-mkconfig -o /boot/grub2/grub.cfg
    Generating grub configuration file ...
    Found theme: /boot/grub2/themes/openSUSE/theme.txt
    Found linux image: /boot/vmlinuz-5.3.12-1-default
    Found initrd image: /boot/initrd-5.3.12-1-default
    Found linux image: /boot/vmlinuz-5.3.9-1-default
    Found initrd image: /boot/initrd-5.3.9-1-default
    Found Manjaro Linux (18.1.3) on /dev/sdb6
    Found openSUSE Tumbleweed on /dev/sdb7
    Found Mac OS X on /dev/sdc2
    Found Ubuntu 19.10 (19.10) on /dev/sdc5
    Found Ubuntu 19.10 (19.10) on /dev/sdc6
    done
    
    linux:/home/butoh-mind # ll /boot/efi/EFI/opensusetw/
    total 136
    -rwxr-xr-x 1 root root 139264 Dec  3 09:59 grubx64.efi
    
    linux:/home/butoh-mind # grep DISTRIBUTO /etc/default/grub
    GRUB_DISTRIBUTOR="opensusetw"
    linux:/home/butoh-mind #

  7. #107

    Default Re: Install followed by fresh upgrade couple days later--lost by grub/EFI boot??

    et al:

    Well, that did not "prevail" as far as getting TW to boot via grub . . . in fact on reboot the two opensuse options were now showing as "sdc7" and "sdc8" and selecting the "sdc8" line goes again to the kernel panic.

    I rebooted and used SG2 to select the Gecko install and edited the DISTRIBUTOR line to another option with no white space . . . then rebooting and back into grub, the Manjaro system line worked fine . . . I ran "update-grub" there . . . .

    Other stuff to do now, when I get back to it I'll go into the ubuntu options and try to edit the grub listings . . . .

    Other than not being able to boot into TW via grub . . . it's operating well . . . .

  8. #108
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    1,122

    Default Re: Install followed by fresh upgrade couple days later--lost by grub/EFI boot??

    Quote Originally Posted by non_space View Post
    et al:

    Well, that did not "prevail" as far as getting TW to boot via grub . . . in fact on reboot the two opensuse options were now showing as "sdc7" and "sdc8" and selecting the "sdc8" line goes again to the kernel panic.

    I rebooted and used SG2 to select the Gecko install and edited the DISTRIBUTOR line to another option with no white space . . . then rebooting and back into grub, the Manjaro system line worked fine . . . I ran "update-grub" there . . . .

    Other stuff to do now, when I get back to it I'll go into the ubuntu options and try to edit the grub listings . . . .

    Other than not being able to boot into TW via grub . . . it's operating well . . . .
    You got lots of grubs (8?) and menu entries (64?). When booting a nonnative entry you need to update the menu by running ' grub2-mkconfig -o /boot/grub2/grub.cfg' on the system the current boot loader belongs to.

    To minimize confusion I refrain from detecting other systems by using:

    Code:
    erlangen:~ # grep PROBER /etc/default/grub
    GRUB_DISABLE_OS_PROBER="true"
    erlangen:~ #
    On tumbleweed-btrfs chain loading is enabled:

    Code:
    erlangen:~ # cat /etc/grub.d/40_custom 
    #!/bin/sh
    exec tail -n +3 $0
    # This file provides an easy way to add custom menu entries.  Simply type the
    # menu entries you want to add after this comment.  Be careful not to change
    # the 'exec tail' line above.
    
    menuentry 'SLED /dev/sdb3' {
        search --fs-uuid --no-floppy --set=root 6DEC-64F9
        chainloader /EFI/sled/grubx64.efi
    }
    
    menuentry 'Tumbleweed /dev/nvme0n1p2 - ext4' {
        search --fs-uuid --no-floppy --set=root 6DEC-64F9
        chainloader /EFI/tumbleweed-ext4/grubx64.efi
    }
    
    menuentry 'Arch Linux /dev/sdb2' {
        search --fs-uuid --no-floppy --set=root 4A24-B10D 
        chainloader /EFI/arch/grubx64.efi
    }
    
    menuentry 'Fedora 31 /dev/nvme0n1p1' {
        search --fs-uuid --no-floppy --set=root 6DEC-64F9
        chainloader /EFI/fedora/grubx64.efi
    }
    erlangen:~ #
    The above avoids stale entries in the boot menus.
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), openSUSE Tumbleweed, KDE Plasma 5

  9. #109

    Default Re: Install followed by fresh upgrade couple days later--lost by grub/EFI boot??

    Quote Originally Posted by karlmistelberger View Post
    You got lots of grubs (8?) and menu entries (64?). When booting a nonnative entry you need to update the menu by running ' grub2-mkconfig -o /boot/grub2/grub.cfg' on the system the current boot loader belongs to.

    To minimize confusion I refrain from detecting other systems by using:

    Code:
    erlangen:~ # grep PROBER /etc/default/grub
    GRUB_DISABLE_OS_PROBER="true"
    erlangen:~ #
    On tumbleweed-btrfs chain loading is enabled:

    [data removed to save cyber space]

    The above avoids stale entries in the boot menus.
    @Karl:

    Thanks again for continuing along . . . I did run the "grub2-mkconfig" command after editing both opensuse installs . . . . However that command is not recognized by Manjaro, there I ran "update-grub" . . . and then I tested again using grub . . . the TW installs have again returned to "sdb" but TW fails to boot from Grub menu . . . he one that yesterday was showing as being in sdc1, but today was back to sdb1????

    So, for this latest suggestion, what is the purpose of disabling recognition of other systems? Do we not want grub to be able to find or detect any possible new installations?? to avoid having to manually keep track of them??

    I get that there might still be "stale entries" . . . but I'm not sure if this track is getting the problem "solved"?? So far the only way to get TW booted is via SG2, and all other linux systems boot fine [still] with grub list . . . after getting distorted earlier today I think most of grub is "OK" . . . . And, still in grub, even though I edited system names and took out white space both sdb show as "OpenSUSE TUMBLEWEED" in grub, and both ubuntu shows as "Ubuntu 19.10" . . . i.e., it shows white space . . . and isn't reflecting my edits.

  10. #110
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    1,122

    Default Re: Install followed by fresh upgrade couple days later--lost by grub/EFI boot??

    Quote Originally Posted by non_space View Post
    @Karl:

    Thanks again for continuing along . . . I did run the "grub2-mkconfig" command after editing both opensuse installs . . . . However that command is not recognized by Manjaro, there I ran "update-grub" . . . and then I tested again using grub . . . the TW installs have again returned to "sdb" but TW fails to boot from Grub menu . . . he one that yesterday was showing as being in sdc1, but today was back to sdb1????

    So, for this latest suggestion, what is the purpose of disabling recognition of other systems? Do we not want grub to be able to find or detect any possible new installations?? to avoid having to manually keep track of them??

    I get that there might still be "stale entries" . . . but I'm not sure if this track is getting the problem "solved"?? So far the only way to get TW booted is via SG2, and all other linux systems boot fine [still] with grub list . . . after getting distorted earlier today I think most of grub is "OK" . . . . And, still in grub, even though I edited system names and took out white space both sdb show as "OpenSUSE TUMBLEWEED" in grub, and both ubuntu shows as "Ubuntu 19.10" . . . i.e., it shows white space . . . and isn't reflecting my edits.
    You can take a look at efivars and watch for debris:

    Code:
    erlangen:~ #  ll /sys/firmware/efi/efivars/
    total 0
    -rw-r--r-- 1 root root    5 Dec  3 21:59 ASR_TIMERSMI-2781600e-9df9-4ef8-a5a4-66501ae55c41
    -rw-r--r-- 1 root root    5 Dec  3 21:59 ASR_USER_DEF_VER-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
    -rw-r--r-- 1 root root  158 Dec  3 21:59 Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root  162 Dec  4 06:29 Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root  114 Dec  3 21:59 Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root  126 Dec  3 21:59 Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root  122 Dec  3 21:59 Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root  114 Dec  3 21:59 Boot0005-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root  124 Dec  3 21:59 Boot0007-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root  134 Dec  3 21:59 Boot0009-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root    6 Dec  3 21:59 BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root    8 Dec  3 21:59 BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root   20 Dec  3 21:59 BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root    5 Dec  3 21:59 CaseOpenStatus-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
    -rw-r--r-- 1 root root   60 Dec  3 21:59 ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root   60 Dec  3 21:59 ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root   34 Dec  3 21:59 ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root   34 Dec  3 21:59 ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root   20 Dec  3 21:59 DefaultBootOrder-45cf35f6-0d6e-4d04-856a-0370a5b16f53
    -rw-r--r-- 1 root root 1284 Dec  3 21:59 DmiArray-4b3082a3-80c6-4d7e-9cd0-583917265df1
    -rw-r--r-- 1 root root   20 Dec  3 21:59 DmiVar0200020700-4b3082a3-80c6-4d7e-9cd0-583917265df1
    -rw-r--r-- 1 root root   36 Dec  3 21:59 Ep-73dad563-8f27-42af-918f-8651eb0a93ef
    -rw-r--r-- 1 root root   34 Dec  3 21:59 ErrOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root   34 Dec  3 21:59 ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root   11 Dec  3 21:59 EzConfigData-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
    -rw-r--r-- 1 root root    8 Dec  3 21:59 FPDT_Volatile-01368881-c4ad-4b1d-b631-d57a8ec8db6b
    -rw-r--r-- 1 root root    5 Dec  3 21:59 GoodNightLed-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
    -rw-r--r-- 1 root root   12 Dec  3 21:59 HiiDB-1b838190-4625-4ead-abc9-cd5e6af18fe0
    -rw-r--r-- 1 root root   20 Dec  3 21:59 IntUcode-eda41d22-7729-5b91-b3ee-ba619921cefa
    -rw-r--r-- 1 root root 1564 Dec  3 21:59 KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root 1564 Dec  3 21:59 KEKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root    5 Dec  3 21:59 LoadSetupDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root    7 Dec  3 21:59 M2Setup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
    -rw-r--r-- 1 root root    8 Dec  3 21:59 MonotonicCounter-01368881-c4ad-4b1d-b631-d57a8ec8db6b
    -rw-r--r-- 1 root root    6 Dec  3 21:59 NBGopPlatformData-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
    -rw-r--r-- 1 root root   28 Dec  3 21:59 OA3MSDMvariable-01368881-c4ad-4b1d-b631-d57a8ec8db6b
    -rw-r--r-- 1 root root   12 Dec  3 21:59 OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root   12 Dec  3 21:59 OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root  643 Dec  3 21:59 PK-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root  643 Dec  3 21:59 PKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root   10 Dec  3 21:59 PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root   54 Dec  3 21:59 PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root   12 Dec  3 21:59 S3SS-4bafc2b4-02dc-4104-b236-d6f1b98d9e84
    -rw-r--r-- 1 root root    5 Dec  3 21:59 SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root    8 Dec  3 21:59 SetUpdateCountVar-81c76078-bfde-4368-9790-570914c01a65
    -rw-r--r-- 1 root root    5 Dec  3 21:59 SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root  132 Dec  3 21:59 SignatureSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root   34 Dec  3 21:59 StageChk-8f132913-6907-4192-a227-6cbcd7a50e6c
    -rw-r--r-- 1 root root    6 Dec  3 21:59 Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root    5 Dec  3 21:59 VendorKeys-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root   68 Dec  3 21:59 WriteOnceStatus-4b3082a3-80c6-4d7e-9cd0-583917265df1
    -rw-r--r-- 1 root root    5 Dec  3 21:59 aDefaultSetupConfig-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
    -rw-r--r-- 1 root root 3147 Dec  3 21:59 db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
    -rw-r--r-- 1 root root 3147 Dec  3 21:59 dbDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
    -rw-r--r-- 1 root root 3756 Dec  3 21:59 dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
    -rw-r--r-- 1 root root  656 Dec  3 21:59 dbxDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
    erlangen:~ #
    The above is pretty clean. but yours could be cluttered by dump-* files and more. If unsure what to delete post the contents of your /sys/firmware/efi/efivars/.

    The rationale for disabling osprober is purely pragmatic: probing can take a lot of time. Cross-booting requires updating two grubs consistently in most cases.

    Thus when frequently switching between systems and keeping them up to date it gets annoying. Turning it off and relying on chain loading makes things easy.
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), openSUSE Tumbleweed, KDE Plasma 5

Page 11 of 15 FirstFirst ... 910111213 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •