Samuel Thibault, le mar. 08 août 2023 19:15:50 +0200, a ecrit: > The issue I'm still seeing now is that I cannot get to install some > packages, such as libicu72. When I pass it as extra package to > debootstrap, it does get installed, but when I "dpkg -i" it by hand, > things halt.
It seems that the most common case is that rumpdisk gets stuck. I guess we have e.g. a lost interrupt which makes rumpdisk endlessly wait for termination of a write. We can avoid this issue by using a ramdisk. Another case seems like a four-players issue. - one ext2fs thread is doing diskfs_S_file_syncfs, it's stuck inside the helper calling fsys_syncfs on some other translator and it holds the translator_ihash_lock lock - one ext2fs thread is trying to call fshelp_set_active_translator from dir_lookup. It is stuck on trying to acquire translator_ihash_lock, and it holds the np. - one ext2fs thread doing the diskfs_sync_everything, stuck in diskfs_node_iterate trying to lock a node, while holding the nodecache_lock. So in the end nodecache_lock is stuck just because some translator is stuck on fsys_syncfs. It's unfortunate that we had never seen that before and it's appearing now at the worst time for the hurd-amd64 bootstrap :) We can avoid this issue by using eatmydata, to prevent dpkg from running syncs. Samuel