0

I have a VPS on the new Vultr system and I am noticing that they do not have pv-grub ready and available which makes my dilemma even more interesting.

I have a 40gig image I need to migrate to a 15 gig partition.

Normally just reboot into rescue mode and run fdisk or gparted, but this does not appear to be an option on the Vultr system.

There is a boot partition on the VPS but tentative attempts to access it with mount failed

[\u@r2d2:/root] # gpart show
=>      34  83886013  vtbd0  GPT  (40G)
        34        94      1  freebsd-boot  (47K)
       128  83885919      2  freebsd-ufs  (40G)

first attempt to access boot:

# mount /dev/vtbd0p1 /mnt/boot/
mount: /dev/vtbd0p1: Input/output error

previous attempt that locked system up midway:

dump -0 -f - / | ssh -c blowfish root@target_machine "cd /; restore -rf -"

used space 

[\u@r2d2:/root] # du -sh /
5.8G    /

What is an effective yet safe way (won't lock the system halfway during transfer because it can't access a locked file) to transfer a FreeBSD10 live VPS server to another live FreeBSD10 VPSs server. Hopefully catching that pesky boot partition as well.

Or resize a mounted partition.

Jenny D
  • 27,780
  • 21
  • 75
  • 114
nix
  • 145
  • 4
  • Don't assume that everyone has heard of your service provider. Interestingly, the choice of Xen is the primary reason I decided that I could not use them for anything. – Michael Hampton Apr 12 '15 at 17:00
  • @MichaelHampton As I recall, xen was one of the first to implement pv-grub. But I see no way to use it on there system. – nix Apr 12 '15 at 17:02
  • Wait.. it _says_ they use KVM. What's this about pvgrub? That's _only_ a Xen thing, since Xen has a strange process for booting virtual machines. – Michael Hampton Apr 12 '15 at 17:23
  • I found it. if you upload a livecd iso to the image, a feature pops up to 'attach it'. I am still going through the process but this looks like the resize solution needed. – nix Apr 12 '15 at 17:32
  • Also, I was experimenting with rsync and I think I found a really big cheat. Both systems were virtually the same version and both perfectly up to date. I ran 'rsync --exclude="/dev/*" --exclude="/sys/*" --exclude="/proc/*" -aHSKDvz -e ssh / root@108.61.169.20:/' and right now everything looks fine. Still testing – nix Apr 12 '15 at 17:47

1 Answers1

0

You cannot mount the boot partition, because there is no filesystem there.

The dump method should work, though. It won't trip on locked files, unless you use mandatory locking (which would be rather weird in the first place).

When dump "locks up", could you press ^T (ctrl-t) to see what exactly is going on?

Edward Tomasz Napierala
  • 206
  • 1
  • 4