>
> Sur 19 juin 2026 à 17 h 45, Martin-Éric Racine <[email protected]>
> a écrit :
>
>
> ma 15.6.2026 klo 0.43 Samuel Thibault ([email protected]) kirjoitti:
> >
> > Martin-Éric Racine, le sam. 13 juin 2026 11:36:48 +0300, a ecrit:
> > > su 7.6.2026 klo 18.38 Samuel Thibault ([email protected])
> > kirjoitti:
> > > > Martin-Éric Racine, le sam. 06 juin 2026 10:48:17 +0300, a ecrit:
> > > > > The Debian host on which I test Hurd is dual-boot
> > (Linux/Testing,
> > > > > Hurd/Unstable). Running 'apt-get update' takes about one
> > minute on
> > > > > Linux, but a full hour on Hurd.
> > > >
> > > > That's not happening here at all, and there is no reason why it
> > should
> > > > be *that* long.
> > > >
> > > > We'd need **way** more details about your setup and observations
> > to be
> > > > able to provide any insight as in why it is happening so on your
> > box.
> > > > Otherwise you are just asking for divination.
> > >
> > > What else do you need?
> >
> > For trivial starters, whether you are running natively or within a VM
> > (with hardware acceleration or not?), what step exactly is taking so
> > long (e.g. is that the download that takes long or the "Reading package
> > lists" step), and what shows up in top: is cpu time being eating, by
> > which process, etc.
>
> I already said a dual-boot host, so it should be obvious that it's
> running natively on real x86 hardware.
>
> 'sudo apt-get update' is taking 2 minutes tops to complete when
> booting off the Linux partition, but a whole hour when booting off the
> Hurd partition.
>
> If you could past /proc/cpu
> Or same...
>
> Without log is very difficult to help you
>
> Maybe you pass by an mount FS to retrieve log
>
>
> Martin-Éric
>
>
> Kinds regards
