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'

nona -

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.

Thanks.

do you have the same problem without cryptsetup?

1. This only happens after I install linux-libre 5.7.2-1-x86_64
2. I can boot with `nomodeset' with linux-libre 5.7.2-1-x86_64
3. 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).

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

Hi, bill.

1. Removing `quiet splash' shows some messages before the rest of the messages are suppressed.
2. With `nomodeset' I see the whole list of messages in the boot process
3. `fbcon=fontÑTER16x32' makes no difference except in the font size
4. 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)
5. It seems that 5.7.2-1-x86_64 disables my keyboard
   1. If I install 5.6.12-1-x86_64, I can hit [CTRL] + [ALT] + [DEL] to restart the computer
   2. with 5.7.2-1-x86_64, [CTRL] + [ALT] + [DEL] does nothing
6. 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

Thanks.

On Sat, 27 Jun 2020 15:01:27 +0000 labs@parabola.nu 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
both working

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")

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

Nope, nothing is plugged in. I tried the hint about the 5 minutes, but still nothing. Thanks.

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
═════════════════
┌────
│ MODULES=()
└────
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.

the current is linux-libre-5.7.8 now - can someone try it and confirm if the problem is still present

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
Hardware/research/gpu/radeon

You know, bill? I really appreciate all the effort that you make to keep this forum working! Thank you :).

/me is becoming an expert cat-herder :)

is this still a problem with 5.8.5 ?

yes, still there

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:

https://centos.pkgs.org/7/centos-x86_64/xorg-x11-drv-vesa-2.4.0-3.el7.x86_64.rpm.html
- 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://wiki.archlinux.org/index.php/GRUB#GUID_Partition_Table_.28GPT.29_specific_instructions
- 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):
https://www.linux.org/threads/intel-ending-legacy-bios-support.30967/post-103083

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.

FWIW, there is nothing wrong with so called "legacy" BIOS mode
- if the computer can boot in that mode, then EFI is a bloated
"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

related to this forum thread maybe
https://labs.parabola.nu/boards/11/topics/589

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 [1], 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

Cheers!

[1] 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.

just for documentation, this problem was with a "Radeon Vega" GPU?

$ lspci | grep -i vga
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev c4)

Yes, still is.