Gentoo Archives: gentoo-user

From: Joshua Murphy <poisonbl@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Initramfs or move /usr to /, oh my...
Date: Wed, 21 Mar 2012 03:07:59
Message-Id: CAOTuDKrK2ZwTsSqt1H=B6Cox9X1rZ7GfoQCNFdkMSaiKcEsu0w@mail.gmail.com
In Reply to: Re: [gentoo-user] Initramfs or move /usr to /, oh my... by Sebastian Pipping
1 On Mon, Mar 19, 2012 at 9:28 PM, Sebastian Pipping <sping@g.o> wrote:
2 > On 03/18/2012 06:44 PM, Tanstaafl wrote:
3 <snip>
4 >> On that note - is it possible, and if so, does anyone have any decent
5 >> detailed How-to's on how I might be able to convert a separate /user to
6 >> one on directly on / on a running system?
7 >
8 > From my current understanding (please double-check, no warrenties):
9 >
10 >  0. Make backups
11 >
12 >  1. Boot some sort of live/rescue CD
13 >    (so you can fiddle with /usr without shooting your foot)
14 >
15 > (2. Enlarge space on partition/device <root> (the one holding /))
16 >
17 > (3. Enlarge file system sitting on partition/device <root>)
18 >
19 >  4. Make a new folder <root>/usr
20 >
21 >  5. Copy content from <usr>/ to <root>/usr/
22 >
23 >    - Watch out for use of Xattr (extended file attributes)
24 >
25 >    - Watch out for use of POSIX ACLs
26 >
27 >    - Use something like --archive with cp/rsync to maintain attributes
28 >
29 >  6. Update <root>/etc/fstab
30 >
31 >  7. Reboot
32 >
33 >  8. Resolve partition <usr>
34 >
35 > Good luck.
36 >
37 > Best,
38 >
39 >
40 >
41 > Sebastian
42 >
43
44 That would work, and is among the safer routes, but it also means
45 taking the system down for a fair while. If your root has enough free
46 space to hold all of /usr already, without any resizing, you actually
47 can do everything with only a single reboot along the way (and while
48 that, too, *can* be avoided with a lazy unmount in place of the reboot
49 [see notes at the bottom if you're feeling adventurous], I don't dare
50 test it when a reboot's far from likely to hurt me), as long as you
51 can resist making changes to files in /usr between starting and your
52 reboot. The difficulty you run into is that you can't copy from /usr/*
53 (the data on the usr partition) directly into /usr (a folder acting as
54 a mount point on the root partition). What you *can* do, however, is
55 bind mount your root partition somewhere else, and your usr partition
56 too if you like, make the copy (using tar, rsync, or cp with the
57 appropriate flags to preserve all the important details), adjust
58 fstab, and then reboot into the adjusted system, after which, you can
59 go about pondering what to do with your old /usr partition.
60 Incidentally, this general method also works fairly well for taking
61 snapshots of a live root partition (accepting that the contents of
62 anything prone to change mid-copy could be anything, like /tmp, most
63 of /var, bits of /etc), catching the static files hidden by mounting
64 done at boot time, like the base set of device nodes in /dev too...
65
66 As root, obviously, and you may include --acls or --xattrs on the
67 rsync call, if they suit your system's needs (I have quite a bit
68 turned off on the machine I'm testing this on as I write it up):
69
70 1) make backups and... 1.a) verify backups... consider this my disclaimer...
71 2) mkdir /mnt/root-bind/ /mnt/usr-bind/
72 3) mount --bind / /mnt/root-bind/
73 4) mount --bind /usr/ /mnt/usr-bind/
74 5) rsync --archive --hard-links --sparse --progress /mnt/usr-bind/
75 /mnt/root-bind/usr/
76 6) edit fstab ...
77 7) cross fingers and reboot ...
78 8) rm -r /mnt/root-bind/ /mnt/usr-bind/
79
80 While 9 can be done before the reboot, this way doesn't depend on
81 fighting with unmounting outside of the reboot itself.
82
83 And some background on my test system...
84 <Before Copy>
85 # df -h
86 Filesystem Size Used Avail Use% Mounted on
87 rootfs 7.9G 128M 7.7G 2% /
88 /dev/root 7.9G 128M 7.7G 2% /
89 rc-svcdir 1.0M 56K 968K 6% /lib64/rc/init.d
90 udev 10M 176K 9.9M 2% /dev
91 shm 2.0G 0 2.0G 0% /dev/shm
92 /dev/sda1 505M 15M 465M 3% /boot
93 /dev/sda8 15G 845M 14G 6% /var
94 /dev/sda7 20G 2.0G 18G 10% /usr
95 /dev/sda9 49G 3.2G 46G 7% /home
96 tmpfs 2.0G 4.0K 2.0G 1% /tmp
97
98 <After copy (extras trimmed)>
99 # df -h
100 Filesystem Size Used Avail Use% Mounted on
101 rootfs 7.9G 2.1G 5.8G 27% /
102 /dev/sda7 20G 2.0G 18G 10% /usr
103
104 <After reboot>
105
106 # df -h
107 Filesystem Size Used Avail Use% Mounted on
108 rootfs 7.9G 2.0G 5.9G 26% /
109 /dev/root 7.9G 2.0G 5.9G 26% /
110 rc-svcdir 1.0M 56K 968K 6% /lib64/rc/init.d
111 udev 10M 176K 9.9M 2% /dev
112 shm 2.0G 0 2.0G 0% /dev/shm
113 /dev/sda1 505M 15M 465M 3% /boot
114 /dev/sda8 15G 844M 14G 6% /var
115 /dev/sda9 49G 3.2G 46G 7% /home
116 /dev/sda10 141G 7.9G 133G 6% /data
117 tmpfs 2.0G 0 2.0G 0% /tmp
118
119 And... at least for my own, copied, rebooted, and working as though
120 nothing's changed (aside from a presently unused 20G partition sitting
121 around on the drive). I do admit, my 8G existing root partition is a
122 bit on the large size.. this system transitioned from a desktop to a
123 'server', losing X as well as a number of hefty things that were in
124 /opt ... leaving me with both a lot of free space on / and a much more
125 slim /usr so it's a rare thing to be able to so easily drop things in
126 place. It did manage a downtime of all of about a minute, though,
127 rather than booting a secondary OS to do all of that.
128
129 [notes regarding a potentially bad idea follow]
130 Lastly, on the topic of avoiding the reboot altogether, the trick
131 would be, instead of unmounting those bind mounts, doing a umount -l
132 /usr then, as you're able, freeing references to the old mount,
133 syncing new changes from the old tree into the new one (if any, and if
134 appropriate), and then starting up whatever was killed to free it, if
135 appropriate. Due to the usual way /usr is used, however, it's entirely
136 likely that, after the lazy unmount, the process of simply updating
137 the system over time will eventually free up all old references,
138 releasing the old mount, and allowing everything to roll over to the
139 new arrangement gradually, much like the ability to update things like
140 sshd in place, restarting the service (as the , but leaving existing
141 connections uninterrupted... but, again, I'm not brave enough to test
142 it, let alone make guarantees.
143
144 --
145 Poison [BLX]
146 Joshua M. Murphy

Replies

Subject Author
Re: [gentoo-user] Initramfs or move /usr to /, oh my... Sebastian Pipping <sping@g.o>
Re: [gentoo-user] Initramfs or move /usr to /, oh my... Neil Bothwick <neil@××××××××××.uk>