bug-hurd
[Top][All Lists]
Advanced

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

Re: hang on bootstrap


From: Riccardo Mottola
Subject: Re: hang on bootstrap
Date: Mon, 15 Sep 2014 10:27:50 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29

Hi,

Justus Winter wrote:
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...
funny is a bit sarcastic here, right?


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:
I'll check, to be honest, I just leave aptitude install and update.
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).
I used a live-cd and did run fsck on both filesystems (I have / and /home separate since when I reinstalled, so at least HURD doesn't mess up my personal data...) Sadly it still hangs at boot. This means I need to try to recover. I'll try your procedure. If I am lucky the .deb files are still on the same partition.

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.
Indeed, running fsck found a lot of "inodes with zero dtime" to fix. Looks something nice to fix :)

Riccardo



reply via email to

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