Ok so in fact the inconsistency is due to "parted" that will try to
probe devices iff the given block device return informations from
stat(), regardless if the block device is available or not.
Seems like the only trigger/criteria is the stat() return. Since the
loop device stat doesn't clear/reset once umounted/detacted, then parted
assume it can go ahead and probe it assuming it is a legit device.
----
# libparted/arch/linux.c
----
618 static int
619 _device_stat (PedDevice* dev, struct stat * dev_stat)
620 {
621 PED_ASSERT (dev != NULL);
622 PED_ASSERT (!dev->external_mode);
623
624 while (1) {
625 if (!stat (dev->path, dev_stat)) {
626 return 1;
627 } else {
628 if (ped_exception_throw (
629 PED_EXCEPTION_ERROR,
630 PED_EXCEPTION_RETRY_CANCEL,
631 _("Could not stat device %s - %s."),
632 dev->path,
633 strerror (errno))
634 != PED_EXCEPTION_RETRY)
635 return 0;
636 }
637 }
638 }
----
Example:
----
# parted -s $(losetup -f) unit s print
Warning: Error fsyncing/closing /dev/loop18: Input/output error
# stat $(losetup -f)
File: /dev/loop18
Size: 0 Blocks: 0 IO Block: 4096 block special file
Device: 6h/6d Inode: 509 Links: 1 Device type: 7,12
Access: (0660/brw-rw----) Uid: ( 0/ root) Gid: ( 6/ disk)
Access: 2019-12-25 13:05:15.543108777 -0500
Modify: 2019-12-25 13:05:15.543108777 -0500
Change: 2019-12-25 13:05:15.543108777 -0500
Birth: -
# parted -s /dev/loop19 unit s print
Error: Could not stat device /dev/loop19 - No such file or directory.
# stat /dev/loop19
stat: cannot stat '/dev/loop19': No such file or directory
----
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1856871
Title:
i/o error if next unused loop device is queried
Status in linux package in Ubuntu:
Incomplete
Status in snapd package in Ubuntu:
Invalid
Status in systemd package in Ubuntu:
New
Status in udev package in Ubuntu:
New
Bug description:
This is reproducible in Bionic and late.
Here's an example running 'focal':
$ lsb_release -cs
focal
$ uname -r
5.3.0-24-generic
The error is:
blk_update_request: I/O error, dev loop2, sector 0
and on more recent kernel:
kernel: [18135.185709] blk_update_request: I/O error, dev loop18,
sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
How to trigger it:
$ sosreport -o block
or more precisely the cmd causing the situation inside the block plugin:
$ parted -s $(losetup -f) unit s print
https://github.com/sosreport/sos/blob/master/sos/plugins/block.py#L52
but if I run it on the next next unused loop device, in this case
/dev/loop3 (which is also unused), no errors.
While I agree that sosreport shouldn't query unused loop devices,
there is definitely something going on with the next unused loop
device.
What is differentiate loop2 and loop3 and any other unused ones ?
3 things so far I have noticed:
* loop2 is the next unused loop device (losetup -f)
* A reboot is needed (if some loop modification (snap install, mount loop,
...) has been made at runtime
* I have also noticed that loop2 (or whatever the next unused one is) have
some stat as oppose to other unused loop devices. The stat exist already right
after the system boot for the next unused loop device.
/sys/block/loop2/stat
::::::::::::::
2 0 10 0 1 0 0 0 0 0 0
2 = number of read I/Os processed
10 = number of sectors read
1 = number of write I/Os processed
Explanation of each column:
https://www.kernel.org/doc/html/latest/block/stat.html
while /dev/loop3 doesn't
/sys/block/loop3/stat
::::::::::::::
0 0 0 0 0 0 0 0 0 0 0
Which tells me that something during the boot process most likely
acquired (on purpose or not) the next unused loop and possibly didn't
released it well enough.
If loop2 is generating errors, and I install a snap, the snap squashfs
will take loop2, making loop3 the next unused loop device.
If I query loop3 with 'parted' right after, no errors.
If I reboot, and query loop3 again, then no I'll have an error.
To triggers the errors it need to be after a reboot and it only impact
the first unused loop device available (losetup -f).
This was tested with focal/systemd whic his very close to latest
upstream code.
This has been test with latest v5.5 mainline kernel as well.
For now, I don't think it's a kernel problem, I'm more thinking of a
userspace misbehaviour dealing with loop device (or block device) at
boot.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856871/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
