Hi Friedrich, while you're likely much better versed in your goals than what I likely know how to do I couldn't help but ponder what exactly you're trying to accomplish by copying the ISO to the seemingly unpartitioned hard disk /dev/sda, if I've followed along correctly. *> which I encountered during copying this ISO image over.* If you were trying to write the ISO as-is for bootable reuse wouldn't you use DD to write the image as it stands? Otherwise if keeping the ISO as an ISO was your goal wouldn't you need to create a basic partition table, mount the partition (ie /dev/sda1 to /mnt) then *cp archlinux.iso /mnt* ? Apologies if I've misread, you've sparked my genuine curiosity with the path you've chosen. Thanks, Sean On Tue, Apr 22, 2025 at 12:24 PM Friedrich Romstedt < friedrichromstedt@gmail.com> wrote:
Hi mpan,
Am Mo., 21. Apr. 2025 um 23:51 Uhr schrieb mpan <archml-y1vf3axu@mpan.pl>:
(…) This is about some error entries in the system journal, which I
encountered
during copying this ISO image over. The respective transcripts are provided inline, as well as attached in the form of plain text files. (…) I believe this is unrelated to the copying process.
Actually, I am certain that the behaviour was triggered by the copying process, as the log journal entries were reproducible by repeating the installation for a second time.
udevd stopped responding for `WatchdogSec` seconds,⁽¹⁾ systemd restarted it. This kind of reports are usually associated with some specific piece of hardware leading to udevd lock-up, and no less often the bug is resolved in later kernel releases.
The logs indicate some failed attempts to SIGABRT and then SIGKILL. Shortly after the completion of the operation (when the kernel emits sda: sda1 sda2), a log:
systemd-udevd.service: Main process exited, code=killed, status=9/KILL
can be spotted. Thus it is rather clear that the error is truly related to the ISO image installation to sda.
Possibly the USB stick leads to such a kind of lock-up as you mentioned, while the copying process is underway? The actual copying procedure completed successfully.
You may try passing `udev.log_level=debug` to kernel command-line during boot. See if that produces any useful info, but also note that this log level is very spammy.
Hm, what should I look for?
Best, Friedrich