111–120 of 138 posts
Have any guidelines been posted somewhere for systems already updated to linux-image-amd64 6.1.64-1?
Here's my understanding so far: In the upstream Linux kernel there were two fixes posted months from each other, one for direct io [0] and the other one for ext4 [1]. The ext4 one was marked for backport to stable (CC: stable@vger.kernel.org), the other was not. The problem is that these commits depend on each other for things to work properly. If you have both, you're fine. If you have only the backported one, you h…
As someone who is heavily dependent on zfs, this is a little bit of reassurance. Sad that data corruption exists in any file system that is shipped too many people, but reassuring that it happens to the most stable and least "interesting" in the newness sense file systems. ZFS's own recent file system corruption issue is in roughly the same category of edge case, but accessible to reasonable if niche workloads.
Combine ext4's dumb but robust approach to journaling and robust metadata layout (for example inodes are statically allocated) with fsck.ext4 (which got refined for years) and you can recover from any situation.
To give you an example, fsck.ext4 will happily carve a working filesystem out of random data, as long as there is a valid superblock. Seriously - try it yourself:
# create a working filesystem image
dd if=/dev/zero of=test1.img bs=1M count=256
/sbin/mkfs.ext4 test1.img
# write file with random data
dd if=/dev/urandom of=test2.img bs=1M count=256
# copy superblock into random file
dd if=test1.img of=test2.img bs=1024 count=4 seek=1 skip=1 conv=notrunc
/sbin/fsck.ext4 -fy test2.img
sudo mount test2.img /mnt/somewhereWhy wasn't automatic updating to this halted immediately? The "grave" bug report was yesterday, but today unattended-upgrades updated me to the affected kernel and I restarted before I heard about the problem.
If this all seems archaic, keep in mind that all this has been designed 20+ years ago, when bandwidth was quite a bit less abundant.
Why wasn't automatic updating to this halted immediately? The "grave" bug report was yesterday, but today unattended-upgrades updated me to the affected kernel and I restarted before I heard about the problem.
I found a few things surprising about this bug too, but this might be due to my own ignorance about how these processes work: - I was expecting the package to either be revoked, or to have a new `6.1.64-2` version being published with the previously good known state. Maybe it wasn't done because it was not possible (mirrors being write-only, and maybe other complications in publishing a 6.1.64-2). - I was expecting s…
Earlier quoted context omitted.
If they are, then that's why the quality is declining.
Funny. You don't even know if that's the case, but somehow you know it's the cause?
In Debian bookworm: "sudo systemctl stop unattended-upgrades.service" ... wasn't able to prevent unattended-upgrades from going on ahead and just upgrading (to this problematic kernel) anyway. Unintuitively, the "right" way to disable unattended-upgrades is: "sudo dpkg-reconfigure unattended-upgrades" ...and choose "No" when asked.
Most likley because you stopped the wrong service. You should have stopped the relevant timer service, not the service that the timer starts.
FTFY. Helps keeping them apart to not use the same word for both ;)
systemctl disable --now unattended-upgrades.timer;
systemctl disable --now unattended-upgrades.service
Here's my understanding so far: In the upstream Linux kernel there were two fixes posted months from each other, one for direct io [0] and the other one for ext4 [1]. The ext4 one was marked for backport to stable (CC: stable@vger.kernel.org), the other was not. The problem is that these commits depend on each other for things to work properly. If you have both, you're fine. If you have only the backported one, you h…
Were any Ubuntu versions affected?
In Debian bookworm: "sudo systemctl stop unattended-upgrades.service" ... wasn't able to prevent unattended-upgrades from going on ahead and just upgrading (to this problematic kernel) anyway. Unintuitively, the "right" way to disable unattended-upgrades is: "sudo dpkg-reconfigure unattended-upgrades" ...and choose "No" when asked.
systemctl stop is a oneshot operation, right? Perhaps sudo apt remove unattended-upgrades?
Here's my understanding so far: In the upstream Linux kernel there were two fixes posted months from each other, one for direct io [0] and the other one for ext4 [1]. The ext4 one was marked for backport to stable (CC: stable@vger.kernel.org), the other was not. The problem is that these commits depend on each other for things to work properly. If you have both, you're fine. If you have only the backported one, you h…