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 < friedrichromst...@gmail.com> wrote: > > Hi mpan, > > Am Mo., 21. Apr. 2025 um 23:51 Uhr schrieb mpan <archml-y1vf3...@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
