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.

  • 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
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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.