Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have an old FreeBSD Server (running 7.3-RELEASE) that desperately needs additional storage. In fact, it has some-- the original 20G SCSI drives have been replaced by 300G SCSI drives, so in theory there is 280G available that could be used.

I'd like to make use of this space. I think the best way to do this is by formatting the unused space as a new slice on the existing drive, but I'm not clear how to do this without destroying the data on the existing slice. Most of the documentation I can find about doing this refers to initial installation. I know how to set up slices and partitions during initial installation, but not how to claim unused space on the drive AFTER initial installation.

(I'd also be happy to expand the slice and add additional partitions to the existing slice, but I've heard that this is riskier).

I thought the easy way to do this might be to use /stand/sysinstall, but when I go into either Configure->FDisk or Configure->Label, I get this message:

No disks found!  Please verify that your disk controller is being
properly probed at boot time.  See the Hardware Guide on the
Documentation menu for clues on diagnosing this type of problem.

This is obviously untrue, since I'm actually running off of a disk when I get this message, but maybe sysinstall just doesn't like messing with the boot disk?

Output of fdisk da0:

******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=2235 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=2235 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 35905212 (17531 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 1023/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

Output of bsdlabel da0s1

# /dev/da0s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:  2097152        0    4.2BSD     2048 16384    89
  b:  2097152  2097152      swap
  c: 35905212        0    unused        0     0         # "raw" part, don't edit
  e:  2097152  4194304    4.2BSD     2048 16384    89
  f: 29613756  6291456    4.2BSD     2048 16384    89

Update:

I came a cross the advice to use sade for this purpose. Unfortunately, sade can't see much empty space:

         0         63         62        -     12     unused        0
        63   35905212   35905274    da0s1      8    freebsd      165
  35905275      10501   35915775        -     12     unused        0

This may be a dead end. Do I need to figure out drive geometry somehow? It might be relevant to mention that the drive is a RAID 1 mirror set; originally the mirrored drives were both 20G SCSI drives but they've both been swapped out with 300G drives. I'm willing to temporarily break the mirror if that will help.

share|improve this question
    
Be careful, there were weird "this partition is really the sum of those others" partition schemes in BSD. I did some disk reorganizing under SunOS (BSD derivative). I vaguely remember that the partition table was in the first sector (or so) of the drive, so when fooling around with partitions I'd (a) print the detailed partition table out, and (b) save the partition table somewhere (typically on a floppy disk, I said the memories have faded, didn't I?) before messing around with the partitions. After repartitioning, I'd print the new partiton table and checked entry by entry against the old. –  vonbrand Feb 7 '13 at 3:29
    
Yeah, you can see that in partition c in the bsdlabel output. –  davidcl Feb 7 '13 at 18:28
    
But that's bsdlabel partitions within the slice. I don't think that's helpful for creating a new slice. I'm guessing the key is drive geometry... but that could be off base. –  davidcl Feb 7 '13 at 21:28
    
Have you checked the BSD websites and other documentation? You mention that is an old version, is it still supported? This is even more relevant for servers, where miscreants can create severe problems. If not, perhaps your best bet is to backup everything, install the newest version with the disk layout you require and restore what is required. –  vonbrand Feb 13 '13 at 11:40
1  
That's a fair reply; you know your system better than I do. Take my next comment here with the grain of salt it's worth ;) I subscribe to the philosophy that if I have to manually rebuild a server, any server, I've already lost the war. Having managed several dozen mail servers, I much prefer to let my automation software (chef, cfengine, puppet, etc) do the rebuilds. This ensures that if I'm hit by a bus (or a pink slip) the same day a server fails, that standing a new one up takes minutes, not a day. Best of luck to you. –  Stephan Feb 14 '13 at 19:42
show 8 more comments

2 Answers 2

So it sounds like when you did the replacement of the older disk, you basically just used dd to copy the whole old disk to the new one. So you should be able to create another fdisk partition, which would be da0s2, then put another BSD partition in there, which would be da0s2a. I would use geom to do it, rather than sysinstall or sade. If you can show the output of gpart list, I can probably walk you through creating the new partition. Of course, be sure to have good backups, etc.

Of course, the nicer thing to do would be to upgrade to 9.1, make the partitions larger, then use growfs to make the existing FS larger, so that the new disk space is part of the same FS. (Normally I like to split things up a little, by having a separate /var and /usr (at least), but I know most people don't these days and at that size disk it can become a bit of a chore to manage where things are stored.)

(Oh, and I guess the best thing would be to switch to ZFS but I imagine if the system had a 20gb disk in it, it's probably 32bit and not a lot of RAM so not ideal for ZFS...)

Edit: Completely missed the part about the mirror. Yeah, breaking the mirror could be one path towards it. Is it hardware RAID mirror or software?

share|improve this answer
    
Hardware RAID. And actually when I replaced the disks, the RAID did all the work-- I just swapped the disks one at a time (the old disks were failing, which is was the primary motivation at the time) and let it rebuild on the new disks. I don't have "gpart" on my system-- is this a part of FreeBSD or a port? If part of FreeBSD, it must have been added after 7.3. Upgrading FreeBSD-- and many other things I should do that might seem sensible-- are non-starters without more disk space, unfortunately. –  davidcl Feb 18 '13 at 21:59
    
OK, that helps. As far as gpart, it should be there. At least the man page was there in 7.3 freebsd.org/cgi/… –  Steve Wills Feb 19 '13 at 16:08
    
Oops Comment editing is different than reply editing. Anyway, I guess the thing to do would be to go ahead and create da0s2 and da0s2a and create a new FS on there. Do you need help with that? –  Steve Wills Feb 19 '13 at 16:10
add comment

A 20GB disk!? Go buy yourself a 16 or 32GB USB thumb drive. Stick it into the box (it'll mount as /dev/daN (with N being the next lowest da device not in use). Using sysinstall, format the USB drive as one large partition and copy your entire disk over to the thumb drive (or to 2 thumb drives if you're paranoid and have no other backups):

sysinstall (configure -> fdisk & label)
cd /mnt/root
dump -0aL -f - / | restore xf -

Then edit /mnt/root/etc/fstab, telling FreeBSD to boot off the thumb drive with a fstab entry like this one:

/dev/da0s1a /   ufs ro   1  1

If your BIOS is configured to boot off USB removable media, your next reboot will be off the thumb drive. If not, you can change your BIOS settings or edit /etc/fstab on the main disk to boot off the thumb drive. Now that you have a complete verified backup, go into the RAID BIOS, destroy the volume and create a new (much larger) one. Then you can use the standard FreeBSD utilities to format the new volume.

share|improve this answer
    
Heh. Hi Matt! You're actually familiar with this particular server. The flash drive is a great idea, and one I hadn't thought of. Not sure why not. I'll need to make sure the BIOS on this box will actually boot off of USB... it's old enough that this may be in doubt. If the BIOS will not boot off of USB, this sounds a bit more challenging. At the point where I've destroyed my original volume, I no longer have a bootable volume. I could install FreeBSD from optical media, and then restore selectively, but it becomes a little more of a project, no? –  davidcl Jun 19 '13 at 15:18
    
I'd be VERY surprised if the box wouldn't boot off USB. If the machine has USB ports, it almost certainly has the BIOS option to boot off them (likely as 'removable media'). I wouldn't go recreating the volume until after verifying it. Worst case, you back up to a USB drive, recreate the new volume, boot off CD-R, and then restore to the new disk. –  Matt Simerson Jun 24 '13 at 7:44
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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