Re: Everything's broken (was: Debian GNU/Hurd 2023 released!)

[Sergey Bugaev]

On Wed, Jun 14, 2023 at 4:14 PM Samuel Thibault <samuel.thibault@gnu.org> wrote:
> ?? I'm not getting such a result at all of course. How did you run the
> installation *exactly*?

The image I downloaded was debian-sid-hurd-i386-NETINST-1.iso from [0]

[0]: 
https://cdimage.debian.org/cdimage/ports/hurd-i386/12.0/debian-sid-hurd-i386-NETINST-1.iso

I tried two configurations: in VirtualBox 7.0.8 on a Windows 10 host,
and in QEMU 7.2.1 on a GNU/Linux host. Both reproduced the issue. The
qemu command line I used was

$ qemu-img create -f qcow2 debian-hurd-2023.qcow2 100G
$ qemu-system-i386 -m 1G -hda debian-hurd-2023.qcow2 -cdrom
debian-sid-hurd-i386-NETINST-1.iso -enable-kvm

I picked the "Pseudo-graphical install" (which is the default) and
left most options at their defaults too. The default "guided setup"
split my 100 GB drive into two partitions, an ext2 one for the root
and a swap one. I installed GRUB onto the same drive.

Please tell me if you need even more details, such as what exact
choices I made at each particular screen. I could even record a video.

> As a reminder, the really recommended way to avoid issues is to just run
> the pre-installed image inside qemu (and README files are actually meant
> to be read).

Is there any reason to assume that I (or those other people) have not
read the readme?

It does say "To give Debian GNU/Hurd a try, it is probably easier to
simply run the preinstalled image", not "it is really recommended to
use the preinstalled image, since the system you get after using the
installer doesn't boot". People certainly have their reasons why they
want to install the system from scratch.

Rather than blaming it on the users, let's fix the bug.

> > I've seen people on a certain online forum report this,
> > and draw a rather negative conclusion about the state of the Hurd.
>
> As usual, we see a lot of people grumble about things, much less people
> actually report things, and even less people actually have a look at
> fixing things...

I share the opinion that things aren't magically going to fix
themselves and people need to actively make things work if they want
to see them working (this is what I tell everyone who asks whether
their favorite app runs on Darling: it's not going to run unless you
put in the work to make it run). But also not everyone is interested
enough in Hurd internals to participate, and releasing a broken image
is not going to go a long way towards getting more people excited
about the Hurd.

Anyway, I am here, reporting things, and trying to fix them when I
can. (And actually wondering whether you're all tired of me already.)

> And most people just forgetting that it's just the same with *any*
> OS that doesn't have a huge testing team. Any departure from what is
> actually tested will get issues, very obviously. One just can't test the
> whole world of virtualfoo etc.

Well, if there was, say, a call for pre-release testing, I could have
reported this before the release, and we'd have figured it out in
time.

But it's also not like I'm doing something weird by just installing
the provided ISO with mostly default settings... one would think that
this would get tested.

> > # ls /dev/tty1
> > ls: cannot access '/dev/tty1': No such file or directory
> >
> > # ls /dev
> > ls: reading directory '/dev': Input/output error
>
> This looks like filesystem corruption. Did you try to fsck it?

fsck says that the fs was cleanly unmounted... but if I -f it, then
indeed it reports 'directory corrupted', and the inode number
corresponds to /dev.

So the installed system is not to blame, it must be that the installer
is corrupting the FS somehow.

For what it's worth, after the installer is done installing and right
before shutting down, /dev and /dev/tty1 appear just fine, at least as
far as the active translator on /target knows.

> > I can't debug this properly myself because of the issue with GDB and
> > debuginfo I was talking about earlier: GDB (I've tried GDB 13.1 from
> > Fedora and 10.1 from Debian bullseye) just doesn't "see" the (DWARF?)
> > debuginfo in the .debug files extracted from the dbgsym debs.
>
> Are you running a Linux gdb for a Hurd binary? I don't know if that's
> supposed to work.

I am. I think it is supposed to work -- it's just ELFs. Well, GDB does
complain, saying "warning: A handler for the OS ABI "GNU/Hurd" is not
built into this configuration of GDB.  Attempting to continue with the
default i386 settings.", but this never seemed to really break
anything. This is how I've been using GDB to debug things (64-bit
startup) this whole time, and it has always worked, both with binaries
I build locally, and with debuginfo downloaded from your/Debian
builds. Until about a week and a half ago when the latter suddenly
stopped working.

I'm not using gnu_nat_target or anything like that; I'm using GDB for
symbolication and disassembly (this can be done without running the
binary in any way), and for debugging the whole system (qemu -s +
target remote :1234).

But that being said, GDB 13.1 on my other Hurd VM does see the
debuginfo. And I have just checked with older Hurd packages from the
Debian archive, and my host's GDB can't see the debuginfo there
either, so it's not a change in Debian that has broken things. You'd
think that I must have updated GDB at about the same time that it
stopped working, but no, package history says that I have not, and
just to be sure I just rolled back GDB to an older version and it
still doesn't work.

I don't know what's going on; but I'm sure that I have successfully
used debuginfo files from your Debian packages before, very recently,
and it has worked. And it sure still does work for the binaries I
build locally:

$ gdb -q ~/dev/crosshurd/src/hurd/build/ext2fs/ext2fs.static

warning: A handler for the OS ABI "GNU/Hurd" is not built into this
configuration
of GDB.  Attempting to continue with the default i386 settings.

Reading symbols from
/home/sergey/dev/crosshurd/src/hurd/build/ext2fs/ext2fs.static...
(gdb) l main
225  error_t err;
226  mach_port_t bootstrap;
227
228  /* Initialize the diskfs library, parse arguments, and open the store.
229     This starts the first diskfs thread for us.  */
230  store = diskfs_init_main (&startup_argp, argc, argv,
231    &store_parsed, &bootstrap);
232
233  if (store->size < SBLOCK_OFFS + SBLOCK_SIZE)
234    ext2_panic ("device too small for superblock (%" PRIi64 "
bytes)", store->size);

Sergey