Is gparted useful? My recollection is that it is pretty good at what you want to do.

Cheers, Michael

On 16-03-31 12:00 PM, roundtable-request@muug.mb.ca wrote:

Send Roundtable mailing list submissions to roundtable@muug.mb.ca

To subscribe or unsubscribe via the World Wide Web, visit http://www.muug.mb.ca/mailman/listinfo/roundtable or, via email, send a message with subject or body 'help' to roundtable-request@muug.mb.ca

You can reach the person managing the list at roundtable-owner@muug.mb.ca

When replying, please edit your Subject line so it is more specific than "Re: Contents of Roundtable digest..."

Today's Topics:

1. shrink to smaller disk, offsite (Trevor Cordes)
2. Re: shrink to smaller disk, offsite (Gilles Detillieux)

---

Message: 1 Date: Wed, 30 Mar 2016 20:56:08 -0500 From: Trevor Cordes trevor@tecnopolis.ca To: MUUG RndTbl roundtable@muug.mb.ca Subject: [RndTbl] shrink to smaller disk, offsite Message-ID: 20160331015608.GA22087@pog.tecnopolis.ca Content-Type: text/plain; charset=us-ascii

I have an interesting problem.

Linux box. /, /boot, swap on 3 RAID1 partitions 2 disks

currently RAID is degraded, just using 1 750G disk. / (ext3) is 700G, only 200G used.

No LVM.

I added a 500G SSD. I want that to be the new 2nd RAID1 disk.

I need to shrink / to be ~450G before I can do this.

resize2fs can only do shrink on unmounted. That's a problem. RAID1 can shrink the RAID block dev once I get the fs shrunk, so that's not a problem.

I'm offsite and want to find a way to do this without going onsite and using single-user mode or a boot cd.

Options?

I guess I could make a new, smaller RAID1 / on the SSD, quiet down all services, and do a cp -a or cpio or something? Then get the system to boot off the new / and ignore the old one, and reboot. Besides in theory, has anyone actually do a whole cpio or cp -a of an entire *running* / and been successful? Sample command lines? I guess nowadays there would be zero dev files that need to be copied because udev recreates them all? So it's literally just files, dirs, links and fifos that need copying?

Any options using just ext3 and mdadm tools? Surely there must be some way... unless the no-shrink-mounted makes that impossible.

Maybe I'm missing something.

Thanks!

---

Message: 2 Date: Thu, 31 Mar 2016 11:47:08 -0500 From: Gilles Detillieux grdetil@scrc.umanitoba.ca To: roundtable@muug.mb.ca Subject: Re: [RndTbl] shrink to smaller disk, offsite Message-ID: 56FD548C.9010702@scrc.umanitoba.ca Content-Type: text/plain; charset=windows-1252; format=flowed

It's been a while since I've had to do this, but I have successfully replicated a live root volume on a few occasions using rsync. It could be as simple as doing this:

rsync  -aHXx /.  /mnt/newdisk/.

I've adopted the "/." at the end of both paths to rsync as a defensive measure because it can make some funky assumptions about where you want source directories put in the target directory otherwise. I've often ended up with the target having an extra level of directory when I tell rsync to copy one directory to another without the /. at the end. The advantage of using rsync is that you can rerun it again to more quickly update the target if you suspect the source changed during the first copy, which can happen even on a relatively quiet system. To make the subsequent update even quicker, you can just run it on directories that are likely to have changed, e.g. /etc.

I don't recall if I had to play around with --exclude options to avoid paths I didn't want traversed, or if the -x took care of all of these. I do recall that on a few occasions I played it safe by using a for loop to only copy specific subdirectories and avoid things like /sys and /proc altogether, but that was a bit more complicated and error-prone (easy to miss something important).

Note that if you're using SELinux on your system, you'll want to verify that the target's contexts are correctly set, and chcon any that aren't. rsync with the -X option should copy contexts accurately, but you may want to manually override the context for any mount points on the target volume, and make sure the volume's root directory is set to system_u:object_r:root_t. ls -Zld dir is the way I examine contexts (in addition to modes & ownership).

Hope this helps.

Gilles

On 2016-03-30 20:56, Trevor Cordes wrote:

...

I have an interesting problem.

Linux box. /, /boot, swap on 3 RAID1 partitions 2 disks

currently RAID is degraded, just using 1 750G disk. / (ext3) is 700G, only 200G used.

No LVM.

I added a 500G SSD. I want that to be the new 2nd RAID1 disk.

I need to shrink / to be ~450G before I can do this.

resize2fs can only do shrink on unmounted. That's a problem. RAID1 can shrink the RAID block dev once I get the fs shrunk, so that's not a problem.

I'm offsite and want to find a way to do this without going onsite and using single-user mode or a boot cd.

Options?

I guess I could make a new, smaller RAID1 / on the SSD, quiet down all services, and do a cp -a or cpio or something? Then get the system to boot off the new / and ignore the old one, and reboot. Besides in theory, has anyone actually do a whole cpio or cp -a of an entire *running* / and been successful? Sample command lines? I guess nowadays there would be zero dev files that need to be copied because udev recreates them all? So it's literally just files, dirs, links and fifos that need copying?

Any options using just ext3 and mdadm tools? Surely there must be some way... unless the no-shrink-mounted makes that impossible.

Maybe I'm missing something.

Thanks! _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable