| 22 Mar 2025 |
 @elvishjerricco:matrix.org | the device appears, satisfying some dependencies, and then disappears, which causes job cancellations because of BindsTo=dev-foo.device | 09:17:42 |
| @elvishjerricco:matrix.org | and then reappears, but then it's too late and damage is done | 09:18:07 |
 Arian | Could it be a kernel bug? | 09:18:20 |
| Arian | Why is the kernel sending uevents on resize | 09:18:30 |
| @elvishjerricco:matrix.org | is it not normal for a device's partitions to be removed and added from udev's perspective when the device is partscanned? | 09:19:01 |
| Arian | Well you just said it's possible to resize a partition that is mounted. In that case it doesn't sound like sane behaviour that the underlying device would disappear and appear no | 09:19:50 |
| Arian | That makes 0 sense to me | 09:20:04 |
| Arian | Ah yeh we use online resize for cloud images etc. I remember now | 09:21:28 |
| @elvishjerricco:matrix.org | after repart finishes, I see Changed plugged -> dead for each of the partitions in the systemd debug logging, and then immediately after I see Changed dead -> plugged for them | 09:23:12 |
| @elvishjerricco:matrix.org | vda3: Processing udev action (SEQNUM=1400, ACTION=remove)
then I get a
vda: Processing udev action (SEQNUM=1401, ACTION=change)
And then I get
vda3: Processing udev action (SEQNUM=1404, ACTION=add)
| 09:23:57 |
| @elvishjerricco:matrix.org | * vda3: Processing udev action (SEQNUM=1400, ACTION=remove)
then I get a
vda: Processing udev action (SEQNUM=1401, ACTION=change)
And then I get
vda3: Processing udev action (SEQNUM=1404, ACTION=add)
| 09:24:15 |
| @elvishjerricco:matrix.org | I feel like this can't possibly be right, because then imagine what happens with a normal stage 2 repart service. It would repartition, and immediately cancel all mount jobs depending on those partitions, stopping local-fs.target | 09:26:43 |
| Arian | Is Dev/vda3 mounted at this point? | 09:27:35 |
| @elvishjerricco:matrix.org | no | 09:27:41 |
