and did you disable the TPM Trust Platform Technology under security in bios, as suggested in the link above
There’s no setting for that. I have messed with bios settings though and they don’t help.
Guys I noticed that using the fallback initramfs seems to consistently boot the system.
very interesting 
1 Like
So something is messed up apparently. I remind you that the live usb sometimes fails to boot as well. Probably, the fallback initramfs does something that the default one does not. Should I configure grub to always use the fallback one or is there any problem with that?
Looks like this issue:
In your case it would be i915 instead of amdgpu.
I added:
MODULES=(i915 nvidia)
and then:
MODULES=(i915 nvidia nvidia_modeset nvidia_uvm nvidia_drm)
Neither worked. I use the nvidia prime intel/nvidia hybrid driver (the default one).
Another issue is that in (successful) boots without fallback initramfs sometimes it doesn’t resume after suspend. This doesn’t happen when I use the fallback initramfs.
Looking at the journalctl logs I wasn’t able to find something meaningful by comparing fallback and default initramfs.
shouldnt be it like this?:
MODULES="i915 nvidia nvidia_drm nvidia_uvm nvidia_modeset" “” quotes instead of ()
try it with “” than run:
sudo mkinitcpio -P
reboot
The arch wiki mentions that the quotes were deprecated. It even uses examples in comments with the parentheses.
ok, good to know… so what remains is running on the fallback kernel…
could you post your mkinitcpio.conf file please? I guess that something is wrong there.
# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run. Advanced users may wish to specify all system modules
# in this array. For instance:
# MODULES=(piix ide_disk reiserfs)
MODULES=""
# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image. This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=()
# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way. This is useful for config files.
FILES=""
# HOOKS
# This is the most important setting in this file. The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added. Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
## This setup specifies all modules in the MODULES setting above.
## No raid, lvm2, or encrypted root is needed.
# HOOKS=(base)
#
## This setup will autodetect all modules for your system and should
## work as a sane default
# HOOKS=(base udev autodetect block filesystems)
#
## This setup will generate a 'full' image which supports most systems.
## No autodetection is done.
# HOOKS=(base udev block filesystems)
#
## This setup assembles a pata mdadm array with an encrypted root FS.
## Note: See 'mkinitcpio -H mdadm' for more information on raid devices.
# HOOKS=(base udev block mdadm encrypt filesystems)
#
## This setup loads an lvm2 volume group on a usb device.
# HOOKS=(base udev block lvm2 filesystems)
#
## NOTE: If you have /usr on a separate partition, you MUST include the
# usr, fsck and shutdown hooks.
HOOKS="base udev autodetect modconf block keyboard keymap consolefont filesystems fsck shutdown"
# COMPRESSION
# Use this to compress the initramfs image. By default, gzip compression
# is used. Use 'cat' to create an uncompressed image.
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"
#COMPRESSION="zstd"
# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()
1 Like
Exactly like mine. Anyway, I don’t know if it makes sense to waste more time. Apparently something in this file doesn’t work in my system.
running the fallback kernel is not problematic… you can keep this open, someone may have some useful input…
Thanks everyone for your help. I know that it sounds like a minor problem but it implies that there is something wrong. I will use the fallback initramfs for now.
you can check this link out on arch wiki
basically the ‘normal’ kernel is more minimalistic; and the fallback is the same as ‘normal’ but with the full range of modules/ drivers … so the normal kernel doesnt load some modules/ drivers, that break your system, and the fallback load all of modules/ drivers, including the one(s) that are required by your system… thats how i understand it …
EDIT: could be possible to find out what is the module/driver that is required by your system? … also whats the ram usage on normal kernel and on the fallback kernel
and also whats the difference in loaded modules in normal and in fallback, comparing those with the lsmod command?..
1 Like
I would doubt that it would make any noticeable difference in ram usage. With the fallback initramfs it consumes 700MB which is not a lot for gnome.
I think that the intel-ucode is not loaded in the fallback initramfs though. I have flashed the latest bios/uefi version (2020). Security wise is this a problem?
By saying that… maybe the settings has been reset. So what real difference here between default and fallback is the cached state.
So guess this: Your uefi do a fastboot, so it skips initialization steps. The default kernel does the same and presumes it does not change. The fallback kernel just initialized everything again, no matter what the UEFI does or if there is cache.
So therefore, check the UEFI and switch to full initialization.
Switching from
initrd /boot/intel-ucode.img /boot/initramfs-5.15-x86_64.img
to
initrd /boot/initramfs-5.15-x86_64.img
seems to solve the issue even with the normal initramfs. The fallback initramfs doesn’t include the intel-ucode image and I guess that’s why it works. Any pointers from here?
As I’ve mentioned before it’s not uefi-related.
Then it is CPU related, since that microcode should fix the CPU behavior.
Sure, as you see, disabling the microcode solves the problem. And that is clearly related to the UEFI Firmware. But since the microcode is proprietary, there is nothing you can do at this point.