You are not logged in.
I issued a sync command while performing a system upgrade. The system was updating the kernel. (more exactly it was performing the hooks after the kernel upgrade: updating modules dependencies, etc.). This led to a deeply corrupted system while the root filesystem was reported as read only by the kernel; after having hanged for some time. After a reboot, I was forced to issue a "fsck -y" to repair the errors (I had a message saying that "please run fsck manually"). After that, some of the files, including the kernel, that the system was updating appeared to be empty and the corresponding pacman database was corrupted (invalid mtree). I eventually reinstall them with the "--force" option from a boot disk. Now everything seems to work again...
Is that expected? Normal? I thought sync should be pretty innocent. I certainly didn't expect that it could corrupt the system.
I have a new SSD that otherwise seems to work reliably. I use the lts kernel.
Last edited by olive (2019-02-07 10:16:02)
Offline
sync - Synchronize cached writes to persistent storage
sounds like the sync operation interfered with the upgrade writing changed data.
What was the exact command you used and what type of filesystem where you running it on ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
I use an ext4 filesystem. The exact command was just "sync" during "pacman -Syu".
I usually issue a sync command after an upgrade and before rebooting after a system upgrade, to be sure the files are OK in case of a problem while rebooting (that can append if we update systemd). This time I issued the sync command too early, before pacman finished. Anyway, I thought 'sync' should be innocent. Look like a bug of some sort.
Offline
Wild guess, output of "mount"?
Offline