[RESOLVED] Linux wont start on AMD without nomodeset

I’ve tried Fedora 39 and Mint 21.2 Edge, without setting nomodeset the installers won’t even start, after install if I don’t have nomodeset it also won’t boot.

With nomodeset I can’t use any external monitor, to do my work I need to connect my external monitor, so it’s not a good workaround.

The strange thing is that with nomodeset I’ve seen it crash in several different ways, not a single one.

Any help? Thanks.

Edit: There are other problems, but this one is the worse for now, if I solve this at least I can start using the laptop.

Update your BIOS.

1 Like

I came with the latest (3.03)

That’s quite odd then - in the installed OS can you post the journal from a boot without nomodeset?

It freezes before I have any terminal or something, I will post pictures, but it’s not giving relevant info (at least not that I can see).

You can look at the last boot’s journal like this: journalctl -k -b-1 > journal.txt

Didn’t know that thanks,
In the case of starting from the USB before installing that won’t work, but for sure after installing that’s going to be helpful.
Will do that later today.

Meanwhile I’m uploading the boots that I took pictures.

Note, several of these look like they are still booting, (the kernel panic is obvious, others are not), but all of them I left them for more than one minute frozen before taking the picture.

The most common one is the one that goes up to “Started gdm.service” and freezes there, the kernel panic only happen once.

I need to see the full journal to understand if this soft lock is a perpetrator or a victim.

I would suggest if you haven’t already to check with no modules or anything else plugged in.

Have you changed any BIOS settings? By chance do you have Windows also and can see if it’s got problems too?

Fwiw from where it hung in the log you posted Windows might only show it after you have done hardware accelerated video playback if it’s the same problem.

I’m doing several boots to have several journal reports, I will post a good one when I have it.

By modules what do you mean? the 4 modules that cover the laptop ports? If it’s that, I have 2xUSB-C, 1xUSB-A and 1xHDMI. Apart for the power supply I have nothing connected to them.

I only changed a config that limit’s the battery charge to prolong battery life, but that should not have anything to do with this.

I don’t have any Windows.

Ok, I did 3 boots and they crashed in the same way, the journal also looks similar.

I can’t post the entire text (too big) and I can’t upload the file (not authorized extensions), so I changed the extension to scad, but it’s just text.

crash1.scad (119.1 KB)

crash2.scad (117.7 KB)

crash3.scad (118.0 KB)

None of those seem to match a boot with amdgpu loading. Can you double check the arguments you used and spacing? You can double check the kernel command line from a log in the header.

Dec 18 15:09:17 fedora kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.6.6-200.fc39.x86_64 root=UUID=df6389e7-b10e-4ca1-a0a7-2bdf3e97ef5e ro rootflags=subvol=root rd.luks.uuid=luks-f4d6ad3a-b041-47f1-a1d0-e2e80c37f993 nomodeset rhgb quiet

Yeah that’s what I meant - take those out in case they’re causing the problem.

Comparing with a boot with nomodeset this is the extra lines

Dec 18 15:06:02 framework kernel: usb 1-4: reset full-speed USB device number 2 using xhci_hcd
Dec 18 15:06:04 framework kernel: rfkill: input handler enabled
Dec 18 15:06:07 framework kernel: wlp1s0: deauthenticating from 6c:cd:d6:b2:18:78 by local choice (Reason: 3=DEAUTH_LEAVING)
Dec 18 15:06:07 framework kernel: kauditd_printk_skb: 57 callbacks suppressed
Dec 18 15:06:07 framework kernel: audit: type=1305 audit(1702911967.588:289): op=set audit_pid=0 old=1337 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditd_t:s0 res=1
Dec 18 15:06:07 framework kernel: audit: type=1131 audit(1702911967.602:290): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=auditd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 18 15:06:07 framework kernel: audit: type=1131 audit(1702911967.614:291): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-tmpfiles-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 18 15:06:07 framework kernel: audit: type=1131 audit(1702911967.622:292): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=import-state comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 18 15:06:07 framework kernel: EXT4-fs (nvme0n1p2): unmounting filesystem 0d771651-35d6-4a6b-93d5-caa9cbd5b246.
Dec 18 15:06:07 framework kernel: audit: type=1131 audit(1702911967.720:293): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-fsck@dev-disk-by\x2duuid-18E5\x2d7601 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 18 15:06:07 framework kernel: audit: type=1131 audit(1702911967.771:294): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-cryptsetup@luks\x2df4d6ad3a\x2db041\x2d47f1\x2da1d0\x2de2e80c37f993 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Dec 18 15:06:07 framework kernel: audit: type=1131 audit(1702911967.786:295): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-fsck@dev-disk-by\x2duuid-0d771651\x2d35d6\x2d4a6b\x2d93d5\x2dcaa9cbd5b246 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 18 15:06:07 framework kernel: audit: type=1131 audit(1702911967.826:296): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-remount-fs comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 18 15:06:07 framework kernel: audit: type=1131 audit(1702911967.844:297): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-tmpfiles-setup-dev comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 18 15:06:07 framework kernel: audit: type=1131 audit(1702911967.851:298): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-tmpfiles-setup-dev-early comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 18 15:06:07 framework kernel: zram0: detected capacity change from 16777216 to 0
Dec 18 15:06:07 framework kernel: watchdog: watchdog0: watchdog did not stop!
Dec 18 15:06:07 framework systemd-shutdown[1]: Using hardware watchdog 'SP5100 TCO timer', version 0, device /dev/watchdog0
Dec 18 15:06:07 framework systemd-shutdown[1]: Watchdog running with a timeout of 10min.
Dec 18 15:06:07 framework systemd-shutdown[1]: Syncing filesystems and block devices.
Dec 18 15:06:07 framework systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Dec 18 15:06:07 framework systemd-journald[1098]: Received SIGTERM from PID 1 (systemd-shutdow).

Will do that.

Same problem, will bring logs.

Last post I did a mistake and deleted it.

No modules…
crash-nomods1 and crash-nomods2 crashed visually in a different way, crash-nomods4 crashed in a similar way to the ones posted before but didn’t take a picture.

crash-nomods1.scad (118.4 KB)
crash-nomods2.scad (116.7 KB)
crash-nomods4.scad (116.3 KB)

Don’t know if it helps (or if it’s related), but when I start with nomodeset, closing the lead does go to suspend and if send the computer to suspend it won’t wake again, I will need to force shutdown (press power for 10s).

Edit: To be frank I don’t know if it’s not waking up, the screen is black, maybe it’s waking up but just the screen keeps black.

This is one of the other things not working, if it’s not related we can not talk about this until the main problem is solved and get back to this after.

Many thanks, I really appreciate the time and help you’re giving.

I have the same issue with the lid closed or open and it going into suspend/sleep…nomodeset shouldn’t have anything to do with that issue.

Those logs still are with nomodeset.

Running with nomodeset will prevent graphics from working after suspend.

You are right, but when I run journalctl --list-boots, the boots without nomodeset are not there, so when I was doing -b-1 I was not getting the previous (without nomodeset) but the one before.

This means I again don’t know how to get more info.

That’s actually a good news, it means when I solve this problem, potentially I’ll solve the other one.