[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 64bit startup

From: Samuel Thibault
Subject: Re: 64bit startup
Date: Thu, 10 Aug 2023 00:07:53 +0200
User-agent: NeoMutt/20170609 (1.8.3)

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]