resource-agents 1:4.16.0-3ubuntu1 autopkgtests fail on questing [dd direct write flag]

Looking at the error, the problem lies in the Filesystem agent. There are some monitoring functions being tested, and the one which fails is a check which reads the starting bytes of a device.

This is done using `dd`. This is the exact command executed in the test:
dd if=/dev/loop0 iflag=direct bs=4k count=1 2>&1 >/dev/null

The first smell is: this passes with `coreutils-from-gnu`, but fails with `coreutils-from-uutils` with:
`dd: IO error: Invalid input`

strace shows that dd can't read from the FD:
`read(3, 0x5d3c457b94a0, 4096) = -1 EINVAL (Invalid argument)`

It seems the rust coreutils can't deal with the `direct` flag appropriately [1]. The implementation of O_DIRECT seems different than the one in the GNU version - and it seems to lack buffer alignment, which is needed for direct reads.

In the resource-agents side, a workaround would be removing the iflag from the `dd` call. However, the commit which introduces the flag (tens of years ago) states: "Reading from the device in O_DIRECT mode is imperative to bypass caches.", so that's not acceptable for the monitoring functionality.

So this needs to be looked at in the coreutils side. I am adding bug tasks.

For the package migrations blocked on this bug, I suggest adding hints so they get in. As a last resort, migration-reference is also a workaround for now.

Mind that many other packages (or at least package tests) also call/depend on the `direct` iflag, and are potentially affected by this coreutils bug.

---
Steps to reproduce:

1. Launch a questing VM with coreutils-from-uutils
2. Create a file which will be mapped to loop0:
$ sudo dd if=/dev/zero of=/example bs=1 count=0 seek=16M
Make sure to not create it in a tmpfs, as this is a different scenario - also not supported in the rust coreutils[1]
3. Map loop0 to the file:
$ sudo losetup /dev/loop0 /example
4. Try to read the data without using the `direct` iflag, see it works:
sudo dd if=/dev/loop0 bs=4k count=1
5. Try to read the data using the `direct` iflag, see it fails:
sudo dd if=/dev/loop0 iflag=direct bs=4k count=1

6. Launch a questing VM with coreutils-from-gnu
7. Repeat steps 2 to 4
8. Repeat step 5, but this time it works

---
[1] https://users.rust-lang.org/t/how-does-rust-use-directio/93210

Hello Julian,

I'd like to know the rationale for marking this particular issue as won't fix. The 'direct' flag on dd is important to more users I think, and this is breaking resource-agents functionality.

Could you please weigh in?

The `coreutils-from` task designates whether the `dd` binary gets redirected to gnudd as a workaround, whereas the `rust-coreutils` task is about fixing it.

Ack, makes sense; thanks for the clarification (:

Setting this to Critical as Christian have done for the coreutils-from task before

Reported upstream, though on Ubuntu 26.04, and without resource-agents involvement: https://github.com/uutils/coreutils/issues/12085

I believe this is triggered far more widely than described here. For example, we reproduced this in the DRBD test suite.

I suspect many users are using similar dd calls in their scripts, since this expression is a pretty common pattern when testing with block devices.