Hang at boot on Dell Inspiron 15
I built a Spectrum OS image using https://github.com/DemiMarie/spectrum/tree/499323fa448406ec728b1f29a4bca6dc5.... This is almost the same as Spectrum git main, and I am almost certain that the differences (visible on GitHub) are not related to this problem. Therefore, I'm reporting this as if it were a bug in Spectrum itself. The bug is pretty simple: on a Dell Inspiron 15, booting freezes forever. The last message from the kernel before it stops is: amdgpu 0000:03:00.0: [drm] fb0: amdgpudrmfb frame buffer device This machine has an AMD Ryzen 7000 series CPU with integrated graphics and a 512GB NVMe drive. The installation ISO was built by $ nix build --log-format bar-with-logs --file release/combined --out-link "path to Caddy web root" with a custom config.nix that I can also share if needed. It just specifies the update URL and signing key, though. The actual install ISO I built can be found at <https://test-spectrum-updater.devbydemi.com/demi/spectrum-updates/spectrum-installer.iso> (no authentication needed). This was built on (and is hosted by) a test server I don't particularly trust, so don't mount or boot it on a machine you care about outside of a VM with no GPU acceleration or other sandbox holes. To even install Spectrum, I had to kexec from the existing NixOS install because the firmware wouldn't boot the image off of the USB stick. I presume this is a firmware bug, which would not at all surprise me. I'm not sure how to go about diagnosing this. The hang happens after s6 gets started, but the boot is so fast that it is hard to tell if it has switched from the initramfs to the rootfs yet. In any case, it seems to happen before Weston gets a chance to produce any output on screen. Suggestions welcome! -- Sincerely, Demi Marie Obenour (she/her/hers)
Demi Marie Obenour <demiobenour@gmail.com> writes:
I built a Spectrum OS image using https://github.com/DemiMarie/spectrum/tree/499323fa448406ec728b1f29a4bca6dc5.... This is almost the same as Spectrum git main, and I am almost certain that the differences (visible on GitHub) are not related to this problem. Therefore, I'm reporting this as if it were a bug in Spectrum itself.
The bug is pretty simple: on a Dell Inspiron 15, booting freezes forever. The last message from the kernel before it stops is:
amdgpu 0000:03:00.0: [drm] fb0: amdgpudrmfb frame buffer device
This is most likely the known issue where we hardcode an assumption that we should wait for /dev/dri/card0, but on some hardware there's only /dev/dri/card1, at least by the time we get that far in boot. Perhaps you can try replacing card0 with card1 in the sources to confirm. (This is a very serious issue, of course, but there's apparently an easy fix for it with COSMIC, and I don't know of one with Weston, so it's been waiting for the switchover.)
This machine has an AMD Ryzen 7000 series CPU with integrated graphics and a 512GB NVMe drive. The installation ISO was built by
$ nix build --log-format bar-with-logs --file release/combined --out-link "path to Caddy web root"
with a custom config.nix that I can also share if needed. It just specifies the update URL and signing key, though. The actual install ISO I built can be found at <https://test-spectrum-updater.devbydemi.com/demi/spectrum-updates/spectrum-installer.iso> (no authentication needed). This was built on (and is hosted by) a test server I don't particularly trust, so don't mount or boot it on a machine you care about outside of a VM with no GPU acceleration or other sandbox holes.
To even install Spectrum, I had to kexec from the existing NixOS install because the firmware wouldn't boot the image off of the USB stick. I presume this is a firmware bug, which would not at all surprise me.
Does the live image boot?
I'm not sure how to go about diagnosing this. The hang happens after s6 gets started, but the boot is so fast that it is hard to tell if it has switched from the initramfs to the rootfs yet. In any case, it seems to happen before Weston gets a chance to produce any output on screen. Suggestions welcome!
If it's not the card0/card1 thing, some other debugging tips: • Did this ever work? If so, first thing to try should usually be bisection. • You should be able to switch VT in the usual way (Ctrl-Alt-F2). getty is running on tty2, tty3, and tty4. • You should be able to get a serial getty if you include an appropriate console parameter on the kernel command line, which can be edited in GRUB.
On 1/10/26 15:58, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
I built a Spectrum OS image using https://github.com/DemiMarie/spectrum/tree/499323fa448406ec728b1f29a4bca6dc5.... This is almost the same as Spectrum git main, and I am almost certain that the differences (visible on GitHub) are not related to this problem. Therefore, I'm reporting this as if it were a bug in Spectrum itself.
The bug is pretty simple: on a Dell Inspiron 15, booting freezes forever. The last message from the kernel before it stops is:
amdgpu 0000:03:00.0: [drm] fb0: amdgpudrmfb frame buffer device
This is most likely the known issue where we hardcode an assumption that we should wait for /dev/dri/card0, but on some hardware there's only /dev/dri/card1, at least by the time we get that far in boot. Perhaps you can try replacing card0 with card1 in the sources to confirm.
I can confirm that this is in fact the problem. Editing /run/service/weston/run and passing --drm-device=card1 allows Weston to start. I made a bunch of other changes but they should not be relevant here.
(This is a very serious issue, of course, but there's apparently an easy fix for it with COSMIC, and I don't know of one with Weston, so it's been waiting for the switchover.)
This machine has an AMD Ryzen 7000 series CPU with integrated graphics and a 512GB NVMe drive. The installation ISO was built by
$ nix build --log-format bar-with-logs --file release/combined --out-link "path to Caddy web root"
with a custom config.nix that I can also share if needed. It just specifies the update URL and signing key, though. The actual install ISO I built can be found at <https://test-spectrum-updater.devbydemi.com/demi/spectrum-updates/spectrum-installer.iso> (no authentication needed). This was built on (and is hosted by) a test server I don't particularly trust, so don't mount or boot it on a machine you care about outside of a VM with no GPU acceleration or other sandbox holes.
To even install Spectrum, I had to kexec from the existing NixOS install because the firmware wouldn't boot the image off of the USB stick. I presume this is a firmware bug, which would not at all surprise me.
Does the live image boot?
I initially installed by booting it with kexec, but fixing the partition table with fdisk so the backup GPT is at the end allowed the firmware to boot it. It seems that the firmware is very picky about this.
I'm not sure how to go about diagnosing this. The hang happens after s6 gets started, but the boot is so fast that it is hard to tell if it has switched from the initramfs to the rootfs yet. In any case, it seems to happen before Weston gets a chance to produce any output on screen. Suggestions welcome!
If it's not the card0/card1 thing, some other debugging tips:
• Did this ever work? If so, first thing to try should usually be bisection. • You should be able to switch VT in the usual way (Ctrl-Alt-F2). getty is running on tty2, tty3, and tty4.
I did that and it really helped.
• You should be able to get a serial getty if you include an appropriate console parameter on the kernel command line, which can be edited in GRUB.
Most laptops don't have a serial port, so this is (sadly) not very useful in practice. Unfortunately, I was not able to use the machine because it only has Wi-Fi, which isn't supported yet. Probably not the best machine for testing :). I can of course use a USB NIC, but that gives me networking on the host, not the guest. Is there a way to run a full Linux distro in the network VM? Or should I simply replace the hardware with one more suitable to the task? -- Sincerely, Demi Marie Obenour (she/her/hers)
Demi Marie Obenour <demiobenour@gmail.com> writes:
Unfortunately, I was not able to use the machine because it only has Wi-Fi, which isn't supported yet. Probably not the best machine for testing :). I can of course use a USB NIC, but that gives me networking on the host, not the guest.
Is there a way to run a full Linux distro in the network VM? Or should I simply replace the hardware with one more suitable to the task?
Until we have Wi-Fi, which probably won't be too far away, I'd have thought you'd be able to get by without networking? It shouldn't be necessary to test any other functionality of the system.
participants (2)
-
Alyssa Ross -
Demi Marie Obenour