Hi,
I tried to switch from AppArmor to Selinux using this tutorial.
As I don’t use Grub 2, I used Yast Bootloader to add the required kernel parameters mentioned in the tutorial and then rebooted.
My system then would hang during boot, mentioning “A start job is running for /dev/gpt-auto-root” followed by “initrd dependency failed” and I had to rollback.
I tried editing manually /etc/kernel/cmdline as well. Same result.
I tried on 2 other PC with other kernel parameters (quiet splash) and everytime it would not boot.
mitigations=auto works, though.
Editing manually the snapshot entry in the systemd-boot menu works as well.
Am I doing something wrong or is this a bug ?
Thanks for your insight.
You did not show any evidence that you could not change kernel parameters. Do whatever you did with YaST Bootloader, then check the actual systemd-boot configuration file. Are changes present?
How should I show evidence of this ?
By «actual systemd-boot configuration file», do you mean the entries in /boot/efi/loader/entries ?
If so, the parameters I add are present in the latest snapshot *.conf file (and in /etc/kernel/cmdline) but it just won’t boot correctly when I reboot.
However, if I add the same parameters manually by editing the entry with ‘e’ in the Systemd-boot menu (without touching Yast Bootloader or editing manually /etc/kernel/cmdline), it will boot.
I’ve compared entries that boot to the ones created after editing the kernel parameters (using Yast Bootloader or editing /etc/kernel/cmdline) that won’t.
It appears that the newly created entries are missing the root=UUID= part. Adding it from another entry allows those specific snapshots to boot.
However I guess I shouldn’t have to do that manually.
Workaround: add the root=UUID= to Yast Bootloader or /etc/kernel/cmdline.
Subsequently created snapshots boot correctly afterwards.
So, the title of your topic is completely misleading.
What does it mean? You have some entries with this parameter and some entries without this parameter? We are not staying behind your shoulder, we cannot read your mind, we do not have crystal ball - we just rely on what you say or show. And we always prefer that you show the actual data, not describe what you saw.
Anyway - the only VM with systemd-boot I have is microOS and I just performed transaction-update dup and checked that “newly created entry” has the root=UUID=xxx parameter. So, you need to give more details about what you did, step by step, so that someone could reproduce it.
Well, not that misleading. Adding kernel parameters to make them permanent would make my system unbootable.
It means the entries created after adding kernel parameters to Yast Bootloader or /etc/kernel/cmdline.
By the way I’ ve been told the default kernel parameters are quiet splash and yet my 3 computers on TW and systemd-boot were without it. CPU mitigations were on manually in Yast Bootloader as well, despite setting them on enabled/auto during install.
We are not staying behind your shoulder, we cannot read your mind, we do not have crystal ball
Sorry for the previous message. Inadvertently sent it and took too much time to edit it afterwards so I couldn’t send the modified version.
Well, not that misleading. Adding kernel parameters to make them permanent would make my system unbootable.
It means the entries created after adding kernel parameters to Yast Bootloader or /etc/kernel/cmdline.
We are not staying behind your shoulder, we cannot read your mind, we do not have crystal ball
I’m looking for help, not interested in being trolled, thanks.
we just rely on what you say or show. And we always prefer that you show the actual data, not describe what you saw.
I asked you earlier how I’m supposed to show you evidence. You didn’t answer. I don’t know how to show logs from the kernel boot messages after a failed boot. Was I supposed to take a picture with my phone ?
So, you need to give more details about what you did, step by step, so that someone could reproduce it.
PC1:
Wanted to try Selinux instead of Apparmor.
Opened Yast Bootloader. The kernel parameters line is empty.
Added security=selinux selinux=1 to the kernel parameters as required by the tutorial. Reboot in order to make the changes effective.
Stuck on boot. Boot message: start a job for /dev/gpt-auto-root followed by initrd dependency failed.
Rollback to an earlier snapshot. Boots.
PC2:
Decide to check if it works with other kernel parameters. Find about the /etc/kernel/cmdline file that is missing as well on this computer. Yast Bootloader’s kernel parameters line is empty, too.
Added quiet splash and set mitigations on Auto. Reboot.
Stuck on boot with the same message as PC1.
Rollback to an earlier snapshot.
Reboot, try to edit a working snapshot with ‘e’ in the systemd-boot menu. Add quiet splash in the entry line. It booted as it should (no more lengthy boot messages and vendor logo)
Opened Yast Bootloader, set the mitigations on auto. Rebooted. It booted. /etc/kernel/cmdline was populated with mitigations=auto.
Tried once more with quiet splash in Yast Bootloader. Failed on next reboot as well with the usual message.
Checked the boot entries created in /boot/efi/loader/entries. Entries created after the changes in Yast Bootloader contained the added kernel parameters (quiet splash) but lacked the root=UUID= part. Adding that part using the one from a working snapshot made the ‘faulty’ snapshot bootable again.
Added the root=UUID= part to the kernel parameters line in Yast Bootloader. Subsequently created snapshots boot with the right kernel parameters.
PC3:
Same story. Missing /etc/kernel/cmdline. Adding kernel parameters to Yast Bootloader creates unbootable snapshots with the same boot error.
I’ ve been told the default kernel parameters are quiet splash and yet my 3 computers on TW and systemd-boot were without it. CPU mitigations were on manually in Yast Bootloader as well, despite setting them on enabled/auto during install. I never had troubles changing those parameters with Grub 2.
You could already stop here. Your problem has nothing to do with “changing kernel parameters”. We have no way to guess why it became empty nor do we have any evidence that /etc/kernel/cmdline was not empty before.
OK, out of curiosity I cloned my UEFI VM with grub2 and tried to switch to systemd-boot using YaST.
YaST did not migrate grub2 kernel parameters, it offered completely new command line. The root=... was not there. YaST offered to install some packages (first and foremost systemd-boot 
) which worked.
The first attempt failed due to missing /etc/kernel (so it was unable to create /etc/kernel/cmdline). This directory is owned by sdbootutil-kernel-install package that was not installed.
After installing the missing package and trying to switch again the second attempt failed when creating kernel entries due to missing /boot/efi/loader/entries directory. This directory is created by sdbootutil install, but YaST only invokes it during initial install.
After running sdboot install it looked like systemd-boot was installed. Yes, /etc/kernel/cmdline did not have root=... parameter. It is only added by YaST during initial install either.
Still, after reboot grub2 was invoked. It turned out, sdbootutil prefers grub2 if both are present, and nothing removed grub2 packages when switching to systemd-boot. Removed grub2 EFI binary, re-run sdbootutil install, rebooted - still grub2. Because sdbootutil will not replace the existing boot entry, even though it has changed.
Removed existing boot entry, re-run sdbootutil install and finally was greeted with systemd-boot menu. And yes, it failed at the auto-gpt step just as in your case. You do not really need root=... parameter, you simply need to disable auto-gpt. E.g. by using systemd.gpt_auto=0.
And I am pretty sure the next problem will be during kernel update because sdbootutil-rpm-scriptlets was not installed either (OK, there should be improvements here, may be it is no more needed).
To summarize. The only way it can work is during initial installation. Any deviation from developer expectations result in some problem. So, if you believe you found a bug, you need to
-
demonstrate that after clean installation selecting
systemd-bootas bootloader you haveroot=...in/etc/kernel/cmdline(you should) -
demonstrate that after you invoked YaST it showed you the empty kernel command line which did not match the content of
/etc/kernel/cmdline. I cannot reproduce it. YaST Bootloader shows the actual content of/etc/kernel/cmdline.
Otherwise it is simply not actionable.
Thanks for your lengthy investigation.
I will try to use systemd.gpt_auto=0 instead.
PC 1 and 2 were clean reinstalled with system-d boot and the CPU mitigations enabled in the installer.
PC 3 had a migration from grub2 to systemd-boot.
The 3 PCs had an empty parameters line in Yast Bootloader (and so /etc/kernel/cmdline). Mitigations were disabled on all 3.
I will try firing a VM (when I have time) with the latest Tumbleweed snapshot with systemd-boot and mitigations enabled and hope to find that /etc/kernel/cmdline file populated the way it should be.
Thanks again.
Did a fresh install in a VM.
/etc/kernel/cmdline is populated with root=/dev/vda2 splash=silent quiet security=selinux selinux=1 enforcing=1 mitigations=auto as it should be.
Will never know what happened with my 3 installs as the only thing I tinkered with in Yast Bootloader before wanting to make the switch to Selinux was the timeout in the last tab.
Good to know this works now.
Thanks for the help.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.