On Mon, Mar 19, 2012 at 9:28 PM, Sebastian Pipping <sp...@gentoo.org> wrote: > On 03/18/2012 06:44 PM, Tanstaafl wrote: <snip> >> On that note - is it possible, and if so, does anyone have any decent >> detailed How-to's on how I might be able to convert a separate /user to >> one on directly on / on a running system? > > From my current understanding (please double-check, no warrenties): > > 0. Make backups > > 1. Boot some sort of live/rescue CD > (so you can fiddle with /usr without shooting your foot) > > (2. Enlarge space on partition/device <root> (the one holding /)) > > (3. Enlarge file system sitting on partition/device <root>) > > 4. Make a new folder <root>/usr > > 5. Copy content from <usr>/ to <root>/usr/ > > - Watch out for use of Xattr (extended file attributes) > > - Watch out for use of POSIX ACLs > > - Use something like --archive with cp/rsync to maintain attributes > > 6. Update <root>/etc/fstab > > 7. Reboot > > 8. Resolve partition <usr> > > Good luck. > > Best, > > > > Sebastian >
That would work, and is among the safer routes, but it also means taking the system down for a fair while. If your root has enough free space to hold all of /usr already, without any resizing, you actually can do everything with only a single reboot along the way (and while that, too, *can* be avoided with a lazy unmount in place of the reboot [see notes at the bottom if you're feeling adventurous], I don't dare test it when a reboot's far from likely to hurt me), as long as you can resist making changes to files in /usr between starting and your reboot. The difficulty you run into is that you can't copy from /usr/* (the data on the usr partition) directly into /usr (a folder acting as a mount point on the root partition). What you *can* do, however, is bind mount your root partition somewhere else, and your usr partition too if you like, make the copy (using tar, rsync, or cp with the appropriate flags to preserve all the important details), adjust fstab, and then reboot into the adjusted system, after which, you can go about pondering what to do with your old /usr partition. Incidentally, this general method also works fairly well for taking snapshots of a live root partition (accepting that the contents of anything prone to change mid-copy could be anything, like /tmp, most of /var, bits of /etc), catching the static files hidden by mounting done at boot time, like the base set of device nodes in /dev too... As root, obviously, and you may include --acls or --xattrs on the rsync call, if they suit your system's needs (I have quite a bit turned off on the machine I'm testing this on as I write it up): 1) make backups and... 1.a) verify backups... consider this my disclaimer... 2) mkdir /mnt/root-bind/ /mnt/usr-bind/ 3) mount --bind / /mnt/root-bind/ 4) mount --bind /usr/ /mnt/usr-bind/ 5) rsync --archive --hard-links --sparse --progress /mnt/usr-bind/ /mnt/root-bind/usr/ 6) edit fstab ... 7) cross fingers and reboot ... 8) rm -r /mnt/root-bind/ /mnt/usr-bind/ While 9 can be done before the reboot, this way doesn't depend on fighting with unmounting outside of the reboot itself. And some background on my test system... <Before Copy> # df -h Filesystem Size Used Avail Use% Mounted on rootfs 7.9G 128M 7.7G 2% / /dev/root 7.9G 128M 7.7G 2% / rc-svcdir 1.0M 56K 968K 6% /lib64/rc/init.d udev 10M 176K 9.9M 2% /dev shm 2.0G 0 2.0G 0% /dev/shm /dev/sda1 505M 15M 465M 3% /boot /dev/sda8 15G 845M 14G 6% /var /dev/sda7 20G 2.0G 18G 10% /usr /dev/sda9 49G 3.2G 46G 7% /home tmpfs 2.0G 4.0K 2.0G 1% /tmp <After copy (extras trimmed)> # df -h Filesystem Size Used Avail Use% Mounted on rootfs 7.9G 2.1G 5.8G 27% / /dev/sda7 20G 2.0G 18G 10% /usr <After reboot> # df -h Filesystem Size Used Avail Use% Mounted on rootfs 7.9G 2.0G 5.9G 26% / /dev/root 7.9G 2.0G 5.9G 26% / rc-svcdir 1.0M 56K 968K 6% /lib64/rc/init.d udev 10M 176K 9.9M 2% /dev shm 2.0G 0 2.0G 0% /dev/shm /dev/sda1 505M 15M 465M 3% /boot /dev/sda8 15G 844M 14G 6% /var /dev/sda9 49G 3.2G 46G 7% /home /dev/sda10 141G 7.9G 133G 6% /data tmpfs 2.0G 0 2.0G 0% /tmp And... at least for my own, copied, rebooted, and working as though nothing's changed (aside from a presently unused 20G partition sitting around on the drive). I do admit, my 8G existing root partition is a bit on the large size.. this system transitioned from a desktop to a 'server', losing X as well as a number of hefty things that were in /opt ... leaving me with both a lot of free space on / and a much more slim /usr so it's a rare thing to be able to so easily drop things in place. It did manage a downtime of all of about a minute, though, rather than booting a secondary OS to do all of that. [notes regarding a potentially bad idea follow] Lastly, on the topic of avoiding the reboot altogether, the trick would be, instead of unmounting those bind mounts, doing a umount -l /usr then, as you're able, freeing references to the old mount, syncing new changes from the old tree into the new one (if any, and if appropriate), and then starting up whatever was killed to free it, if appropriate. Due to the usual way /usr is used, however, it's entirely likely that, after the lazy unmount, the process of simply updating the system over time will eventually free up all old references, releasing the old mount, and allowing everything to roll over to the new arrangement gradually, much like the ability to update things like sshd in place, restarting the service (as the , but leaving existing connections uninterrupted... but, again, I'm not brave enough to test it, let alone make guarantees. -- Poison [BLX] Joshua M. Murphy
