USB EFI Boot/Install

[linuxcat]

Good day,
I have had no luck installing open mamba.
I have tried multiple ISO’s and different usb sticks, but to no avail.
I have noticed that the ISO’s aren’t creating a grubx64.efi option, only bootx64.efi, and as such my computer won’t recognize the usb stick…(yes, I have efi set in my bios).
So…I have to use rEFInd and it recognizes the bootx64.efi and boots to the grub menu.
I have tried every boot mode, but none of them will boot.
The closest one is the debug choice and it attempts to boot…I see the openmamba logo briefly and it drops to a prompt and stops booting, usually the last line says, “Failed to start SDDM”.
I can switch to another terminal and run, dnf update…it finds and installs 104 updates, including sddm.
If I try to run startx from the prompt, it attempts to load, but states that X refuses to run or fails to connect.
Enclosed is my report.
Any ideas?

Attachments:

You must be logged in to view attached files.

[Silvan]

Hi,
thanks for reporting the issue with much detail.

I will check for adding a UEFI boot option to the live ISOs in the next days. Currently you may create a UEFI bootable pendrive by using the “Install openmamba on USB” tool but of course you need to have a working openmamba desktop installation to be able to run this tool.

As for the SDDM startup error, recently this issue was caused by a missing /lib/systemd symlink pointing to /usr/lib/systemd, you may want to check if the link is missing and if so creating the symlink should fix the problem. I thought the problem would be fixed with the latest ISOs but I will check and eventually do a fix for this problem.

[linuxcat]

Silvan,
Thank you for quick response…
When the usb stick I created booted and I switched to tty2, I could start mc and see that in fact the sym link was created for systemd that you mentioned. I updated using dnf but couldn’t get the desktop to start using startx.

Just to confirm, so that you are aware…I am seeing these issues when booting the usb stick I created. It never does boot to a desktop.
I created my boot stick using dd…I may also try Belana-etcher to see if that makes a difference.

I even downloaded the openmambo image and using gnome-disks, restored the openmamba image to a second drive. Interestingly enough, it created 3 partitions.
Partition #1 19mb hfs+ (EFI_MAC), Partition #2 20mb Fat (EFI), Partition #3 3.7gb Ext4 (openmamba)
Both partition #1 & #2 have the same folders and files; EFI/Boot/bootx64.efi
Partition #3 has a boot folder (grub/initrd.gz/vmlinuz) and a LiveOS folder with the squashfs.img
But my system, (and rEFInd) can’t find either bootx64.efi or grub in either partition #1 or #2
I hope that I haven’t overloaded you with too much info.
Any pointers will be greatly appreciated.

Douglas

[Silvan]

Hi Douglas,
by looking at the report you sent it seems that Xorg is unable to start because the kernel is started with the “nomodeset” option, so it would skip AMD/ATI drivers and try VESA/Framebuffer modes which fail too probably because VESA/Framebuffer modes are not available too. So for this part of the problem I would suggest to boot without the “nomodeset” option, then if you are able to access a console a report in this situation would be more interesting to see. If you can’t get to a console the boot could be blocking with some relevant message on screen instead (assuming that you are not booting with the bootsplash enabled, so without the ‘quiet splash’ kernel command line arguments.

Using the diskimg is a good idea to perform a EFI boot. The bootx64.efi from grub 2.04 has been the same for a long time and it works where I have tested it, BTW I’m working on Grub 2.06 update. The boot file has just to be inside a FAT partition and the PC has to be configured to support boot from the external device (i.e. things like secure boot need to be disabled). BTW I recently had a similar problem on a x86_64 tablet where bootx64.efi is no longer detected so I will be able to further investigate on this problem.

• This reply was modified 2 years, 7 months ago by Silvan.

[linuxcat]

Silvan,
Thank you for your insight…I will check a few more things in regards to booting the usb and also the image boot.

Douglas

[linuxcat]

Silvan,
So…I was finally successful in installing OpenMamba, here’s how it went.
To start, I used dd to write the openmamba image file to an 8gb usb.
The main thing, (and I should have realized this since there was no grubx64.efi in the install files), I had to go into the BIOS settings on my computer and enable CSM mode.
Upon booting to the usb, it came up with the grub menu and I selected the “default” load line.
I did not have to use the nomodeset switch.
After installation to /dev/sdc, (I have 3 drives with sdc being an extSATA), upon initial boot, I was getting an rpm database error.
So…I rebuilt the rpm database and was able to complete the initial update.

The next thing I want to attempt is adding UEFI boot to OpenMamba.
This gentleman, Roderick Smith, writes great articles on the whole UEFI boot process…I’ve used his advice for many years. (https://www.rodsbooks.com/linux-uefi/).

Douglas

[Silvan]

Hi Douglas,
I’m glad that you could boot openmamba ISO and install it in CSM mode.

You could now try to create a USB pendrive from a ISO using the provided openmamba tool you find in the start menu by typing USB, then ideally boot in EFI mode from this pendrive and install (the calamares installer supports EFI boot).

My doubt is if it is possible (and whether other distribution do) to distribute a ISO image which you can write with dd into a pendrive and which can be booted in UEFI, but I don’t think so.

For this reason there is the openmamba diskimg download, an image that you already tried which contains the EFI ESP partition and should boot. But I think that in EFI boot mode there might be, as previously noticed, KMS video driver problems that should be investigated further…

[linuxcat]

Silvan,
Well…I had luck with the install, but after rebooting, whenever I attempt to update, either through command line with dnf or through the openmamba updater, the computer hard locks.
The only option is to hold the power button to get it to turn off.
And upon rebooting, it kernel panics.
Like you mentioned, there must be an issue with kms and the kernel on my machine.
I attempted to compile a newer kernel, but downloading a newer kernel and upon running make menuconfig, it just fails as I think the openmamba file system must be different.

Douglas

[Silvan]

Hi Douglas,
this means that the glibc-2.34-4mamba upgrade, which would make /lib[64] a symlink to /usr/lib[64], was a failure. The linux loader /lib64/ld-linux-x86-64.so.2 would disappear and no executable can be run, it is not a problem with the kernel, which will panic because it won’t be able to run /sbin/init after switching to the rootfs.

The fix is to either start from the most recent ISO livecd image or do a manual recovery by booting a live system and perform a series of terminal command such as:

wget https://cdn.openmamba.org/pub/openmamba/devel/RPMS.x86_64/glibc-2.34-4mamba.x86_64.rpm
sudo su
mkdir /mnt/sda1
mount /dev/sda1 /mnt/sda1
mount -o bind /dev /mnt/sda1/dev
mount -o bind /proc /mnt/sda1/proc
mount -o bind /sys /mnt/sda1/sys
rpm -r /mnt/sda1 -u glibc-2.34-4mamba.x86_64.rpm
chroot /mnt/sda1
dnf update

This would fix the main issue although repairing of any of the packages which were part of the upgrade may be needed as well.

• This reply was modified 2 years, 7 months ago by Silvan.
• This reply was modified 2 years, 7 months ago by Silvan.

[linuxcat]

Silvan,

Good day…
So, not much luck with running the update that you suggested.
First, the wget command to download glibc failed with a “certificate not trusted error” and a, “doesn’t have a known user error”. So I followed the link and manually downloaded the glibc file.
Also to clarify, you instructed to mount sda1…that is the efi fat32 partition, didn’t you mean sda2 to mount and chroot into the rootfs?
I ran the commands mounting /dev/sda2 to /mnt/sda2 the rootfs file system.
But upon running the rpm command to upgrade glibc, I received a failed dependency error.
I chrooted into the sda2 rootfs and ran the wget command again to get the glibc update, and it also failed due to certificate not rusted error.

Something additional I tried…since I was successful at installing, I attempted to update only the glibc initially, and then thinking of rebooting and complete a full update…but alas, after a successful glibc update, the computer would only boot to black screen.
So…I can install successfully and run openmamba, I just can’t update the system.

Douglas

[Silvan]

Hi Douglas,
The instructions given are quick guidelines needing interpretation, as you did.

For the download URL, my mistake, the URL needs to start http instead of https.

Ok that you identified as /dev/sda2 and mounted the rootfs partition.

Next, the glibc recovery procedure (using rpm -r .. where -r is the option to specify the target rootfs path) was needed because I’ve assumed that during the upgrade in the previous post glibc broke and so all the system broke. This indeed is contradictory with the fact that you have been able to chroot to that rootfs with success and without fixing glibc before.

There are currently two different problems I would put the attention on:

1) glibc upgrade with migration from /lib64 to /usr/lib64 causes severe problems if it fails (i.e. the system is unbootable, and the kernel panics altough it’s not kernel’s fault);

2) sddm, the KDE Plasma login manager, fails to start the graphical desktop. This is the situation where the system enters graphical mode, you have the mouse pointer available on screen, but you get no more than a black screen. You can btw switch to a console by pressing CTRL-ALT-F2.

My previous post was about fixing the issue 1), it explains the guidelines for a “almost disaster” recovery procedure and is intended to be performed by a quite expert and conscious user. I’m not sure any longer that this applies to your last situation reported.

For the issue 2) I haven’t found a certain solution yet. There is a sddm upgrade which I’m testing and suggest to try to apply first (please note that I mean sddm, not sddm-kcm), while a workaround seems to be removing the file .Xauthority for user home and restart sddm:

rm -f ~/.Xauthority
systemctl restart sddm

By using the most recent livecd ISO the glibc upgrade problem is bypassed, but the sddm issue remains to fix.

[linuxcat]

Silvan,
Thank you for your continued attention and patience, I will try and implement your suggestions today.

Douglas

[linuxcat]

Silvan,
Good day…So I was able to boot normally from my initial install and I ran update, (sudo dnf update), from command line and it completed and installed appropriately.
Upon reboot though, and I had to add nomodeset to the linux loader line, the boot up process would not complete. I would never see the black desktop and mouse pointer, like you mentioned.
Thinking the issue was with SDDM like you mentioned, I switched to tty2 and ran, “systemctl stop SDDM” and then, “systemctl disable SDDM”.
Upon reboot, the boot process completed by going to a login prompt. So it seemed SDDM was failing and stopping the boot process.
I tried running startx from command line and just received the following:
“[KMS} drm report modesetting isn’t supported”
“xinit: unable to connect to X server: Connection refused”.

I assume the modesetting error is from my adding nomodeset to the kernel load line.
Is it possible to use lightdm instead of SDDM?

Douglas

[Silvan]

Hi Douglas,
you say you could install the system and it was working until you did a system upgrade and reboot. So what ISO release did you install from, in order for me to limit which are the updates that caused the problem?

The nomodeset is an argument that is only used to support non-KMS drivers, like NVIDIA proprietary drivers (well, to be correct this is also not true anymore with recent drivers). In this case you use it as a workaround to get to a console but the system is not expected to start correctly in graphical mode with this option (it should with fb or vesa drivers but maybe not on UEFI btw we are not interested in starting the system with this option). So if the kernel fails to boot in default mode it should be started without the quiet splash arguments (and maybe also adding debug but this may cause excessive flooding of messages) and what appears on screen when it stops (a screenshot?) could be useful for debugging.

As for the startx command, as I told there is not interest in booting with nomodeset because the desktop is not expected to work correctly at all with standard video drivers.

Of course you can try to install other login managers but openmamba is designed to work (and did for years) with SDDM like any other KDE Plasma based distribution. BTW there is no lightdm package in openmamba, there is lxdm (which is used by openmamba-light flavour with LXQt).

As yours and other reports suggest I will try to package a kernel update, although I have three systems correctly running with this kernel (with Intel and AMD gpus) so I think the problem is elsewhere.

[linuxcat]

Silvan,

I used the openmamba-diskimg-livecd-en-snapshot-20210630.x86_64.img
And I used gnome-disks to restore the image to an 8gb usb stick. It would then boot up efi.
As the attachment shows, boot stops with the line at the bottom, when I removed quiet and splash from the linux load line.
If I remove quiet and add nomodeset, then it boots to a prompt.
(If you remember, I disabled SDDM with the systemctl disable SDDM command).
I have configured and compiled new kernels on other distros…is that an option with openmamba, or is it hardcoded by you?

Douglas

Attachments:

You must be logged in to view attached files.

[Silvan]

Hi Douglas,
as you installed starting from a june snapshot you should still have the previous kernel installed (5.10.56) and available in the Grub advanced options submenu. Did you try that? According to other reports problems seems to happen since 5.10.57 update and this would explain why your system worked before updating.

The kernel is built from the kernel source rpm that you can find in the sources folder.

• This reply was modified 2 years, 7 months ago by Silvan.
• This reply was modified 2 years, 7 months ago by Silvan.

[Silvan]

Hi Douglas,
I’ve packaged a new kernel update which is under testing, if you want to test it against the problems you are having in your installation you may install it with the following command:

sudo dnf update kernel-mamba-x86_64 kernel-mamba-x86_64-headers --enablerepo=unstable-makedist

[linuxcat]

Silvan,

Just to inform you of other things I have done…
My boot stick works just fine and I can complete an install. Upon reboot, I can log in, but just get the spinning wheel.
So I switched to tty2 and ran systemctl stop sddm and then systemctl disable SDDM.
I then, (without rebooting), installed lxdm and ran systemctl start lxdm. The lxdm login came right up and I could log in normally, without rebooting.
I then ran a selective update, I deselected sddm and sddm-kcm and the newer 5-10.47 kernel. Update completed, but upon reboot, (with quiet turned off), the boot process would just stop and never go to login.

So…I’ll try your suggestion above for the new kernel and let you know how it goes.

Douglas

[Silvan]

Hi Douglas,
thanks for reporting your attemps with openmamba.

Here are the news from my side: after deep research I identified the cause of Plasma Desktop not starting in the file /etc/xdg/kwinrc which would cause the window manager process kwin_x11 to run at 100% CPU and block the desktop startup. This only happens the first time a user logs in, because thereafter the file kwinrc is read from the local home directory. So the fix for this is in the desktop-base-kde update to version 5.0.

Other problems you may have after updating depend on the fact that you are starting from a three-months old live image and here the glibc update to the /usr flat filesystem is probably the cause of further problems, so I would suggest you to try the openmamba-diskimg-livecd (with EFI boot support) or openmamba-livecd that have been made available between yesterday and today with the more recent kernel and everything fixed from my point of view.

[linuxcat]

Silvan,

I’m keeping my finger crossed, but I think I may finally have a working system, thanks to your hard work.
So…I created a new boot stick with the openmamba-diskimage-livecd-en-snapshot-20210912 image and completed the install and update.
It looks like it is running good; I will try things out and let you know.
Thanks again.

Douglas

[Silvan]

Hi Douglas,
I’m glad that you could finally have a working installation starting from the new downloadable image.
I can’t fully check the installation procedure every time new images are released and I did not receive any report before you so this was a problem that lasted for months and now I’m happy that it is resolved.
So thank you for your detailed reports and your patience.

[linuxcat]

Silvan,
I was happy that I could help out, if there is anything I can assist you with in the future, don’t hesitate to let me know.

Douglas

[Author]

Posts