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.
I misunderstood your report then. From now on I’ll assume we
eliminated the possibility, that this is something happening regardless
of copying.
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. (…)
If either udevd or a program invoked by udevd try to read from the
USB stick at the same time writing happens, I suppose this could happen.
Hypothetically. I never encountered blocking like that. At least some
reads should be scheduled between writes. I also searched the web for
possibly relevant issues and can’t see such mentions.
This explanation would be good, though. It would only indicate a
benign failure, not affecting the data.
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?
Everything around the same time the error is triggered.
I didn’t think of that earlier, but `udevadm monitor` run in another
console may be less spammy. Observe it during the situation. Again,
anything pointing to what udev activity happens would be useful for
debugging.
