bug-hurd
[Top][All Lists]
Advanced

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

ext2fs stability (in vm?)


From: Andrew Engelbrecht
Subject: ext2fs stability (in vm?)
Date: Wed, 06 Apr 2011 17:09:20 -0400

Have you tried running fsck on the disk image? It won't solve any ext2fs
server instability, but it should give you another shot at starting up.
The only trick is doing it outside of qemu, since your system isn't
booting up. Also, it's somewhat more complicated because it has multiple
partitions.

Here's what worked for me, using hd0.img:

#  stop any loop device usage:
losetup -d /dev/loop*
#  again for good measure:
losetup -d /dev/loop*

rmmod loop
modprobe loop max_part=63
#  ^ now when we add a loop device, it will list multiple
#  partitions with a pN suffix, where N = 1-63
losetup -f hd0.img

ls /dev/loop0*
#  that will print the partitions. my output was:
#  /dev/loop0  /dev/loop0p1  /dev/loop0p2  /dev/loop0p5

parted /dev/loop0 p
#  print partition info. for me, the ext2 partition was number 1.

sudo fsck /dev/loop0p1
#  that runs fsck on partition 1. you may need to use some options,
#  check "man fsck" for more info. also it may be necessary to run
#  again if there are errors.

#  stop the loop device usage:
losetup -d /dev/loop*
#  again, since we have both loop0 and loop0pN:
losetup -d /dev/loop*

#  that's it! try not to kill qemu too much. you can use the halt
#  command to stop hurd before you kill qemu (at least with Debian.)

source: one of the comments in:
http://www.docunext.com/blog/2007/07/losetup-working-with-raw-disk-images.html

Hope it helps.

-Andrew




reply via email to

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