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 |