Re: hang on bootstrap

[Justus Winter]

Hi :)

Quoting Riccardo Mottola (2014-09-08 22:30:12)
> after the last udpate (I admit, a couple of weeks ago before the holiday 
> season) which was apparently successful, my system doesn't boot anymore.
> 
> I get:
> 
> <...>
> start ext2fs: ext2fs: device:hd0s1: warning: FILESYSTEM NOT UNMOUNTED 
> CLEANLY; PLEASE fsck
> Hurd server bootstrap: ext2fs[device:hd0s1] exec
> 
> And here it hangs forever, no disk activity, nothing (although 
> eventually the screen will blank)
> 
> I then tried to enter GRUB and use the "recovery mode" ( is this the new 
> wording for single-user?)

Yes.  This will append '-s' to the kernel command line, which well
eventually get passed to sysvinit.  It will then do the same thing as
Debian/Linux:

Using makefile-style concurrent boot in runlevel S.
[...]
Cleaning up temporary files....
Press enter for maintenance(or type Control-D to continue):
root@debian:~# uname -a
GNU debian 0.5 GNU-Mach 1.4-486/Hurd-0.5 i686-AT386 GNU

Yay sysvinit :)

> The output changes, but hangs in the same place:
> 
> <...>
> start ext2fs: ext2fs: device:hd0s1: warning: FILESYSTEM NOT UNMOUNTED 
> CLEANLY; PLEASE fsck
> ext2fs: device:hd0s1: warning: MOUNTED READ-ONLY; MUST USE 'fsysopts 
> ''writable'
> Hurd server bootstrap: ext2fs[device:hd0s1] exec

It's funny that you get a different output...

> What is happening? is ext2fs server haning because my filesystem wasn't 
> cleanly unmounted? It would be nice to get at least in single-user and 
> run fsck!

I'm afraid that at this point in the Hurd bootstrap, if either of
ext2fs or exec dies, nothing will be displayed.

If you are running a debug kernel (and you should), you can break into
the kernel debugger using ctrl-alt-d and do:

^D
Stopped at  0x801000be: leave
db> show all threads
    TASK        THREADS
  0 gnumach (a0895f00): 8 threads:
[...]
  1 ext2fs (a0895e40): 16 threads:
[...]
  2 exec (a0895d80): 4 threads:
[...]
  3 a0895cc0 (a0895cc0): (a08c3548) .W.O.F(0x8014d850) 0
  4 a0895c00 (a0895c00): 3 threads:
[...]
  5 a0895b40 (a0895b40): 4 threads:
[...]
  6 /bin/sh(1) (a0895a80): 2 threads:

3 is /hurd/init, which I guess isn't even run on your systems.

To recover from this, use a Hurd live CD (I guess the Debian installer
CD will do), or even a random Debian/Linux live CD.  Run fsck on your
root filesystem.  If that doesn't help, some important files might
have been corrupted.  You could then try reinstalling the hurd,
hurd-libs, and libc0.3 packages.  This is doable even from Linux
(mount your rootfs using mount -t ext2 /dev/your/root /mnt, use
dpkg-deb --extract hurd.deb /mnt).

To prevent this in the future, regularly run touch /forcefsck to force
a fsck on your filesystems.  There is a known problem in ext2fs
affecting root filesystem translators, deleted inodes with zero dtime
are accumulating until no free inodes are left.

Good luck :)
Justus