4

I am just trying to figure out if this is possible to do. I am trying to resize a number of filesystems, and to be safe (these are production boxes as well as QA) I wanted to do the resize offline.

I have gotten into the server with single user mode and am having no issues unmounting /var, and /opt. However I cannot unmount /.

Any ideas would be appreciated, using a rescue cd is not an option.

Pierre.Vriens
  • 1,159
  • 34
  • 15
  • 19
Matthew
  • 2,666
  • 8
  • 32
  • 50

2 Answers2

6

You certainly cannot unmount / ; you could perhaps first pivot_root to another / then umount the previous /, but there always has to be a /, and you cannot unmount a filesystem in use (and if it is /, it must be in use).

Are you needing to grow or shink the partition? Some filesystems (such as ext2/ext3/ext4) will allow online growing, but not necessarily shrinking. (using resize2fs). You'd have to resize the partition from underneath the filesystem first.

This is all to be considered dangerous, and it would be wise to have a full backup before starting.

stew
  • 9,263
  • 1
  • 28
  • 43
  • This is to grow the partition. The use of pivot_root makes sense with the use of a rescue cd, and it explains why all of the questions I've found on google mention using a rescue cd. The partition has been resized already (using lvm2) and we are using ext3. The concern I am getting from above is the safety of doing it online, since, as I said, this process is to be used on production machines. – Matthew Dec 14 '11 at 20:57
  • yes, pivot_root in this situation requires that you've bootstrapped a new / (basically a separate install) on some other partition. it would be cumbersome. – stew Dec 14 '11 at 20:59
  • I understand your trepidation about an online resize. I *do* believe it is pretty safe. I know it is only anecdotal, but I've done it dozens of times. I've had it refuse to operate with old filesystems, but never cause data loss / corruption. – stew Dec 14 '11 at 21:00
  • I think I'm going to give the online resize a go-ahead. Luckily we're still in testing in QA, and the prod boxes aren't actively used (yet), so there are very few people using the boxes. That should reduce any complications (knock on wood). Thanks for the advice! – Matthew Dec 14 '11 at 21:07
  • The pivot_root to tmpfs is not that hard, it worked really well for me to unmount and resize a root filesystem that didn't allow online resize. Can even do it without a reboot (but I rebooted to clean up at the end). This guy wrote a howto: http://www.ivarch.com/blogs/oss/2007/01/resize-a-live-root-fs-a-howto.shtml but it can be even easier. You have to know what you're doing! I have a remote console (prgmr.com service), so no need to keep ssh or the network up. Didn't copy anything from /usr so only 150MB RAM neede for tmpfs. `telinit u` to restart init so it lets go of the old root. – Sam Watkins Oct 17 '13 at 03:35
  • Didn't feel the need to backup the system. I'm confident with fdisk and resize2fs, and the pivot_root isn't dangerous in itself. I do have my important code and data replicated of course. – Sam Watkins Oct 17 '13 at 03:36
0
  1. Alt+Shift+F1 to activate the console screen.
  2. Press keys: Alt+SysRq, R, E, I, S, U.
  3. Use needed disk commands: fdisk, dd, etc.
hacknull
  • 1