12 Feb
2014
12 Feb
'14
9:32 p.m.
I'm stuck on the old disk layout which is hiding 0.5GB of disk away from
me, and I think I'm going to buy a 5GB upgrade, so I wondered about
fixing all this in one go.
I don't want to reinstall the OS though, so my plan is request/get the
disk upgrade, then to boot into the rescue environment and as root,
cd myvpsfilesystem
tar -c . | ssh somewhereelse "cat > filesystem.tar"
Then do the Xen disk reset, allocate the new space, then boot to rescue
again, mkfs with label "root", then:
ssh somewhereelse "cat filesystem.tar" | tar -x
I've thought about the disk block ID being different after this, but
it's not in fstab or anywhere else I can find.
As I understand it pyGrub will also just work.
The question is, am I heading for any pitfalls?
Thanks for any opinions.
Chris Tallon
12 Feb
12 Feb
9:56 p.m.
Hi Chris,
On Wed, Feb 12, 2014 at 09:32:10PM +0000, Chris Tallon wrote:
I'm stuck on the old disk layout which is hiding
0.5GB of disk away from
me, and I think I'm going to buy a 5GB upgrade, so I wondered about
fixing all this in one go.
By old disk layout do you mean that you have an xvda1 partition
without an xvda block device? If so, and you're wanting to change
things about, then it would be best to put a ticket in to support so
we can change it from xvda1 to xvda.
Assuming you currently have it booting correctly by UUID or label
then this would be as simple as us shutting your VPS down and
booting it again.
The rest of this email will assume a single block device xvda with a
filesystem directly on it.
You say "stuck", but what problems is it actually causing you?
Also I am interested to know about the 0.5GiB that is missing. Can
you tell me which VPS account this is please? Off-list if you like.
I don't want to reinstall the OS though, so my
plan is request/get the
disk upgrade, then to boot into the rescue environment and as root,
cd myvpsfilesystem
tar -c . | ssh somewhereelse "cat > filesystem.tar"
Where would you be storing filesystem.tar at this point? The rescue
environment runs out of your RAM, so if (for example) you had 480MiB
RAM, you would have 480MiB of writable space. Which would crash the
environment long before you wrote 480MiB.
Storing it remotely would work.
I am wondering what the point of doing this is though; there is
normally no issue with having a filesystem directly on xvda, and it
doesn't present a problem for growing it either.
The question is, am I heading for any pitfalls?
If all you're trying to do is add some disk space then you don't need
to do any of this.
If I've misunderstood and you're trying to do something else, ten
maybe.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
9:59 p.m.
On Wed, Feb 12, 2014 at 09:56:23PM +0000, Andy Smith wrote:
On Wed, Feb 12, 2014 at 09:32:10PM +0000, Chris Tallon
wrote:
Duh yes obviously I failed to read that properly. I see you are
intending to store that "somewhereelse" :)
tar -c . | ssh somewhereelse "cat >
filesystem.tar"
Where would you be storing filesystem.tar at this point?
10:13 p.m.
Hi Andy,
I have an xvda with a file system directly on it. As for being stuck,
and the missing 0.5GB:
xen-shell> disks
Your disk layout is currently non-standard; only the "reset" and
"show" commands are available.
Current disk layout:
1. xvda 10,240MiB
Total disk capacity 10,720MiB
Reserved for backups 0MiB
Available for allocation 480MiB
Which was just a mild irritation I hadn't thought about until space
got tight. I guess that 480MiB was supposed to be allocated as swap
space at some point?
The account is equinox.
Thanks.
Chris Tallon
On 12/02/14 21:56, Andy Smith wrote:
Hi Chris,
On Wed, Feb 12, 2014 at 09:32:10PM +0000, Chris Tallon wrote:
I'm stuck on the old disk layout which is
hiding 0.5GB of disk
away from me, and I think I'm going to buy a 5GB upgrade, so I
wondered about fixing all this in one go.
By old disk layout do you mean that you have an xvda1 partition
without an xvda block device? If so, and you're wanting to change
things about, then it would be best to put a ticket in to support
so we can change it from xvda1 to xvda.
Assuming you currently have it booting correctly by UUID or label
then this would be as simple as us shutting your VPS down and
booting it again.
The rest of this email will assume a single block device xvda with
a filesystem directly on it.
You say "stuck", but what problems is it actually causing you?
Also I am interested to know about the 0.5GiB that is missing. Can
you tell me which VPS account this is please? Off-list if you
like.
I don't want to reinstall the OS though, so
my plan is
request/get the disk upgrade, then to boot into the rescue
environment and as root,
cd myvpsfilesystem tar -c . | ssh somewhereelse "cat >
filesystem.tar"
Where would you be storing filesystem.tar at this point? The
rescue environment runs out of your RAM, so if (for example) you
had 480MiB RAM, you would have 480MiB of writable space. Which
would crash the environment long before you wrote 480MiB.
Storing it remotely would work.
I am wondering what the point of doing this is though; there is
normally no issue with having a filesystem directly on xvda, and
it doesn't present a problem for growing it either.
The question is, am I heading for any pitfalls?
If all you're trying to do is add some disk space then you don't
need to do any of this.
If I've misunderstood and you're trying to do something else, ten
maybe.
Cheers, Andy
_______________________________________________ users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
10:31 p.m.
Hi Chris,
On Wed, Feb 12, 2014 at 10:13:26PM +0000, Chris Tallon wrote:
Current disk layout:
1. xvda 10,240MiB
Total disk capacity 10,720MiB
Reserved for backups 0MiB
Available for allocation 480MiB
Okay, yes, that's pretty simple then.
Which was just a mild irritation I hadn't thought
about until space
got tight. I guess that 480MiB was supposed to be allocated as swap
space at some point?
I can create you an xvdb of 480MiB now if you like? That then puts
you into almost-standard territory.
You still don't need to do anything to have xvda grown, just send a
ticket asking for it.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
10:59 p.m.
Hi Chris,
On Wed, Feb 12, 2014 at 10:42:22PM +0000, Chris Tallon wrote:
On 12/02/14 22:31, Andy Smith wrote:
Okay so you should have a 480MiB xvdb block device now, visible in
your VPS.
You don't actually need to touch the "disks" command. Like I say, if
you need xvda extending then that's just a case of sending a support
ticket.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
I can create you an xvdb of 480MiB now if you
like? That then puts
you into almost-standard territory.
Ahah, yes please.
11:48 p.m.
On 12/02/14 22:59, Andy Smith wrote:
Hi Chris,
On Wed, Feb 12, 2014 at 10:42:22PM +0000, Chris Tallon wrote:
Thanks Andy, xvdb configured and working.
Also, thanks Ed, I guess I have some reading to do on tar and ctimes.
Chris Tallon
On 12/02/14 22:31, Andy Smith wrote:
Okay so you should have a 480MiB xvdb block device now, visible in
your VPS.
You don't actually need to touch the "disks" command. Like I say,
if you need xvda extending then that's just a case of sending a
support ticket.
Cheers, Andy
I can create you an xvdb of 480MiB now if you
like? That then
puts you into almost-standard territory.
Ahah, yes please. 
10:56 p.m.
On Wed, Feb 12, 2014 at 09:32:10PM +0000, Chris Tallon wrote:
[...]
cd myvpsfilesystem
tar -c . | ssh somewhereelse "cat > filesystem.tar"
I'd use dump/restore of the block device to get ctimes, if you consider
them important.
--
Best regards,
Ed http://www.s5h.net/
3898
days inactive
3898
days old
8 comments
3 participants
participants (3)
-
Andy Smith -
Chris Tallon -
ed