cannot boot with linux-libre kernel 5.7.2-1 and cryptsetup
I have cryptsetup when I boot. For a long time, I have not been able to see the prompt to input the password, but I can still boot (it's there, I just don't see it). I upgraded my system yesterday, and when I tried to boot today, I realised that the computer would not boot; it would not move from the blank screen that I regularly see.
I restarted the computer, and added `nomodeset' to the linux-libre kernel line of GRUB. That allowed me to boot, but I cannot log-in to a graphical interface. I restarted again and tried without the `nomodeset' with linux-libre-lts, but I could not boot.
After adding `nomodeset' to the linux-libre kernel again, I downgraded linux-libre to 5.6.12-1 and was able to boot in my regular and unorthodox method (blank screen, type in my cryptsetup password blindly).
I don't know what information is required, but I have an AMD Ryzen 2500 which comes embedded with a Vega 8 graphics card. My kernel line is
linux /vmlinuz-linux-libre-lts root=<<my-root>> rw cryptdevice=<<my-device>> resume=<<my-resume>> spec_store_bypass_disable=on quiet splash fbcon=font:TER16x32
the specs from lspci for my Grahpics card are
[AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] [1002:15dd]
the specs for my cpu from lscpu are
AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx ... Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca
Updated by bill-auger 7 months ago
this looks to me pretty much of a duplicate of #1750 which was posted two years ago by the same person - that one is still open marked: 'info-needed'
is this essentially the same problem as #1750? - is it the same ryzen computer? - if so, we should close this ticket and continue the discussion with #1750 - otherwise, you noted in #1750 that the original problem was fixed, so maybe this is a different problem, and #1750 should be closed instead
No, bill, it's not the same issue. It is the same computer. The behaviour now is that the system does NOT take my password unless I downgrade. As I mentioned:
...For a long time, I have not been able to see the prompt to input the password, but I can still boot...
About bug #1750, I still don't know why it is still marked as info needed, if I already provided everything which was requested, and nobody has asked me for more. I guessed it was not a priority.
- This only happens after I install linux-libre 5.7.2-1-x86_64
- I can boot with `nomodeset' with linux-libre 5.7.2-1-x86_64
- I can go back to 5.6.12-1.x86_64 or linux-libre-lts 5.4.41-1_x86_64
I guess that the answer is yes.
My whole disk is encrypted. I hope that there is a way to test this without uninstalling my whole system (including my personal files and configuration).
Updated by bill-auger 7 months ago
the first thing i would try is to remove "quiet splash fbcon=font:TER16x32" from the grub command - that may reveal some information, either with or without nomodeset
i have seen it suggested, that if some laptops have a black screen while booting, you can shine a flashlight on the screen and you may see that the display is actually working but the backlight is off
- Removing `quiet splash' shows some messages before the rest of the messages are suppressed.
- With `nomodeset' I see the whole list of messages in the boot process
- `fbcon=fontÑTER16x32' makes no difference except in the font size
- Leaving the kernel line as it is with 5.6.12-1-x86_64 and 5.7.2-1-x86_64, I know that the screen is on (backlight is not interfering in any way)
- It seems that 5.7.2-1-x86_64 disables my keyboard
- If I install 5.6.12-1-x86_64, I can hit [CTRL] + [ALT] + [DEL] to restart the computer
- with 5.7.2-1-x86_64, [CTRL] + [ALT] + [DEL] does nothing
- As in #1750, I can still see (without `quiet splash' or with `nomodeset') the message
AMD-Vi: Unable to read/write to IOMMU perf count
Updated by bill-auger 7 months ago
On Sat, 27 Jun 2020 15:01:27 +0000 email@example.com wrote:
It seems that 5.7.2-1-x86_64
disables my keyboard
when i rebooted a few moments ago, kernel 5.7.2-gnu-1, my
keyboard was not working either - even the caps-lock key
would not toggle the LED
i have two keyboards and im not sure if that made any
difference; i did not try the other one at first - i
waited at the login prompt for about a minute, then i
pressed a key on the other keyboard, then they were
That is super interesting. I currently do not have an external keyboard, but seems like a step forward. Let me know if I can help :) . May be if I play around with the `mkinitcpio.conf' hooks? I have these right now:
HOOKS=("base" "udev" "keyboard" "keymap" "autodetect" "modconf" "block" "consolefont" "encrypt" "lvm2" "resume" "filesystems" "fsck" "shutdown")
Updated by bill-auger 7 months ago
do you have a USB wifi or anything else plugged in? - i also
noticed that the USB wifi thingy would not activate - i had to
unplug it and plug it in again to get the system to recognize
i dont know that there is any good suggestion in that - just
a clue perhaps - maybe just try booting with nothing extra
plugged in, and wait 5 minutes before trying to log in - just to
see if it maybe will accept the keyboard input eventually
I contacted the linux-libre mailing list and did some other tests:
1 Loading amdgpu early in the grub
│ GRUB_PRELOAD_MODULES="amdgpu ...
Listing 1: Adding amdgpu as preloaded module in `/etc/default/grub' does not have an effect (blank screen, no cryptsetup prompt)
2 Removing amdgpu
Listing 2: Removing amdgpu in `/etc/mkinitcpio.conf' and uninstalling `xf86-video-amdgpu' shows up to some lines of OpenRC.
│ # pacman -Rnucs xf86-video-amdgpu
2.1 Adding `nomodeset' to the kernel line
Adding `nomodeset' to the kernel line eventually clears the screen and shows a static underscore at the top left corner. If I type-in my user password (with the blank screen) and follow the process to shutdown as if I had logged in (without being able to see anything), the computer actually shuts down. That indicates that the boot process completes, but I have nothing on screen except for the underscore.
Thank you, bill. I can confirm that it also happens with the new kernel.
May be this should be moved upstream?
cannot boot with linux-libre>=5.7, amdgpu and cryptsetup
You know, bill? I really appreciate all the effort that you make to keep this forum working! Thank you :).
I updated my system yesterday. It is completely broken. The only way that I have to log in is by adding modeprobe.blacklist=radeon modeprobe.blacklist=amdgpu to the kernel line on the boot loader. This leaves me without any graphical user interface. I tried to roll-back all changes by checking my pacman.log and using the previous packages, but even that did not work. Any help would be appreciated. Otherwise, I will thank you for all these years and will have to wave good bye my freedom to start using a non-libre linux.
Oof! After long days, I found out that VESA is not able to start with UEFI (/var/log/Xorg.0.log). Why? I don't know. Here is a hint:
- Refuse to run on UEFI framebuffers
To figure this out, I went through many hoops, including (you can safely skip this if you are a regular user):
- modprobe.blacklist=amdgpu is usually enough as a parameter in the kernel line to prevent a non-working screen and to drop into a command line (may need CTRL + ALT + F2)
- creating many LiveUSB with many Parabola's and other distro's ISOs
- booting parabola-x86_64-systemd-lxde-2019.06-pre-complete.iso (with the parameter mentioned earlier) with BIOS boot (not UEFI; this is super important)
- using Calamares (nothing else works, really) to install into an external HDD (USB memory sticks do not work, because they don't show up during installation).
- downgrade to 5.4.69-gnu-1-lts
To solve it (hopefully, it will boot after I restart):
- create a LiveUSB and boot with BIOS (not UEFI)
- go to your /boot/grub/grub.cfg and copy one of the previously-working entries
- install Parabola into an external hard drive
- add the previously-working entry into the new /boot/grub/grub.cfg
- boot from the external hard drive into the previously-working system
- remove amdgpu from MODULES in /etc/mkinitcpio.conf
- run mkinitcpio
p <your-kernel> (ex: mkinitcpio -p linux-libre-lts) shrink an (unencrypted) partition in your system
- create a new partition and format it as BIOS boot with fdisk (type 4) or any other means
- run grub-install --target=i386-pc /dev/sdX (replace X with the letter for your hard drive)
- add GRUB_ENABLE_CRYPTODISK=y to your /etc/default/grub (it may complain otherwise)
- run grub-mkconfig
o /boot/grub/grub.cfg (optional) add modprobe.blacklist=amdgpu to kernel line
- reboot and face the non-working grub
- reboot with the LiveUSB into the system (again)
- remove the GRUB_ENABLE_CRYPTODISK=y from your /etc/default/grub
- run grub-install --target=i386-pc /dev/sdX
- run grub-mkconfig
o /boot/grub/grub.cfg reboot into your VESA-enabled (amdgpu-free) system
If in doubt:
- https://www.rohlix.eu/post/linux-disk-encryption-with-bios-uefi-using-mbr-gpt-luks-lvm-and-grub/ (Linux: Full Disk Encryption with BIOS, UEFI using MBR, GPT, LUKS, LVM and GRUB -- GRUB on BIOS with GPT)
#1685 #2181 #2816 #1750 #1819
This makes me shiver (without BIOS boot, my system won't work):
This gives me hope:
"Warning: While the choice to install in UEFI mode is forward looking, early vendor UEFI implementations may carry more bugs than their BIOS counterparts. It is advised to do a search relating to your particular motherboard model before proceeding." --- from https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface
I refuse to mark this as solved. This is NOT a solution. I can still not use AMDGPU, it is working with VESA. I am of course humble enough to stand corrected, if needed.
Updated by bill-auger 3 months ago
FWIW, there is nothing wrong with dispensing of the EFI - if the
computer can boot in legacy BIOS mode, then EFI is a "YAGNI"
feature, for 99% of computer users
it is very interesting that only the 2019 calamares ISO could
install a system that your computer could boot - that ISO is o/c
quite old now; but i left it there because some people can not
boot the others (for other reasons though - mostly libreboot
users) - it is interesting that there is yet another reason why
someone needed it
you are not the first person to have trouble running a libre
system on a ryzen computer - i could only recommended that
people avoid them - you may have just discovered an important
clue though - the next time someone can not boot parabola with a
ryzen computer, i will suggest to try it without EFI
Yes, one advantage of logging this activity is that others can benefit from it.
Regarding Calamares, the other alternatives would need internet connection, but I was dealing with (what I thought was) a backwards compatibility situation. Meaning that I considered that a newer kernel and updated software would worsen the situation.
Also, my disk is fully encrypted and I did not want to risk the command grub-install --target=i386-pc /dev/sdX messing the encrypted headers. At the end, it may be that one can simply do an arch-chroot into the decrypted filesystem within a Live system, make sure to create a bios_grub partition and run such command without a risk (no mid-installation with Calamares needed).
It is important to note (again)
1. Blacklist (remove amdgpu from MODULES in /etc/mkinitcpio.conf or add modprobe.blacklist=amdgpu in the kernel line , and make sure it is not part of the preloaded modules inside /etc/default/grub or the configuration file of the boot-loader--usually grub.cfg)
2. No (U)EFI. The VESA drivers do not load with (U)EFI
 For the uninformed, one refers to the kernel line as the directive of the boot loader (e.g. GRUB or Syslinux) which runs the GNU/Linux kernel. One can usually modify the kernel line with [TAB] or [e] when the list of available operating systems show up when the computer starts. Adding modprobe.blacklist=amdgpu at the end of the line prevents the drivers for AMDGPU to load, and forces the VESA drivers. In the case of GRUB, look for the line starting with the word linux. For Syslinux, a line will usually show up at the bottom of the screen.