:\ Would you like to reconsider information from previous clarification requests?
Examples:
I added a connection for the desired EFI system partition to this directory (in the meantime) as another configuration detail in the file “etc/fstab”.
Are there any cases to consider where other mount points would be more pleasing?
I have occasionally seen a similar message to the one you saw
Thanks for such feedback.
– but it was because I had not mounted “/boot/efi”.
:\ Can any software tools trigger undesirable unmounts (too quickly)?
At one time, “systemd” was unmounting some file system (a bug). I think this only happened if you were using “btrfs” for the root file system. I think that bug has been fixed.
As far as I know, openSUSE always wants the EFI partition mounted at “/boot/efi” and not anywhere else. It doesn’t have to be mounted via “fstab”. Manually mounting it when needed is sufficient. But it might be needed in a regular update, so best to keep it always mounted.
I am using this procedure successfully for years with any distribution and secure boot being turned off. It even succeeds cross distribution. When Pop! OS failed to install grub booting into Tumbleweed and running the procedure fixed the issue. I ran it on the current system, which uses btrfs mirroring from another partition.
Don’t use secure boot unless you definitely want to have it. During installation use expert partitioner and tell what you want to have: https://doc.opensuse.org/documentation/leap/startup/html/book-opensuse-startup/cha-install.html#sec-yast-install-partitioning Performed dozens of installs and expert partitioner always readily performed the operations specified.
I hope so, too. - I became curious about further software failure possibilities.
As far as I know, openSUSE always wants the EFI partition mounted at “/boot/efi” and not anywhere else. It doesn’t have to be mounted via “fstab”. Manually mounting it when needed is sufficient. But it might be needed in a regular update, so best to keep it always mounted.
Thanks for such a feedback.
:\ I hope also that the remaining configuration challenges can be resolved for the current software installation system.
You seem to be using the NET installer. You can probably get a terminal session during install with CTRL-ALT-F2 but I’m not sure if that will do what you want.
Maybe use the live iso. That gives you a KDE or Gnome desktop. It actually uses the same NET installer. But you are in a session where you can open a terminal (“konsole” or “gnome-terminal”) and perhaps watch part of what is going on.
Thanks for such information.
Would it become helpful to improve descriptions for these software sources anyhow?
Thus I am trying the “system upgrade” according to the software combination “openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20210210-Media.iso” out once more at the moment.
The currently proposed software installation settings look promising.
… and perhaps watch part of what is going on.
But I find information like the following suspicious. (It might eventually be reasonable at this point.)
**unknownb42e9932cf79:~ #** cat /etc/mtab
[FONT=monospace][FONT=monospace]…
/dev/mapper/nun-root /mnt ext4 rw,relatime 0 0
[/FONT]…
[/FONT]/dev/nvme0n1p4 /mnt/boot ext3 rw,relatime,data=ordered 0 0
I hope that these partitions will be mounted as the directories “/” (root) and “/boot” finally.
Unfortunately, I stumble on the following German wording again.
Fehler beim Ausführen des Befehls ""/usr/sbin/grub2-install", "--target=x86_64-efi", "--force", "--skip-fs-probe"]]".
Abbruch-Code: 1
Fehlerausgabe: x86_64-efi wird für Ihre Plattform installiert.
/usr/sbin/grub2-install: Fehler: EFI-Verzeichnis kann nicht gefunden werden.
:\
If that is during install, then that is normal. The installer mounts the future root file system at “/mnt” and mounts other needed file systems relative to that. After install, when you reboot they will be mounted at the proper place.
However, that output does not show the EFI partition as mounted. If you use the expert partitioner, you need to specify there that the EFI partition is to be mounted at “/boot/efi”.
Fehler beim Ausführen des Befehls ""/usr/sbin/grub2-install", "--target=x86_64-efi", "--force", "--skip-fs-probe"]]". Abbruch-Code: 1 Fehlerausgabe: x86_64-efi wird für Ihre Plattform installiert. /usr/sbin/grub2-install: Fehler: EFI-Verzeichnis kann nicht gefunden werden.
My German is a bit rusty, but I think it is complaining that the EFI partition is not mounted.
Should the activation of the boot manager components be performed manually anyhow after it seems that the installation succeeded for the other software packages?
I’m not sure what you are asking. The normal install first installs the packages. Then it does “chroot /mnt” to install the bootloader.
If you want to boot to rescue mode to do that again, yes you can do that.
In rescue mode, login as root. Run cryptsetup to handle the crypto. Then mount your root file system at “/mnt”
Then:
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt
mount -A ### mount anything else needed from "/etc/fstab"
mount /dev/XXXX /boot/efi ### manually mount the EFI partition, since you did not set that up correctly.
shim-install ### this should setup booting.
exit ### leave chroot mode
shutdown -r now
The strings starting “###” are just my comments. You do not need to enter those. And change that “/dev/XXXX” to whatever is the device name for your EFI partition.
I can extend the previous file system excerpt if such a detail would be needed.
I imagine that the subsequent directory structures should be prepared then under “/mnt/boot/efi”, shouldn’t they?
If you use the expert partitioner, you need to specify there that the EFI partition is to be mounted at “/boot/efi”.
…, but I think it is complaining that the EFI partition is not mounted.
I wonder still why the EFI directory (and related dependencies) would not be found by the boot manager installation system so far.
Then it does “chroot /mnt” to install the bootloader.
:\ This process should work as usual.
If you want to boot to rescue mode to do that again, yes you can do that.
Do you distinguish from the rescue installation system here?
Yes.
The desired specifications should be available in the file “/etc/fstab” (of the final output storage device).
Right. But is the entry there? It is your computer, so you should be able to check.
:\ Does anything hinder the boot manager installation system to take the following specifications into account as expected?
[manjaro@manjaro ~]$ sudo mkdir /mnt/R && sudo mount /dev/mapper/nun-root /mnt/R && sudo cat /mnt/R/etc/fstab
…
/dev/nun/root / ext4 defaults 1 1
…
/dev/nun/home /home ext4 data=ordered 1 2
…
/dev/nvme0n1p4 /boot ext3 data=ordered,comment=systemd.automount 1 2
/dev/nvme0n1p1 /boot/efi fat32 comment=Test_this 1 2
[manjaro@manjaro ~]$ sudo mkdir /mnt/B && sudo mount /dev/nvme0n1p4 /mnt/B && ls -l -d /mnt/B/efi
drwxr-xr-x 2 root root 4096 5. Feb 10:39 /mnt/B/efi
From that, it does look as if “/etc/fstab” does have the needed entry.
From that manjaro system, can you try:
sudo mkdir /mnt/R && sudo mount /dev/mapper/nun-root /mnt/R
sudo mount --bind /dev /mnt/R/dev
sudo mount --bind /proc /mnt/R/proc
sudo mount --bind /sys /mnt/R/sys
sudo chroot /mnt/R
##### this is in the chroot session, where you should be root already
mount -a
ls /boot/efi
shim-install
#### back out of the chroot session.
Did that work or did it give errors?
I can try a few Linux live systems (like Knoppix 8.6.1) out for the desired repair of boot manager configurations (besides additional software updates).
Did that work or did it give errors?
How do you think about command variants like the following?
root@Microknoppix:/home/knoppix# vgchange -a y && XY=/mnt && LVM=/dev/mapper/nun- && mount ${LVM}root $XY && for MP in usr var; do mount ${LVM}$MP $XY/$MP; done && for MP in dev proc sys; do mkdir -p $XY/$MP && mount --bind /$MP $XY/$MP; done && mount /dev/nvme0n1p4 $XY/boot && mount /dev/nvme0n1p1 $XY/boot/efi && echo 'mounts succeeded' && chroot $XY
5 logical volume(s) in volume group "nun" now active
mounts succeeded
Microknoppix:/ # ls -l -d /boot/efi && /usr/sbin/shim-install
drwxr-xr-x 3 root root 4096 Jan 1 1970 /boot/efi
copying /usr/share/efi/x86_64/grub.efi to /boot/efi/EFI/opensuse/grub.efi
Installing for x86_64-efi platform.
Installation finished. No error reported.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
Would you like to share further thoughts for the presentation of nice boot menus (for UEFI systems)?
That only works if you have booted the system with UEFI. If you use legacy booting, then you will get that “EFI variables are not supported” (or similar message).
I observed that Linux Live systems need to be distinguished also by their level of support for UEFI systems.
If you use legacy booting, then you will get that “EFI variables are not supported” (or similar message).
Can the software combination “Knoppix 8.6.1” (for example) work only according to the “legacy” mode (as expected) so far?
:\ Will any further repairs become relevant for the installed openSUSE instance (and the currently running environment “openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20210215-Media.iso”)?
I can check the software situation again (for example) also by the means of the environment “openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20210215-Media.iso” at the point when the system (or partition) like “/dev/nun/root” should be selected for another update.
**unknownb42e9932cf79:~ #** mkdir /mnt/R && mount /dev/mapper/nun-root /mnt/R && cat /mnt/R/etc/fstab
…
/dev/nun/root / ext4 defaults 1 1
…
/dev/nun/home /home ext4 data=ordered 1 2
…
/dev/nvme0n1p4 /boot ext3 data=ordered,comment=systemd.automount 1 2
/dev/nvme0n1p1 /boot/efi fat32 comment=Test_this 1 2
**unknownb42e9932cf79:~ #** cat /etc/mtab|egrep 'efi|mnt'
**efi**varfs /sys/firmware/**efi**/**efi**vars **efi**varfs rw,nosuid,nodev,noexec,relatime 0 0
/dev/mapper/nun-root /**mnt**/R ext4 rw,relatime 0 0
:\ Can this file system layout preparation be fixed for the desired boot manager setup and related software components anyhow?
I have never tried Knoppix, so I don’t know whether it has UEFI support.
Efibootmgr is not present on Knoppix 8.6.1 or 8.2.1, but it can be used if network works:
# ls -ld /KNOPPIX
drwxr-xr-x 22 root root 4096 Mar 18 2018 /KNOPPIX
drwxr-xr-x 5 root root 2048 Aug 7 2019 /KNOPPIX1
drwxr-xr-x 4 root root 2048 May 15 2018 /KNOPPIX2
# inxi -SIay
System:
Host: Microknoppix Kernel: 5.2.5-64 x86_64 bits: 32 compiler: gcc v: 10.2.1...
Console: N/A DM: KDM Distro: Debian GNU/Linux 10 (buster)
Info:...Shell: Bash v: 5.0.3 **inxi: 3.3.01**
# apt update
...
# apt install efibootmgr
...
# efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0000,0001,0002,0003
Boot0000* opensusetw HD(1,GPT,5b331d7f-9488-4df5-9eed-c7250696b833,0x800,0xa0000)/File(\EFI\OPENSUSETW\GRUBX64.EFI)
Boot0001* UEFI OS HD(1,GPT,5b331d7f-9488-4df5-9eed-c7250696b833,0x800,0xa0000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0002* UEFI: VerbatimSTORE N GO 5.00 PciRoot(0x0)/Pci(0x14,0x0)/USB(3,0)/CDROM(1,0x89d000,0x1e000)..BO
Boot0003* UEFI: VerbatimSTORE N GO 5.00, Partition 1 PciRoot(0x0)/Pci(0x14,0x0)/USB(3,0)/HD(1,MBR,0x12c649b0,0x89d000,0x7800)..BO
The following command can eventually be performed at this point (if the application “Terminal - Super User Mode” can actually be kept open).
**unknown…:~ #** mount [FONT=monospace]/dev/nvme0n1p1 /boot/efi[/FONT]