Search

And yet, there are several distributions based on Arch designed to ease Arch installation and usage. Installing EndeavourOS is hardly any more work than installing Mint. If you're using KDE, and install bauh, you can use Arch and barely be aware that it's supposed to be a snooty, technical distribution.

The distro leaders can do whatever they want. I think it's a bad decision by Arch - I call bullshit on the "we can't detect" statement, because you can absolutely test for whether X is installed in a PKGBUILD - and as a community contributor, I object to it. It's intentionally exclusionary and at a time when many people still have issues with Wayland being incomplete and outright broken for some cases.

Nice. I will try the systemd unit. Meanwhile, i have added a loop in the script, which helps a little bit:

 undefined

    
maxwait=15
if [[ $(nm-online -x) != *"online"* ]]; then
    echo "missing internet connection, waiting..."
    for (( i = 1; i <= maxwait; ++i )); do
        sleep 1 &
        echo $i
        if [[ $(nm-online -x) == *"online"* ]]; then
            break
        fi

        if [[ $i -eq $maxwait ]]; then
            echo "No internet connection"
            exit 1
        fi
        wait
    done 
fi

  

In my test, this exits the script after 15 seconds without connection, but continues, when the connection is available or is established within this time.

But i think, its a nice idea, to add this to the script AND use the systemd unit together.

Create a systemd user unit that waits for the network-online.target.

A script something like:

 undefined

    
[Unit]
Description=Startup script
Requires=network-online.target
After=network-online.target

[Service]
Type=oneshot # either simple or oneshot, but sounds like oneshot
ExecStart=/home/<user>/script.sh
RemainAfterExit=yes #if oneshot, otherwise no

[install]
WantedBy=default.target

  

Edit the template according to your needs and dump it into ~/.local/share/systemd/user/<unit>.service and enable it with systemctl --user enable --now <unit>

Apart from trying the hook way, I would default to just checking the timestamp of /var/lib/pacman/sync/core.db and extra.
As any upgrade should be a system upgrade.

Now sure about your question specifically, but env vars are at runtime (you started the command), or for a service (add them to the service). Hope that helps.

debug nomedeset

It worked! I managed to boot into the system. Updated it and installed linux-lts along with linux-lts-headers. Adjusted /boot/loader/entries/arch_linux.conf to switch to the lts kernel by default and rebooted the PC. Unfortunately, didn't work but I got logs! Here's the relevant part, I think:

    
mai 03 11:04:23 arch kernel: amdgpu: [powerplay] Failed message: 0xe, input parameter: 0x0, error code: 0xffffffff  
mai 03 11:04:23 arch kernel: amdgpu: [powerplay] Failed message: 0x4, input parameter: 0x2000000, error code: 0xffffffff  
mai 03 11:04:23 arch kernel: [drm:resource_construct [amdgpu]] *ERROR* DC: unexpected audio fuse!  
mai 03 11:04:23 arch kernel: [drm] Display Core v3.2.316 initialized on DCE 12.0  
mai 03 11:04:23 arch kernel: amdgpu 0000:0a:00.0: [drm] *ERROR* No EDID read.  
mai 03 11:04:23 arch kernel: amdgpu 0000:0a:00.0: [drm] *ERROR* No EDID read.  
mai 03 11:04:23 arch kernel: amdgpu 0000:0a:00.0: [drm] *ERROR* No EDID read.  
mai 03 11:04:23 arch kernel: amdgpu 0000:0a:00.0: [drm] *ERROR* No EDID read.  
mai 03 11:04:23 arch kernel: [drm] Timeout wait for RLC serdes 0,0  
mai 03 11:04:23 arch kernel: [drm] kiq ring mec 2 pipe 1 q 0  
mai 03 11:04:23 arch kernel: amdgpu 0000:0a:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring kiq_0.2.1.0 test failed (-110)  
mai 03 11:04:23 arch kernel: [drm:amdgpu_gfx_enable_kcq [amdgpu]] *ERROR* KCQ enable failed  
mai 03 11:04:23 arch kernel: [drm:amdgpu_device_init.cold [amdgpu]] *ERROR* hw_init of IP block <gfx_v9_0> failed -110  
mai 03 11:04:23 arch kernel: amdgpu 0000:0a:00.0: amdgpu: amdgpu_device_ip_init failed  
mai 03 11:04:23 arch kernel: amdgpu 0000:0a:00.0: amdgpu: Fatal error during GPU init  
mai 03 11:04:23 arch kernel: amdgpu 0000:0a:00.0: amdgpu: amdgpu: finishing device.  
  
  

I did a search and it seems like it's the GPU's fault due to the ring errors. I think. I remembered I have an old nvidia GPU laying around so I'm going to try to reseat the current GPU and, if that doesn't work, try the old one. Not sure if I have to uninstall the amd drivers or if it's ok to have both the amd and nvidia drivers installed.

EDIT in case you missed it: So, I changed the GPU to a different PCIe slot and everything's working fine so far. I'm not celebrating just yet because when this first happened a few months ago, I'd hard reset the PC and everything would work fine. But if I shut it down and let it pass like 12 hours before I'd power it on again, the problem would reappear. So I'm just basically waiting for tomorrow now.

I'm in. $10 on "this reported kernel panic is not resolved by any change to which nvidia kernel driver is loaded, patched or not, or how anything pertaining nvidia is configured".

nvidia is at fault for many issues, agreed, but not this one.

You could increase verbosity, and try working up your way from booting a bare minimum, to see when the system hangs, and if it persistently hangs at the same time, in the same way.

My usual go-to is to add debug apic=debug init=/bin/sh vga=0 nomodeset acpi=off to kernel boot arguments and see if I consistently drop into the bare initramfs shell that way, without switching to any framebuffer graphics mode, while also avoiding potential ACPI breakage that may manifest as early boot freezes. Yes, vga=0 is legacy BIOS only, feel free to skip that one if you're booting UEFI. This is not likely to avoid your problem, anyway.

If that works, remove the arguments, from the right, one after another, to re-enable ACPI, then KMS, then automatic framebuffer console setting. If you're still going, change init=/bin/sh to emergency, then to rescue, then remove to boot normally, always with excessive debug output. At that point, boot should freeze again, as you've only increased verbosity. The messages leading up to the freeze should always give a hint as to what subsystem might be worth looking into further - be it a specific module that freezes, which can subsequently be blacklisted by kernel parameter, for example. Let the system tell you its woes before stabbing at its parts randomly.

This does not assume you having a software fault. This procedure uses the kernel init and following boot process as diagnostics, in a way. Unfortunately, it is pretty easy to miss output that is "out of the ordinary" if you're not used to how a correct boot is supposed to look like, but the info you need is typically there. I typically try this before unplugging all optional hardware, but both approaches go hand in hand, really. I've found in modern, highly integrated systems, there's just not that much available to unplug anymore that would make a difference at boot time, but the idea is still sound.

If this becomes involved, you might want to look into using netconsole to send the kernel messages somewhere else to grab with netcat, and store them in a plain text file to post here for further assistance. You might just get a good hint when reading the debug kernel messages yourself already, though!

EDIT: If those two colorful, pixely dotted lines in the lower half of your literal screen shot happen to flicker into view during boot somewhat consistently right before freezing, my gut feeling says it's likely a graphics-related issue. You might want to short-circuit your tests by trying only debug nomodeset, a more brutal debug nomodeset module_blacklist=amdgpu,radeon, or replacing your GPU with a known good model, as suggested.

My bet's on hardware.

Boot memtest86+ and let it run (overnight...?) that's the simplest & easiest test - even if the RAM is ok, it might show other problems (over heating, etc)