English for non-English words other than Erweitert please.
Rosetta Stone of grub.cfg:
erlangen:~ # grep menuentry /boot/efi/EFI/fedora/grub.cfg |cut -d \' -f 2
Fedora (4.19.5-300.fc29.x86_64) 29 (Workstation Edition)
Fedora (0-rescue-9742ec8b11704f37811b4ded5cb4fae7) 29 (Workstation Edition)
openSUSE Tumbleweed (on /dev/nvme0n1p2)
Advanced options for openSUSE Tumbleweed (on /dev/nvme0n1p2)
openSUSE Tumbleweed (on /dev/nvme0n1p2)
openSUSE Tumbleweed, mit Linux 4.19.5-1-default (on /dev/nvme0n1p2)
openSUSE Tumbleweed, mit Linux 4.19.4-1-default (on /dev/nvme0n1p2)
Ubuntu 18.04.1 LTS (18.04) (on /dev/sdb2)
Advanced options for Ubuntu 18.04.1 LTS (18.04) (on /dev/sdb2)
Ubuntu (on /dev/sdb2)
Ubuntu, mit Linux 4.15.0-36-generic (on /dev/sdb2)
Ubuntu, mit Linux 4.15.0-36-generic (recovery mode) (on /dev/sdb2)
Ubuntu, mit Linux 4.15.0-29-generic (on /dev/sdb2)
Ubuntu, mit Linux 4.15.0-29-generic (recovery mode) (on /dev/sdb2)
openSUSE Tumbleweed (on /dev/sdb3)
Advanced options for openSUSE Tumbleweed (on /dev/sdb3)
openSUSE Tumbleweed (on /dev/sdb3)
openSUSE Tumbleweed, with Linux 4.19.1-1-default (on /dev/sdb3)
openSUSE Tumbleweed, with Linux 4.18.15-1-default (on /dev/sdb3)
erlangen:~ #
Drives:
erlangen:~ # inxi -D
Drives: Local Storage: total: 4.56 TiB used: 1.85 TiB (40.5%)
ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 950 PRO 512GB size: 476.94 GiB
ID-2: /dev/sda vendor: Western Digital model: WD40EZRX-22SPEB0 size: 3.64 TiB
ID-3: /dev/sdb vendor: Samsung model: SSD 850 EVO 500GB size: 465.76 GiB
erlangen:~ #
Devices:
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda2 swap 3bfe28c8-c708-4859-9222-94b0ea4bddca [SWAP]
├─sda3 ext4 Tumbleweed-HDD dbc33c75-0fbb-4619-add6-d204ecf63a43 /Tumbleweed-HDD
└─sda4 ext4 Home-HDD f5177cae-4082-44ed-9471-b99030f06866 /home-HDD
sdb
├─sdb1 vfat 4A24-B10D
├─sdb2 ext4 Xubuntu f3c36796-d1b7-426d-9bef-6c61c39db0b1
├─sdb3 ext4 Tumbleweed-SSD 083dd95e-4073-43b1-a213-ad3ed8dd9a33 /Tumbleweed-SSD
└─sdb4 ext4 Home-SSD f4c5463f-f43d-420a-a0ea-4456cfbc54fa /home-SSD
nvme0n1
├─nvme0n1p1 ext4 Fedora a233e0b2-944b-4d62-a948-cbcc134b357f /Fedora
├─nvme0n1p2 ext4 Tumbleweed 8b190950-c141-4351-9198-7a9592b4fb34 /
├─nvme0n1p3 ext4 Home 704621ef-9b45-4e96-ba7f-1becd3924f08 /home
└─nvme0n1p4 vfat 6DEC-64F9 /boot/efi
erlangen:~ #
fstab:
erlangen:~ # cat /etc/fstab
UUID=8b190950-c141-4351-9198-7a9592b4fb34 / ext4 defaults 0 0
UUID=704621ef-9b45-4e96-ba7f-1becd3924f08 /home ext4 defaults 0 0
UUID=f5177cae-4082-44ed-9471-b99030f06866 /home-HDD ext4 defaults 0 0
UUID=dbc33c75-0fbb-4619-add6-d204ecf63a43 /Tumbleweed-HDD ext4 defaults 0 0
UUID=083dd95e-4073-43b1-a213-ad3ed8dd9a33 /Tumbleweed-SSD ext4 defaults 0 0
UUID=f4c5463f-f43d-420a-a0ea-4456cfbc54fa /home-SSD ext4 defaults 0 0
UUID=6DEC-64F9 /boot/efi vfat defaults 0 0
#
/home-HDD/drives/SAMSUNG-SP2014N/p6.sqsh /drives/SAMSUNG-SP2014N/p6 squashfs noauto,loop 0 0
UUID=3bfe28c8-c708-4859-9222-94b0ea4bddca swap swap defaults 0 0
UUID=a233e0b2-944b-4d62-a948-cbcc134b357f /Fedora ext4 noauto,data=ordered 0 0
erlangen:~ #
Boot managers:
erlangen:~ # efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0004,0005,0006
Boot0000* opensuse HD(4,GPT,0497bfdf-73d7-47a8-9d8e-6b911574f774,0x800,0x32000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0001* Fedora HD(4,GPT,0497bfdf-73d7-47a8-9d8e-6b911574f774,0x800,0x32000)/File(\EFI\FEDORA\SHIMX64.EFI)
Boot0004* ubuntu HD(4,GPT,0497bfdf-73d7-47a8-9d8e-6b911574f774,0x800,0x32000)/File(\EFI\UBUNTU\SHIMX64.EFI)
Boot0005* ubuntu HD(4,GPT,0497bfdf-73d7-47a8-9d8e-6b911574f774,0x800,0x32000)/File(\EFI\UBUNTU\GRUBX64.EFI)..BO
Boot0006* opensuse HD(1,GPT,2fe6b58a-379a-4f6e-899b-8be22ef6e885,0x800,0x32800)/File(\EFI\OPENSUSE\GRUBX64.EFI)..BO
erlangen:~ #
You are quite right. I don’t know what happened. I looked after the kernel was installed and the symlinks were there pointing to the newly installed kernel, rebooted and they were gone. Maybe I lost my mind for a few, I do not know but, the symlinks are there just like they should be.
I just did a fresh install of TW yesterday afternoon. I learned not to use the G05 Nvidia driver. It would not work and that is what got me into a position where I had to re-install.
grep -e "menuentry " /boot/grub2/grub.cfg | sed 's/^ ]*//' | cut -d "{" -f1 | nl --starting-line-number=0
Or this:
grep -e "menuentry " -e "submenu" /boot/grub2/grub.cfg | sed 's/^ ]*//' | cut -d "{" -f1 | nl --starting-line-number=0
Also gives you a good list.
@mrmazda, what does the noresume do for your system? I’ve read up on it a bit but, just curious to hear your opinion and why you use that.
1-Systems/PCs, not system/PC, lots of PCs and no laptops or tablets
2-all PCs multiboot, as in lots of Gnu installations per PC; few have as few as 4; one has upwards of 40
3-one swap partition per PC almost without exception
4-default stanza selection is locked down in every Grub menu (nothing present in any Grub menu, or elsewhere, to suggest what was last booted)
5-almost without exception I’m interested in a fresh start when I boot or login, the reason for booting
6-grub menu files are smaller without a conventional resume=UUID= string
7-multiple users
8-I know of know way to declutter and shrink initrds by omitting unusable resume functionality
9-without a conventional resume=UUID= string, more of the kernel is on one line, or visible at all, when editing or otherwise perusing a grub menu or stanza
Can anyone think of any way I could benefit from not having noresume as a personal default?
Thanks for the explanation of why you use noresume. For me, I have one PC and prefer not to reboot every time I leave the room for 20 minutes or so.
I expect that whichever operating system I am currently booted into will wake up after a suspend (sleep).
Windows 10, Arch Linux and Xubuntu do not require any special grub resume command to wake from suspend. Fedora and openSUSE TW are the only ones that I know of.
I’m new and I need a little help/advice on one thing. Since I already have an UEFI/EFI boot partition for Windows 10, I don’t get it why Tumbleweed needs another one. The first time I just went with it and created two EFI partitions, but then Windows 10 crashed totally and couldn’t recognize the right GPT partition in which it’s EFI boot was held. I tried to convey all of it somehow to their right directories but it didn’t work out at all. It pretty much killed my Windows system and my laptop, and that’s why I had to reinstall everything. Now it again wants me to do the same and I don’t feel safe doing it since I don’t want to finish of the same. It is also important to point out that Tumbleweed and grub2 after that installation worked kind of strange compared to the last time I used it on my previous computer even though that wasn’t that long ago and the main features felt buggy. Any help?:(:(:(
It doesn’t.
However, the installer is wanting to insist that the EFI partition be at least 256M in size. So if you have a smaller EFI partition, then it wants to create another.
I have successfully installed with a smaller EFI partition. But it requires using the expert partitioner, and telling it to mount the existing EFI partition at “/boot/efi”. At the end of the partitioning part of the install, it then gives an error about there not being a large enough EFI partition. And you have to tell it to ignore the error and proceed with the install.
What are exact symptoms? When this corruption happens? When you simply boot Windows or when you perform some specific actions?
Originally openSUSE installer defaulted to separate ESP during installation. As side-topic of some discussion here it was found that this could lead to Windows installation corruption. I verified it with Windows 7. It happened trying to repair bootloader from within rescue system. Apparently Windows could not decide which of multiple ESP was the correct one, but at this point it already removed old content. I opened bug report which resulted in behavior change - installer now defaulted to reusing existing ESP. See 781689 – openSUSE should reuse existing EFI System Partition by default for details.
Note that corruption happened under rather specific conditions, Windows continued to boot normally otherwise. It is of course possible that similar problem may have happened during patch installation.
If you have evidences that multiple ESP may corrupt existing Windows installation, you should really open bug report. But you need to provide convincing arguments and actually explain how to trigger this corruption.
After the installation of Tumbleweed the corruption happens. You can run openSUSE on grub2 but windows 10 crashes and fails to boot. First it showed the crash screen and after the restart happened. When windows started again it said something like: “Your PC couldn’t start properly”, and an error code and other things like diagnostics, recovery, try again, etc. I tried to edit the entry, to somehow recover it or restore the system and nothing worked.
With the info provided it’s hard to understand just what happened when, and the current state of things. If you can boot TW, get the script from https://github.com/arvidjaar/bootinfoscript and run it in a vtty or Konsole or XTerm, then do
susepaste -n Medin25 -e 40320 RESULTS.TXT
so we can see what you have where and then suggest how to proceed. You may have to install susepaste first with zypper or yast. Also give us the exact model of your laptop so we can have an idea of its specifications. If you can install inxi with zypper or yast and provide output from
inxi -bGxx
run from Konsole or an XTerm it would be even better. Alternatively, output from inxi can be redirected to a file and uploaded with susepaste just like with RESULTS.TXT.
Maybe I wasn’t really clear enough so I’ll put it like this:
Problem 1:
- Installation process of Tumbleweed
- Adding another EFI boot partition (as required) to the system even though already one exists as default (probably for windows 10)
- After installation openSUSE worked but Windows kept crashing and I couldn’t get into it or boot it at all which I already mentioned
- Tried everything to fix it and thought that maybe Windows switched up some boot directories so that it couldn’t find it’s way to grub2. Maybe it has something to to with Legacy mode or UEFI, even though I tried all of it it kept failing.
- Had to reinstall openSUSE and Windows
- Installed Windows just fine but the system reserved of the previous one is still there so the crashed volume could still be accessed even though it can’t boot
- I’m in a state where I want to install again Tumbleweed but don’t know how to deal with the EFI boot partition which Linux requires and feel confused as a newbie for Linux systems and openSUSE
Problem 2:
My friend in the other hand installed it and it worked fine without needing an EFI boot partition, but he has problems with the software updates. It has to do something with the keybase that can’t let the system provide the right tools to download files that need to be provided for the repositories from like multimedia and packman. He can’t download basic things like vlc because it’s missing it’s codecs and files required for it to be installed.
He refreshed the repositories, tried everything from the forums and sites, enabled all repositories except for the Leap 15.1 one that for some reason makes the whole update part not work at all. Strangely enough it says that everything is up to date in the console from the repositories. Maybe he is looking for the wrong thing, or those things are not that connected, but he tried everything and nothing worked.
Thank you for the replies you gave me. Any other advice, help or solution to these problems?
If an EFI boot partition exists there is no need for a second unless it is extremely small it just need to be mounted at /boot/efi
You should NOT mix boot modes ie all OS must use EFI or MBR (legacy) booting never mix. This makes it impossible for grub to chain to the odd OS. You still should be able to boot to a EFI OS from the UEFI boot menu (BIOS) even if grub is in legacy mode
As to problem two show the repos ( we can’t look over your shoulder)
zypper lr -d
Also never mix repos from different OS versions ie only LEAP for Leap and only Tumbleweed for TW. Mixing will break things
Both problems belong in their own unique threads in which “everything” needs to be spelled out in detail. Neither is directly related to this thread’s OP, or to each other.
| Alias | Name | Enabled | GPG Check | Refresh | Priority
| Type | URI | Service
—±------------------------------------±----------------------------------------±--------±----------±--------±--------
-±-------±-------------------------------------------------------------------------------------±-------
1 | Google-Chrome | Google-Chrome | Yes | (r ) Yes | No | 99
| rpm-md | http://dl.google.com/linux/chrome/rpm/stable/x86_64 |
2 | Packman | Packman | Yes | (r ) Yes | Yes | 99
| rpm-md | http://packman.jacobs-university.de/suse/openSUSE_Leap_42.1/ |
3 | dvd | dvd | Yes | (r ) Yes | Yes | 99
| rpm-md | http://opensuse-guide.org/repo/openSUSE_Leap_15.0/ |
4 | http-download.opensuse.org-05f77fc4 | openSUSE.org:openSUSE:Leap:42.3:Update | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.opensuse.org/update/leap/42.3/oss/ |
5 | http-download.opensuse.org-1f422a49 | multimedia:apps | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.opensuse.org/repositories/multimedia:/apps/openSUSE_Leap_15.0/ |
6 | http-download.opensuse.org-5e9c6fb8 | multimedia:libs | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.opensuse.org/repositories/multimedia:/libs/openSUSE_Leap_15.0/ |
7 | http-download.videolan.org-4d928b83 | SuSE | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.videolan.org/SuSE/Leap_42.3/ |
8 | keybase | keybase | Yes | ( p) Yes | Yes | 99
| rpm-md | http://prerelease.keybase.io/rpm/x86_64 |
9 | openSUSE-Leap-15.0-1 | openSUSE-Leap-15.0-1 | No | ---- | ---- | 99
| rpm-md | hd:///?device=/dev/disk/by-id/usb-JetFlash_Transcend_16GB_795DSIPTUNZ93RWR-0:0-part2 |
10 | packman | packman | Yes | (r ) Yes | Yes | 99
| rpm-md | Index of /pub/linux/misc/packman/suse/openSUSE_Leap_42.1/ |
11 | repo-debug | openSUSE-Leap-15.0-Debug | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.opensuse.org/debug/distribution/leap/15.0/repo/oss/ |
12 | repo-debug-non-oss | openSUSE-Leap-15.0-Debug-Non-Oss | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.opensuse.org/debug/distribution/leap/15.0/repo/non-oss/ |
13 | repo-debug-update | openSUSE-Leap-15.0-Update-Debug | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.opensuse.org/debug/update/leap/15.0/oss/ |
14 | repo-debug-update-non-oss | openSUSE-Leap-15.0-Update-Debug-Non-Oss | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.opensuse.org/debug/update/leap/15.0/non-oss/ |
15 | repo-non-oss | openSUSE-Leap-15.0-Non-Oss | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.opensuse.org/distribution/leap/15.0/repo/non-oss/ |
16 | repo-oss | openSUSE-Leap-15.0-Oss | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.opensuse.org/distribution/leap/15.0/repo/oss/ |
17 | repo-source | openSUSE-Leap-15.0-Source | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.opensuse.org/source/distribution/leap/15.0/repo/oss/ |
18 | repo-source-non-oss | openSUSE-Leap-15.0-Source-Non-Oss | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.opensuse.org/source/distribution/leap/15.0/repo/non-oss/ |
19 | repo-update | openSUSE-Leap-15.0-Update | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.opensuse.org/update/leap/15.0/oss/ |
20 | repo-update-non-oss | openSUSE-Leap-15.0-Update-Non-Oss | Yes | (r ) Yes | Yes | 99
| rpm-md | http://download.opensuse.org/update/leap/15.0/non-oss/ |
That’s what I call a mess. You have a mix of repos from various openSUSE versions, a guarantee for the issues you’re seeing. My advice: a clean Leap 15 install.
When I this computer from my son, I formatted the 500GB SSD and installed Windows 10 first of course. Then I noticed it only create a /boot/efi partition that was only 128MB.
Knowing that I would be installing several other Linux systems on here, I knew I had to have at least a 512MB /boot/efi partition. I found how I could make it 550MB.
I’ve ran out of room before and found that deleting the dump files cured that problem.
Sorry, I’m a little late to this ballgame but, if you are willing to start from scratch, which it appears you need to do. Back up everything you want to save and start over by re-installing windows 10 first.
Definitely watch this video about how to make the /boot/efi system partition as big as you want before you do.
The video creates a 260MB EFI partition, which every system on your computer will use (Windows 10, Arch Linux, openSUSE and/or all the other systems you want or will ever want to install).
You will want to make this at least 512MB or bigger. I made mine 550MB. You can see the 5 systems I have installed in my signature. You could make this 2GB and that would be fine if you have the room.
This is probably the most important step there is during an initial install to a new or newly formatted partition. How to Resize EFI System Partition [Hackintosh]
Doing this is easy for the guy in the video but, myself I never would have figured this out in a million years.
BTW, I had to boot into Windows to retrieve that link.
Then every time you install a Linux system .e.g. openSUSE Leap, just point it to the /boot/efi partition but, do not format it. Do the same with the swap partition.
I re-installed Fedora 29 a couple of days ago and in order to get the /boot/efi and swap partition to be included I had to put a check by format this partition but, once it added it, I removed the check mark.
I forget how it was when I installed openSUSE TW but, the idea is the same. You definitely do not ever want to format the /boot/efi partition and if you have more than one Linux system installed, you do not want to format the swap partition either.
I haven’t installed Windows first in nearly two decades, and that was probably a Windows-only installation. While it’s perfectly reasonable to install Windows first, with proper understanding and planning, there’s absolutely no compulsion to adhere to this too popular fairy tale of need. Strictly adhering to such logic, all operating systems would need reinstallation following each Windows reinstallation.
Definitely watch this video about how to make the /boot/efi system partition as big as you want before you do.
The video creates a 260MB EFI partition, which every system on your computer will use (Windows 10, Arch Linux, openSUSE and/or all the other systems you want or will ever want to install).
260M is perfectly reasonable, probably the ideal recommendation for size on a virgin or freshly wiped disk.
You will want to make this at least 512MB or bigger.
Utter nonsense…
I made mine 550MB. You can see the 5 systems I have installed in my signature.
I have two UEFI systems with 6 or more installed operating systems. One has 6, with ESP partition using a mere 19M, which would be only 19% of a 100M partition. The other has 9, using 22M on ESP, which is probably about twice as much as needed due to in place backups/archives.
There do exist circumstances that dictate a minimum ESP partition size of 260M. That is in the AFAIK as yet unsupported configuration of ESP partition living on a device with 4k logical sector size as well as physical sector size. Anyone else would be very hard pressed to install, much less maintain, enough operating systems to exhaust a 100M ESP partition’s freespace.
Those installers that claim that 100M or 128M is inadequate for ESP are quite simply broken.
Windows partition requirements:
-
System partition
The device must contain a system partition. On GPT drives, this is known as the EFI System Partition, or the ESP. This partition is usually stored on the primary hard drive. The device boots to this partition.
The minimum size of this partition is 100 MB, and must be formatted using the FAT32 file format.
This partition is managed by the operating system, and should not contain any other files, including Windows RE tools.
Note For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 = 256 MB.
Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 = 32 MB, which is less than the 100 MB minimum size for this partition.