I ran the above test:
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-dannf-test/jammy/amd64/l/livecd-rootfs/20240123_035147_6470b@/log.gz
It does appear that systemd-udevd is trying to scan partitions at the
same time as losetup:
1599s ++ losetup --show -f -P -v
I ran into this on jammy/amd64:
https://autopkgtest.ubuntu.com/results/autopkgtest-
jammy/jammy/amd64/l/livecd-rootfs/20240121_173406_e4f9a@/log.gz
I downloaded all of the amd64 failures and searched for this failure
pattern. These were the kernels that were running at the time:
"Linux
> Is only asking kernel to scan the device; to then generate "kernel udev"
> events; for then udev to wakeup and process/emit "udev udev" events; and
> create the required device nodes.
>
It's not udev that creates nodes like /dev/loop1p1 though is it? That's
devtmpfs surely.
--
You received
I don't have a good explanation, but in the past I've "fixed" such races
by adding a `sync "$loop_device"` before using any of the newly created
partitons. Maybe it's worth trying.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
my expectation is that udev should be running (somewhere, not sure if it
needs to be both the host and the lxd guest) and that it should process
the device using locks https://systemd.io/BLOCK_DEVICE_LOCKING/.
After that is done, the device should be safe to operate on, in a
consistent manner.
Oh. To the question of whether there was a systemd change in this
window: yes absolutely, because this is the point at which the riscv64
builders moved from lgw manually-operated qemu with a 20.04 guest image,
to bos03 openstack-operated qemu with a 22.04 guest image.
Which is also why we've
On Sat, Dec 09, 2023 at 05:13:28PM -, Andy Whitcroft wrote:
> Was there any systemd/udev change in this timeframe? As the device
> files are very much connected to those.
My understanding is that these devices are supposed to be created directly
by the kernel on devtmpfs and NOT via udev,
Was there any systemd/udev change in this timeframe? As the device
files are very much connected to those.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045586
Title:
livecd-rootfs
https://launchpad.net/~ubuntu-
cdimage/+livefs/ubuntu/noble/cpc/+build/544490 is a log from a build
with a new livecd-rootfs that spits out more debugging info on failure.
+ sgdisk binary/boot/disk-uefi.ext4 --print
Disk binary/boot/disk-uefi.ext4: 9437184 sectors, 4.5 GiB
Sector size (logical):
Failing build had kernel
Kernel version: Linux bos03-riscv64-014 5.19.0-1021-generic
#23~22.04.1-Ubuntu SMP Thu Jun 22 12:49:35 UTC 2023 riscv64
The build immediately before the first failure had kernel
Kernel version: Linux riscv64-qemu-lgw01-069 5.13.0-1019-generic
#21~20.04.1-Ubuntu SMP Thu
November 16 was 2 days after livecd-rootfs 24.04.4 landed in the noble
release pocket, superseding 24.04.2.
The code delta between 24.04.2 and 24.04.4 includes removal of support
for "legacy" images (SUBPROJECT=legacy) which doesn't apply here; and
some reorganization of code related to
11 matches
Mail list logo
