[SOLVED] udev error during boot

tigerjack · 2024-03-29 08:01:08

While booting arch, right after the two messages

Loading linux Linux
Loading initial ramdisk

the boot freezes for two minutes. After that, I receive the error message

Timed out for waiting the udev queue being empty

This happened after yesterday upgrade, that updated

[2024-03-28T10:04:25+0100] [ALPM] upgraded linux-docs (6.8.1.arch1-1 -> 6.8.2.arch1-1)
[2024-03-28T10:04:30+0100] [ALPM] upgraded linux-headers (6.8.1.arch1-1 -> 6.8.2.arch1-1)
[2024-03-28T10:04:13+0100] [ALPM] upgraded util-linux-libs (2.40rc2-1 -> 2.40-1)
[2024-03-28T10:04:14+0100] [ALPM] upgraded util-linux (2.40rc2-1 -> 2.40-1)

Today's upgrade didn't resolve the issue, even though the same packages were upgraded again

[2024-03-29T08:49:17+0100] [ALPM] upgraded linux (6.8.2.arch1-1 -> 6.8.2.arch2-1)
[2024-03-29T08:49:20+0100] [ALPM] upgraded linux-docs (6.8.2.arch1-1 -> 6.8.2.arch2-1)
[2024-03-29T08:49:22+0100] [ALPM] upgraded linux-headers (6.8.2.arch1-1 -> 6.8.2.arch2-1)

Last edited by tigerjack (2024-04-04 09:19:21)

seth · 2024-03-29 10:00:14

https://bbs.archlinux.org/viewtopic.php?id=294344

[2024-03-28T10:04:14+0100] [ALPM] upgraded util-linux (2.40rc2-1 -> 2.40-1)

has

/usr/lib/udev/rules.d/60-rfkill.rules

making it a likely contender, but util-linux also ships the "default" /usr/bin stuff that's likely gonna be invoked by plenty of udev rules.
So try to move away /usr/lib/udev/rules.d/60-rfkill.rules and if that doesn't help whether downgrading both util-linux packages helps.

tigerjack · 2024-03-29 10:17:21

seth wrote:

https://bbs.archlinux.org/viewtopic.php?id=294344
[2024-03-28T10:04:14+0100] [ALPM] upgraded util-linux (2.40rc2-1 -> 2.40-1)
has
/usr/lib/udev/rules.d/60-rfkill.rules
making it a likely contender, but util-linux also ships the "default" /usr/bin stuff that's likely gonna be invoked by plenty of udev rules.
So try to move away /usr/lib/udev/rules.d/60-rfkill.rules and if that doesn't help whether downgrading both util-linux packages helps.

Unfortunately moving around that rule didn't help.

From the rules.d folder I get

-rw-r--r-- 1 root root  13K 28 mar 17.05 90-pipewire-alsa.rules
-rw-r--r-- 1 root root  387 28 mar 10.01 64-btrfs-dm.rules
-rw-r--r-- 1 root root  346 28 mar 10.01 64-btrfs-zoned.rules
-rw-r--r-- 1 root root   46 27 mar 16.15 60-rfkill.rules

and the pipewire package was also updated 2 days ago

[2024-03-28T17:45:54+0100] [ALPM] upgraded libpipewire (1:1.0.4-2 -> 1:1.0.4-3)
[2024-03-28T17:45:54+0100] [ALPM] upgraded pipewire (1:1.0.4-2 -> 1:1.0.4-3)
[2024-03-28T17:45:54+0100] [ALPM] upgraded pipewire-audio (1:1.0.4-2 -> 1:1.0.4-3)
[2024-03-28T17:45:54+0100] [ALPM] upgraded pipewire-pulse (1:1.0.4-2 -> 1:1.0.4-3)

so I will try moving out the pipewire udev rule first.

seth · 2024-03-29 10:29:07

Do you have any custom rules in /etc?

tigerjack · 2024-03-29 10:34:56

seth wrote:

Do you have any custom rules in /etc?

A couple of them, but I think it's more likely that they were put there but some other programs

>tree -taD /etc/udev/
[Mar  9 17:24]  /etc/udev/
├── [Sep 20  2020]  hwdb.d
├── [Nov 28  2022]  rules.d
│   ├── [Jan 24  2021]  backlight.rules
│   ├── [May  2  2022]  80-canon_mfp2.rules
│   └── [Nov 28  2022]  00-remove-nvidia.rules_bak
├── [Mar  3 18:04]  iocost.conf
└── [Mar  3 18:04]  udev.conf

tigerjack · 2024-03-29 12:42:08

seth wrote:

Do you have any custom rules in /etc?

Moving out the pulse audio and btrfs rules didn't have any effect. Is there any other way to understand which rule is causing this problem?

I looked at all other rules, but none of them seem to have been recently modified.

V1del · 2024-03-29 14:02:17

Can you post the contents of these rules?

seth · 2024-03-29 15:37:47

The system journal might actually indicate which udev rule hangs - did you check whether downgrading util-linux* fixes it?

tigerjack · 2024-03-29 17:55:37

V1del wrote:

Can you post the contents of these rules?

Do you mean the ones under /etc?
If I search for the rules outside of /usr/lib/udev

>locate -e .rules | grep -v "/usr/lib/udev/rules.d" | wc -l
95

While the ones in /etc only are 9.

>plocate -e .rules | grep "/etc" 
/etc/audit/audit-stop.rules
/etc/iptables/empty.rules
/etc/iptables/ip6tables.rules
/etc/iptables/iptables.rules
/etc/iptables/simple_firewall.rules
/etc/udev/rules.d/00-remove-nvidia.rules_bak
/etc/udev/rules.d/80-canon_mfp2.rules
/etc/udev/rules.d/backlight.rules
/usr/share/factory/etc/audit/audit-stop.rules

The ones that I posted before are cat'ed here
http://sprunge.us/koMvN0

tigerjack · 2024-03-29 18:02:21

seth wrote:

The system journal might actually indicate which udev rule hangs - did you check whether downgrading util-linux* fixes it?

The journal contains a lot of lines like the following ones

mar 29 13:47:43 azenb kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.PCI0.XHC.RHUB.SS06._PLD], AE_ALREADY_EXISTS (20230628/dswload2-326)
mar 29 13:47:43 azenb kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20230628/psobject-220)

and again three portions like this, that makes me wonder if it's a nouveau related bug (even though I don't see any upgrade related to nouveau in my pacman logs_

mar 29 13:47:43 azenb kernel: nouveau 0000:02:00.0: DRM: GART: 536870912 MiB
mar 29 13:47:43 azenb kernel: nouveau 0000:02:00.0: DRM: MM: using COPY for buffer copies
mar 29 13:47:43 azenb kernel: sdhci-pci 0000:00:14.5: SDHCI controller found [8086:02f5] (rev 0)
mar 29 13:47:43 azenb kernel: ------------[ cut here ]------------
mar 29 13:47:43 azenb kernel: WARNING: CPU: 3 PID: 144 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:112 r535_gsp_msgq_wait+0x1b7/0x1e0 [nouveau]
mar 29 13:47:43 azenb kernel: Modules linked in: hid_generic usbhid nouveau(+) i915 drm_ttm_helper gpu_sched serio_raw drm_gpuvm atkbd drm_exec sdhci_pci libps2 drm_buddy i2>
mar 29 13:47:43 azenb kernel: CPU: 3 PID: 144 Comm: (udev-worker) Not tainted 6.8.2-arch2-1 #1 a430fb92f7ba43092b62bbe6bac995458d3d442d
mar 29 13:47:43 azenb kernel: Hardware name: ASUSTeK COMPUTER INC. ZenBook UX534FTC_UX533FTC/UX534FTC, BIOS UX534FTC.306 04/20/2020
mar 29 13:47:43 azenb kernel: RIP: 0010:r535_gsp_msgq_wait+0x1b7/0x1e0 [nouveau]
mar 29 13:47:43 azenb kernel: Code: 72 36 48 89 da 48 81 c3 ff 0f 00 00 e8 a2 2f c8 ef 48 c1 eb 0c 41 01 dd 0f ae f0 49 8b 87 90 08 00 00 44 89 28 e9 8a fe ff ff <0f> 0b 48 >
mar 29 13:47:43 azenb kernel: RSP: 0018:ffffaada422975e8 EFLAGS: 00010246
mar 29 13:47:43 azenb kernel: RAX: 0000000000000000 RBX: 000000000000002a RCX: 0000000000d5a210
mar 29 13:47:43 azenb kernel: RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffaada42297540
mar 29 13:47:43 azenb kernel: RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
mar 29 13:47:43 azenb kernel: R10: 0000000000000001 R11: 0000000000000100 R12: 0000000000000020
mar 29 13:47:43 azenb kernel: R13: ffffaada42297630 R14: 0000000000000020 R15: ffff91e68f65e000
mar 29 13:47:43 azenb kernel: FS:  000077e7327e7540(0000) GS:ffff91e9cdcc0000(0000) knlGS:0000000000000000
mar 29 13:47:43 azenb kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
mar 29 13:47:43 azenb kernel: CR2: 00005d4b4f76c1e8 CR3: 000000010db1e002 CR4: 00000000003706f0
mar 29 13:47:43 azenb kernel: Call Trace:
mar 29 13:47:43 azenb kernel:  <TASK>
mar 29 13:47:43 azenb kernel:  ? r535_gsp_msgq_wait+0x1b7/0x1e0 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  ? __warn+0x81/0x130
mar 29 13:47:43 azenb kernel:  ? r535_gsp_msgq_wait+0x1b7/0x1e0 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  ? report_bug+0x171/0x1a0
mar 29 13:47:43 azenb kernel:  ? handle_bug+0x3c/0x80
mar 29 13:47:43 azenb kernel:  ? exc_invalid_op+0x17/0x70
mar 29 13:47:43 azenb kernel:  ? asm_exc_invalid_op+0x1a/0x20
mar 29 13:47:43 azenb kernel:  ? r535_gsp_msgq_wait+0x1b7/0x1e0 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  ? r535_gsp_msgq_wait+0x78/0x1e0 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  r535_gsp_msg_recv+0x4e/0x230 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  r535_gsp_rpc_send+0x1c6/0x2e0 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  r535_gsp_rpc_push+0x147/0x160 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  r535_gsp_rpc_rm_ctrl_push+0x40/0x130 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  r535_disp_oneinit+0x132/0xca0 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  nvkm_disp_oneinit+0x25/0xa0 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  nvkm_subdev_oneinit_+0x3f/0x110 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  nvkm_subdev_init_+0x2c/0x130 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  nvkm_subdev_ref+0x8b/0xd0 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  nvkm_engine_ref+0x1b/0x30 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  nvkm_ioctl_new+0x127/0x2b0 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  ? __pfx_nvkm_udevice_child_new+0x10/0x10 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  nvkm_ioctl+0x10b/0x250 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  nvif_object_ctor+0x10f/0x190 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  nvif_disp_ctor+0xba/0x270 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  nouveau_display_create+0xfc/0x530 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  nouveau_drm_device_init+0x3be/0x9f0 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  ? pci_update_current_state+0x72/0xb0
mar 29 13:47:43 azenb kernel:  nouveau_drm_probe+0x12c/0x280 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  local_pci_probe+0x42/0xa0
mar 29 13:47:43 azenb kernel:  pci_device_probe+0xc1/0x260
mar 29 13:47:43 azenb kernel:  ? sysfs_do_create_link_sd+0x6e/0xe0
mar 29 13:47:43 azenb kernel:  really_probe+0x19b/0x3e0
mar 29 13:47:43 azenb kernel:  ? __pfx___driver_attach+0x10/0x10
mar 29 13:47:43 azenb kernel:  __driver_probe_device+0x78/0x160
mar 29 13:47:43 azenb kernel:  driver_probe_device+0x1f/0x90
mar 29 13:47:43 azenb kernel:  __driver_attach+0xd2/0x1c0
mar 29 13:47:43 azenb kernel:  bus_for_each_dev+0x85/0xd0
mar 29 13:47:43 azenb kernel:  bus_add_driver+0x116/0x220
mar 29 13:47:43 azenb kernel:  driver_register+0x59/0x100
mar 29 13:47:43 azenb kernel:  ? __pfx_nouveau_drm_init+0x10/0x10 [nouveau b8e6757f25c87f7bbb7f1b0dd0b0d1417a90c758]
mar 29 13:47:43 azenb kernel:  do_one_initcall+0x58/0x320
mar 29 13:47:43 azenb kernel:  do_init_module+0x60/0x240
mar 29 13:47:43 azenb kernel:  init_module_from_file+0x89/0xe0
mar 29 13:47:43 azenb kernel:  idempotent_init_module+0x120/0x2b0
mar 29 13:47:43 azenb kernel:  __x64_sys_finit_module+0x5e/0xb0
mar 29 13:47:43 azenb kernel:  do_syscall_64+0x86/0x170
mar 29 13:47:43 azenb kernel:  ? do_syscall_64+0x96/0x170
mar 29 13:47:43 azenb kernel:  ? do_syscall_64+0x96/0x170
mar 29 13:47:43 azenb kernel:  ? do_syscall_64+0x96/0x170
mar 29 13:47:43 azenb kernel:  ? __irq_exit_rcu+0x4b/0xc0
mar 29 13:47:43 azenb kernel:  entry_SYSCALL_64_after_hwframe+0x6e/0x76
mar 29 13:47:43 azenb kernel: RIP: 0033:0x77e7332c688d
mar 29 13:47:43 azenb kernel: Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 >
mar 29 13:47:43 azenb kernel: RSP: 002b:00007ffeefa925f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
mar 29 13:47:43 azenb kernel: RAX: ffffffffffffffda RBX: 00005d4b4f76ee10 RCX: 000077e7332c688d
mar 29 13:47:43 azenb kernel: RDX: 0000000000000000 RSI: 000077e7333db376 RDI: 0000000000000021
mar 29 13:47:43 azenb kernel: RBP: 000077e7333db376 R08: 0000000000000001 R09: fffffffffffffe88
mar 29 13:47:43 azenb kernel: R10: 0000000000000050 R11: 0000000000000246 R12: 0000000000020000
mar 29 13:47:43 azenb kernel: R13: 00005d4b4f7672e0 R14: 0000000000000000 R15: 00005d4b4f771630
mar 29 13:47:43 azenb kernel:  </TASK>
mar 29 13:47:43 azenb kernel: ---[ end trace 0000000000000000 ]---
mar 29 13:47:43 azenb kernel: nouveau 0000:02:00.0: disp: one-time init failed, -110
mar 29 13:47:43 azenb kernel: nouveau 0000:02:00.0: DRM: [DRM/00000000:drmDevice] [NEW dispc570] (ret:-110)

seth · 2024-03-29 18:05:42

Most likely - your OP mentions linux-headers bein *updated* what implies linux (the kernel) should ahve been in that list, too?
Keep linux-utils, restore your udev rules and test the LTS kernel - or consider the binary nvidia driver.

If this doesn't help, please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

starlinger · 2024-03-29 21:47:08

I had a very similar (if not the same) issue after a full system update these days with the "Timed out for waiting the udev queue being empty" warning during boot.
journalctl -b had many nouveau related errors / warnings - even though I didn't have any nouveau related packages installed.
Turns out the nouveau modules seem to belong to the kernel package itself (pacman -Qo /usr/lib/modules/6.8.2-arch2-1/kernel/drivers/gpu/drm/nouveau/nouveau.ko.zst).

Installing the nvidia package fixed the problem for me.

tigerjack · 2024-03-30 13:13:12

seth wrote:

...

starlinger wrote:

...

So it seems quite likely that the problem is with the nouveau drivers after all. Since I don't have access to an Arch live usb stick at the moment, and then I don't want to freeze the system, I was thinking of being more cautious.

So, first thing should be to switch on that nouveau blacklist file, whose content is listed here

$> mv /etc/modprobe.d/blacklist-nouveau.conf{_bak,}
$>>cat /etc/modprobe.d/blacklist-nouveau.conf
blacklist nouveau
options nouveau modeset=0

After that, I tried a mkinitcpio -v, but it seems that the module is still loaded

    adding file: /etc/modprobe.d/blacklist-nouveau.conf
  -> Running build hook: [/usr/lib/initcpio/install/kms]
    adding module: nouveau (/lib/modules/6.8.2-arch2-1/kernel/drivers/gpu/drm/nouveau/nouveau.ko.
zst)
    adding dir: /lib/modules/6.8.2-arch2-1/kernel/drivers/gpu/drm/nouveau
    adding file: /lib/modules/6.8.2-arch2-1/kernel/drivers/gpu/drm/nouveau/nouveau.ko.zst

I tried also with

$> echo "install nouveau /bin/true" > /etc/modprobe.d/blacklist-nouveau.conf

but mkinitcpio -v still returns the modules as loaded by the kms hook.

I can manually modify the /usr/lib/initcpio/install/kms file of course, but I don't know if it is the right solution.

seth · 2024-03-30 15:28:01

https://wiki.archlinux.org/title/NVIDIA#Installation
You only have to
a) install the nvidia drivers (don't conduct a partial update, they've to match the installed kernel!)
b) remove the kms hook and regenerate the initramfs (though the latter alone will include the blacklist if you've the modprobe hook active)

You cannot really break the system this way to the point where it becomes unbootable, the multi-user.target in doubt along "nomodeset" will still work (2nd link below)

tigerjack · 2024-03-30 15:36:12

seth wrote:

https://wiki.archlinux.org/title/NVIDIA#Installation
You only have to
a) install the nvidia drivers (don't conduct a partial update, they've to match the installed kernel!)
b) remove the kms hook and regenerate the initramfs (though the latter alone will include the blacklist if you've the modprobe hook active)
You cannot really break the system this way to the point where it becomes unbootable, the multi-user.target in doubt along "nomodeset" will still work (2nd link below)

Thanks for your help seth!

The thing is, I have an intel+nvidia configuration, so I think I should rely on nvidia prime technology, and I don't know how stable it is.

But anyway I will repeat the steps here to check if I understood everything correctly. Please correct me if I'm wrong.
a. Install nvidia

pacman -S nvidia-prime nvidia-utils

b. modify the /usr/lib/initcpio/install/kms file, changing this line

    map add_checked_modules '/drivers/char/agp/' '/drivers/gpu/drm/'

to this

    map add_checked_modules '/drivers/char/agp/' # '/drivers/gpu/drm/'

c. Regenerate (all) the initramfs through

mkinitcpio -P

seth · 2024-03-30 16:29:54

pacman -S nvidia-prime nvidia-utils

You'll still need the kernel package (nvidia, nvidia-lts or nvidia-dkms; the latter builds modules for whatever kernel you run, but you need the kernel headers, eg. linux-headers)

uname -a

modify the /usr/lib/initcpio/install/kms file

You're not touching anything in /usr/lib, young man
/etc/mkinitcpio.conf - you'll findthe HOOKS array there, remove the kms one

tigerjack · 2024-04-02 14:45:09

seth wrote:

You're not touching anything in /usr/lib, young man
/etc/mkinitcpio.conf - you'll findthe HOOKS array there, remove the kms one

ok ok, I will try not to.
What about the other value /drivers/char/agp/ inside kms?

seth wrote:

You'll still need the kernel package (nvidia, nvidia-lts or nvidia-dkms; the latter builds modules for whatever kernel you run, but you need the kernel headers, eg. linux-headers)

I used nvidia-dkms since I have the kernel headers.

I confirm that, once done, there was no problem during boot.
However, I had problems in launching sway, that now should have the --unsupported-gpu option.

From the wiki, I read

Note: All proprietary graphics drivers are not supported, including NVIDIA. After NVIDIA driver version 495, sway works if you enable kernel mode setting and run sway with --unsupported-gpu.

and the kernel mode setting page suggests to enable nvidia_drm.modeset=1

What is the suggested way to do it? Is this option still valid when using intel+NVIDIA gpu?

EDIT: Judging from the FPS, the Nvidia is working. However, I am not sure that the error message is insignificant

>glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
144 frames in 5.0 seconds = 28.783 FPS

>DRI_PRIME=1 glxgears
glx: failed to create dri3 screen
failed to load driver: nouveau
1133 frames in 5.0 seconds = 226.581 FPS

Last edited by tigerjack (2024-04-02 14:47:57)

seth · 2024-04-02 21:16:10

What about the other value /drivers/char/agp/ inside kms?

You don't have to and should not edit anything there.

I confirm that, once done, there was no problem during boot.

\o/

However, I had problems in launching sway, that now should have the --unsupported-gpu option.

That sounds worse than it is and is mostly legacy because nvidia originally didn't support GBM but pushed their eglstreams API.
The sway author might still be a bit sulky - but there's no real difference between nvidia and the mesa drivers itr

and the kernel mode setting page suggests to enable nvidia_drm.modeset=1

The setting is mandatory for wayland and on the kernel commandline will also rid you of the simpledrm device (so you're not accidentally running in software)

failed to load driver: nouveau

Try https://wiki.archlinux.org/title/PRIME# … figuration - https://archlinux.org/packages/?name=nvidia-prime should achieve the same

In case and please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Arch Linux

#1 2024-03-29 08:01:08

[SOLVED] udev error during boot

#2 2024-03-29 10:00:14

Re: [SOLVED] udev error during boot

#3 2024-03-29 10:17:21

Re: [SOLVED] udev error during boot

#4 2024-03-29 10:29:07

Re: [SOLVED] udev error during boot

#5 2024-03-29 10:34:56

Re: [SOLVED] udev error during boot

#6 2024-03-29 12:42:08

Re: [SOLVED] udev error during boot

#7 2024-03-29 14:02:17

Re: [SOLVED] udev error during boot

#8 2024-03-29 15:37:47

Re: [SOLVED] udev error during boot

#9 2024-03-29 17:55:37

Re: [SOLVED] udev error during boot

#10 2024-03-29 18:02:21

Re: [SOLVED] udev error during boot

#11 2024-03-29 18:05:42

Re: [SOLVED] udev error during boot

#12 2024-03-29 21:47:08

Re: [SOLVED] udev error during boot

#13 2024-03-30 13:13:12

Re: [SOLVED] udev error during boot

#14 2024-03-30 15:28:01

Re: [SOLVED] udev error during boot

#15 2024-03-30 15:36:12

Re: [SOLVED] udev error during boot

#16 2024-03-30 16:29:54

Re: [SOLVED] udev error during boot

#17 2024-04-02 14:45:09

Re: [SOLVED] udev error during boot

#18 2024-04-02 21:16:10

Re: [SOLVED] udev error during boot

Board footer