moving /lib - off topic advice wanted
I suppose this is an off topic question, other than it's related to
disks...:) I find that my / partition is more full than I would like. I
like to keep extra space available in case something unexpected happens.
Here is the current setup:
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda862187 48208 10768 82% /
/dev/hda1 7746 3955 3391 54% /boot
/dev/hdc5 495714 61545408568 13% /home
/dev/hda10 1274632690633518135 57% /usr
/dev/hda746632 18515 25709 42% /var
Turns out /lib is taking about 30 megs, so my first idea is to make a new
partition for /lib. I have done this:
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda862187 48208 10768 82% /
/dev/hda1 7746 3955 3391 54% /boot
/dev/hdc5 495714 61545408568 13% /home
/dev/hda10 1274632690633518135 57% /usr
/dev/hda746632 18515 25709 42% /var
/dev/hda6 116630 30565 80043 28% /lib
I figured this was a good first step, because if anything went wrong, I
could just reboot and the old /lib directory would still be there:)
(I have not put the /lib mount into /etc/fstab yet.)
So here are my questions, is it safe for me to do the following steps:
1. reboot to get /dev/hda6 unmounted (it's busy now, so umount does not
work)
2. mv /lib /lib.old
3. mkdir /lib
4. chmod 755 /lib
5. chown 0.0 /lib
6. mount /dev/hda6 /lib
7. rm -rf /lib.old {after testing}
Or am I going to run into trouble because /lib's files will be unavailable
for a bit while I enter these commands? Is there a better way to enlarge
/? In general how to you recommend changing partition sizes? Is this an
argument for not seperating directories into different partitions, since
it's harder to keep the free space evenly distributed?
Best Regards,
Robert Laughlin
Re: moving /lib - off topic advice wanted
Or am I going to run into trouble because /lib's files will be unavailable for a bit while I enter these commands? Is there a better way to enlarge /? In general how to you recommend changing partition sizes? Is this an argument for not seperating directories into different partitions, since it's harder to keep the free space evenly distributed? I think unless your drive mounting and init binaries are statically linked you're going to hit trouble at boot time. However have you sifted through /lib to find out if you have an libraries with debugging codes left in or binaries that have been upgraded and/or ones you can recompile to put in /usr/lib ? -sv
Re: moving /lib - off topic advice wanted
On Wed, 20 Oct 1999, Seth Vidal wrote: I think unless your drive mounting and init binaries are statically linked you're going to hit trouble at boot time. Perhaps I am wrong, I expected that a reboot would make the original /lib available again at boot time. The data is still there, just hidden by the mount, right? Best Regards, Robert Laughlin
Re: moving /lib - off topic advice wanted
Perhaps I am wrong, I expected that a reboot would make the original /lib available again at boot time. The data is still there, just hidden by the mount, right? mounting only occurs after fstab is processed. you can't process fstab with the mount command if there are no libraries for mount to rely on. see the problem? -sv
Re: moving /lib - off topic advice wanted
Nope, sure don't. My new /lib *partition* mount is not even in /etc/fstab. What will happen at boot time is the /lib *directory* on the / partition will be available. Right? I never deleted the data in that partition. I just mounted my new /lib *partition* on top of it for test. Best Regards, Robert Laughlin On Wed, 20 Oct 1999, Seth Vidal wrote: Perhaps I am wrong, I expected that a reboot would make the original /lib available again at boot time. The data is still there, just hidden by the mount, right? mounting only occurs after fstab is processed. you can't process fstab with the mount command if there are no libraries for mount to rely on. see the problem? -sv
Re: moving /lib - off topic advice wanted
if your init and mount are not statically linked, how on earth are they going to work before /lib is mounted? or wait, suppose you could just keep in the real /lib only libs needed for init, mount and whatever other basic commands on boot (for instance if you have to boot "linux single" one day or something). on my system: # ldd /sbin/init libc.so.6 = /lib/libc.so.6 (0x40018000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) # ldd /bin/mount libc.so.6 = /lib/libc.so.6 (0x40018000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) so if you could get away w/ just having those two libs you'd be SET. however take a look at login here, things may not be quite so cozy for "linux single" after all.. # ldd /bin/login libcrypt.so.1 = /lib/libcrypt.so.1 (0x40018000) libpam.so.0 = /lib/libpam.so.0 (0x40046000) libpam_misc.so.0 = /lib/libpam_misc.so.0 (0x4004e000) libdl.so.2 = /lib/libdl.so.2 (0x40051000) libc.so.6 = /lib/libc.so.6 (0x40055000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) a quick ls shows that this might not be so bad... # ls -sh1 /lib/libcrypt-2.1.2.so /lib/libdl-2.1.2.so /lib/libpam.so.0.70 /lib/libpam_misc.so.0.70 /lib/libpamc.so.0.70 /lib/libc-2.1.2.so /lib/ld-2.1.2.so 81k /lib/ld-2.1.2.so 875k /lib/libc-2.1.2.so 20k /lib/libcrypt-2.1.2.so 10k /lib/libdl-2.1.2.so 28k /lib/libpam.so.0.70 6.0k /lib/libpam_misc.so.0.70 9.0k /lib/libpamc.so.0.70 another thing to take into consideration is which modules you'll need before mount. initrd is your friend in that case i guess. just some stuff to consider. my system is debian potato so YMMV, but the numbers shouldn't be wildly different. -- stephen waters amicus, inc. Seth Vidal wrote: Nope, sure don't. My new /lib *partition* mount is not even in /etc/fstab. What will happen at boot time is the /lib *directory* on the / partition will be available. Right? I never deleted the data in that partition. I just mounted my new /lib *partition* on top of it for test. oh. I see now. that should work. Might be weird in the moments of the mount. hmm. good luck. -sv
