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
