|
[20111022]
|
Enlarging a (virtual) disk
I've tried to build NetBSD-current at various points in the past few
months, and always hit one of two bugs: -current blows up with
a gcc Internal Compiler Error when crossbuilding on Mac OS X,
and kernel panics with native NetBSD builds with sources on NFS.
This stinks, and I've successfully managed to do a successful
-current build with sources on (local) disk. With NetBSD
running within VMware Fusion on Mac OS X.
To go on from there, I found that my NetBSD VM's only disk
was too small to do anything useful. Options for enlarging
that came to mind:
- NFS - see 'panic' above, no go.
- Adding another (virtual) disk - easily doable, but I felt like not adding one
- Extending the existing disk - adventure time!
Option #3 was it, and after removing all VMware snapshots, enlarging the
disk was easy with VMware Fusion, going from 10GB to 20GB.
After growing the disk itself, the next question was how to use the
newly gained disk. Of course some file system needs to use it,
and in theory there are the following options:
- Enlarge the last file system on disk
- Fix the partition table to add another partition for the new space
The disk was resized from 10GB to 20GB. The partition table
(disklabel) was created by a standard NetBSD install, and first
had the root file system, followed by the swap partition.
From that, adding 10GB more swap was not useful,
so I've decided to change the disklabel to add the new disk space
as a new partition behind the existing partitions.
This is also an excuse to not frob with
growfs and resize_ffs. (And of course I'm ignoring the option of backing up the full file system, doing a full rebuild of the filesystem
and then doing a restore :-)
For those in a similar situation, here are the steps to use
the newly gained space on an enlarged (virtual) disk:
- Prepare: save the old output of "dmesg" (/var/run/dmesg.boot is OK)
- Enlarge - VMware Fusion wants a shutdown for that, you cannot suspend
the machine
- After booting, run a diff on the saved "dmesg" output, to learn
what the old and new size of the disk is, in sectors. My diff looks
like this, note the size change in sectors:
-wd0: 10240 MB, 22192 cyl, 15 head, 63 sec, 512 bytes/sect x 20971520 sectors
+wd0: 20480 MB, 44384 cyl, 15 head, 63 sec, 512 bytes/sect x 41943040 sectors
- Backup the existing/old disklabel, just in case: disklabel wd0 >disklabel.BAK
- Edit the disklabel: disklabel -e wd0
- In the editor, adjust the disk size in sectors from 20971520 to 41943040:
total sectors: 41943040
- Partition 'd' is the full disk on i386/amd64, it starts at sector 0
and is 41943040 sectors big
# size offset fstype [fsize bsize cpg/sgs]
d: 41943040 0 unused 0 0 # (Cyl. 0 - 44384*)
- Partition 'c' is the NetBSD part of the disk. As this VM only has NetBSD, all the usable space is used. Note that "usable" space excludes the first 63 sectors of the disk (mbr etc.), i.e. it is 41943040 - 63 = 41942977 sectors:
# size offset fstype [fsize bsize cpg/sgs]
c: 41942977 63 unused 0 0 # (Cyl. 0*- 44384*)
- After this everything is in sync with the new disk again, and the remaining/new space can be used for new partition 'e'. As the new space starts where
the disk used to end, its offset is the old size, 20971520 sectors.
The size of the new partition expands from the offset sector 20971520
to the end of the disk at sector 41943040, i.e. the partition size is:
% expr 41943040 - 20971520
20971520
In total, this gives for the new partition:
# size offset fstype [fsize bsize cpg/sgs]
e: 20971520 20971520 4.2BSD 2048 16384 0 # (Cyl. 22192*- 44384*)
- Last, create file system, mount and populate:
# newfs /dev/rwd0e
# mkdir /disk2
# echo '/dev/wd0e /disk2 ffs rw,log 2 2' >>/etc/fstab
# mount /disk2
# cd /usr ; pax -rw -pe -v stuff /disk2
# rm -fr stuff ; ln -s /disk2/stuff .
Now let's see if I get things far enough to get a build
of g4u going... wish me luck!
P.S.: I'm offering choccolate to anyone fixing crossbuilding of
NetBSD-current from Mac OS X. Any takers?
[Tags: disklabel, fusion, g4u, vmware]
|
