scip
Active Member
Wenn man auf einem 1&1 Rootserver (oder einem vergleichbaren Hoster ohne FreeBSD-Console) ein Problem hat (sagen wir die Kiste kommt nicht mehr hoch), dann hat man mit dem Linux Rescue System ein Problem, weil da von Haus aus kein UFS Treiber dabei ist und selbst wenn, dann nur read-only. Dinge wie disklabel etc fehlen ausserdem. Also ich hatte neulich das Problem und habe einen Weg gefunden, trotzdem auf die Platten zuzugreifen.
Zu diesem Zweck habe ich mir unter Debian ein statisches qemu compiliert und mit diesem mfsbsd gestartet, von dem aus ich dann auf die physikalischen Platten zugreifen konnte.
So funktioniert's:
1) Debian 64bit besorgen (zur Not im virtualbox).
2) qemu Sourcen runterladen (http://wiki.qemu.org/Download#Latest_Source_Code)
3) minimal qemu statisch bauen:
Der Prefix /mnt/qemu ist Absicht, damit qemu später auf dem Rescuesystem seinen Kram findet.
Dann wie üblich make & make install.
4) mfsbsd 64bit Image besorgen: http://mfsbsd.vx.sk/
5) ich hab ein start/stop-Script dafür gebaut, das einfach nach /mnt/qemu kopieren:
6) dann /mnt/qemu zusammenpacken:
Den Tarball muss man sich nun irgendwo sichern, daheim am PC oder auf nem anderen Server...
-----
Um das Teil zu nutzen, geht man wie folgt vor:
1) 64bit Rescue System booten + dort einloggen
2) ramdisk erstellen:
3) o.g. qemu.tgz dort auspacken
4) und starten
5) wenn mfsbsd fertig gebootet hat, entweder direkt in der curses-console einloggen (User root, Passwort mfsroot) oder "ssh -p 2222 root@127.0.0.1" machen.
6) und von dort aus kann man dann auf die Platte zugreifen, Beispiel:
usw. Wichtig ist hier, dass die Platte von qemu als Platte Null, d.h. im mfsbsd als ad0, sichtbar ist. Unter native FreeBSD wäre das (in meinem Fall jedenfalls) eigentlich ad4. Man kann auch beide Platten einhängen, dazu einfach das o.g. Script entsprechend anpassen. Dann wird es aber ad0 und ad1 sein, statt dem normalen ad4 und ad6. Ob man dann auch Gmirror managen kann, hab ich noch nicht getestet. Keine Ahnung ob man da was kaputt macht, wenn die Devices andere sind. War bei mir jetzt aber auch noch nicht nötig.
Auf jeden Fall kann man auf diese Weise auf sein FreeBSD zugreifen.
besten Gruss,
scip
Zu diesem Zweck habe ich mir unter Debian ein statisches qemu compiliert und mit diesem mfsbsd gestartet, von dem aus ich dann auf die physikalischen Platten zugreifen konnte.
So funktioniert's:
1) Debian 64bit besorgen (zur Not im virtualbox).
2) qemu Sourcen runterladen (http://wiki.qemu.org/Download#Latest_Source_Code)
3) minimal qemu statisch bauen:
Code:
./configure --target-list=x86_64-softmmu --disable-sdl --disable-vnc --disable-xen \
--enable-curses --disable-curl --disable-check-utests --disable-kvm --prefix=/mnt/qemu \
--static
Der Prefix /mnt/qemu ist Absicht, damit qemu später auf dem Rescuesystem seinen Kram findet.
Dann wie üblich make & make install.
4) mfsbsd 64bit Image besorgen: http://mfsbsd.vx.sk/
5) ich hab ein start/stop-Script dafür gebaut, das einfach nach /mnt/qemu kopieren:
Code:
#!/bin/sh
PATH=$PATH:/mnt/qemu/bin
iso=isobsd/mfsbsd-8.2-amd64.iso # evtl anpassen!
hd=/dev/sda
pidfile=/tmp/qemu.pid
if test -n "$2"; then
hd=$2
fi
case $1 in
start)
echo
echo "About to run $iso using disk $hd."
echo "Use 'ssh -p 2222 root@localhost' with password mfsroot to connect"
echo
echo -n "press any key to start> "
read wait
qemu-system-x86_64 -pidfile $pidfile -cdrom $iso -boot d -curses -hda $hd -redir tcp:2222::22 -m 256M
;;
stop)
if test -s "$pidfile"; then
pid=`cat $pidfile`
kill $pid
fi
;;
*)
echo "Usage: $0 { start | stop } [disk]"
;;
esac
6) dann /mnt/qemu zusammenpacken:
Code:
cd /mnt
tar cpzf qemu.tgz qemu
Den Tarball muss man sich nun irgendwo sichern, daheim am PC oder auf nem anderen Server...
-----
Um das Teil zu nutzen, geht man wie folgt vor:
1) 64bit Rescue System booten + dort einloggen
2) ramdisk erstellen:
Code:
mkfs -q /dev/ram1 128000
mount /dev/ram1 /mnt
3) o.g. qemu.tgz dort auspacken
Code:
cd /mnt
scp woauchimmer:qemu.tgz .
tar xfz qemu.tgz
4) und starten
Code:
./qemu.sh start [optional: platte angeben, z.b. /dev/sda]
5) wenn mfsbsd fertig gebootet hat, entweder direkt in der curses-console einloggen (User root, Passwort mfsroot) oder "ssh -p 2222 root@127.0.0.1" machen.
6) und von dort aus kann man dann auf die Platte zugreifen, Beispiel:
Code:
mfsbsd# dmesg | grep ad
FreeBSD is a registered trademark of The FreeBSD Foundation.
em0: Ethernet address: 52:54:00:12:34:56
md0: Preloaded image </mfsroot> 36159488 bytes at 0xffffffff80d9fe20
ad0: 476940MB <QEMU HARDDISK 0.15.91> at ata0-master WDMA2
GEOM: ad0s1: geometry does not match label (255h,63s != 16h,63s).
mfsbsd# disklabel /dev/ad0s1
# /dev/ad0s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 10485760 16 4.2BSD 0 0 0
b: 8388608 10485776 swap
c: 976768002 0 unused 0 0 # "raw" part, don't edit
d: 104857600 18874384 4.2BSD 0 0 0
e: 104857600 123731984 4.2BSD 0 0 0
f: 209715200 228589584 4.2BSD 0 0 0
g: 538463218 438304784 4.2BSD 0 0 0
usw. Wichtig ist hier, dass die Platte von qemu als Platte Null, d.h. im mfsbsd als ad0, sichtbar ist. Unter native FreeBSD wäre das (in meinem Fall jedenfalls) eigentlich ad4. Man kann auch beide Platten einhängen, dazu einfach das o.g. Script entsprechend anpassen. Dann wird es aber ad0 und ad1 sein, statt dem normalen ad4 und ad6. Ob man dann auch Gmirror managen kann, hab ich noch nicht getestet. Keine Ahnung ob man da was kaputt macht, wenn die Devices andere sind. War bei mir jetzt aber auch noch nicht nötig.
Auf jeden Fall kann man auf diese Weise auf sein FreeBSD zugreifen.
besten Gruss,
scip