SUMMARY: Moving /usr From Under Root "/" To Its Own Partition

• Previous message: sunmanager_at_topsoft.ca: "Ultra 1 and E220R max memory module size"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Wed, 04 Jun 2003 13:28:53 -0400
To: <sunmanagers@sunmanagers.org>

First, thanks to all who responded:
Joe Ritter
Ian MacPhedran
Darren Dunham
Ravi Kumar
Hichael Morton
Julie Baumler
Crist Clark
Charles Homan
David Beard
Mark Cain
Andrew Maddox
Karl Vogel
devnull
Dave Mitchell, and,
John Timon

The original post is at the bottom. I have also included
everyone's responses. I should have also mentioned that I am running
Solaris 8.

Couple of comments on the responses:

1. The consensus seemed to be that doing this whole evolution (as
originally described) in single-user mode
     would be a good thing.

2. Several folks noticed that I had missed some steps where I would
need to (between the original steps h. and i.):
mkdir /usr
chown root /usr
chgrp sys /usr
chmod 755 /usr

3. There was a lot of discussion about how/when to rename the original
/usr and the issues involved with doing so.
     One of the reasons for doing this is to end up with a smaller root
parition on the new drive
     (local tape capacity issue).

4. Julie's comments about using Live Update are intriguing. I plan on
looking at this.

5. Don't use the "c" option in ufsdump.

6. The alternatives to using ufsdump/ufsrestore. tar, etc.

7. Make sure to set 'mount at boot' to 'no' for the new /usr

After mulling over everything for a bit and talking it over locally,
another
approach that we think will work comes to mind.
1. Dump/restore /usr to its own parition on the new drive.
2. Create a temporary slice on the new drive large enough to hold the
existing
root parition (including /usr).
3. Dump/restore from the existing root slice to this temporary root
slice.
4. Mount the temporary root slice as /dave, delete usr under /dave and
change
     the device names in etc/vfstab under /dave.
5. Dump/restore the temporary root slice (now smaller because we have
deleted usr)
     on the new drive to the permanent root slice on the new drive
(c1t2d0s0)
6. Install the boot block and boot off the new drive.
7. Reslice and finish moving the remaining filesystems from the old to
the new.

The nice thing about this approach is that I still have the exisiting
drive, untouched,
if I need to fall back.

Thanks again everyone,

Dave

==================================================

>From John Timon:
----------------
Why not boot off of the cdrom, dump and restore the /usr to the new
slice,
edit /etc/vfstab and reboot

>From Dave Mitchell:
-------------------
On Tue, Jun 03, 2003 at 02:39:17PM -0400, Dave Warchol wrote:
> h. mv /usr /usr_prev (do I need to do this in single user mode?)
> i. Reboot

you also need h2. mkdir /usr.
You will probaly need to be booted off a CD when you do this, as the
mkdir and rebot commands will no longer be found under /usr, and even
if
you use their current path, the shared libraries they link against
will
not be found.

>From devnull@adc.idt.com:
-------------------------
Here is something to think about, lifted directly from Christopher A.
Petro' "fix solaris"

" In order for the root partition to be fscked and remounted
read-write,
  the system needs to be able to run fsck. Generally this isn't a
  problem, but because of the way some of the system binaries are
installed, it can
  be.

  Let's take a look at /sbin/fsck...

  ls: /sbin/fsck: cannot open file: No such file or directory

  GAK! It's not there. It's actually in /usr/sbin/fsck, which means
  that Solaris needs to mount /usr before it can fsck the root
  partition. Now, /usr is the sort of partition that's likely to get
  updated a lot, and therefore is likely to not mount cleanly during
  boot. This means that if /usr won't mount, not only can Solaris not
  fsck the root partition, it can't even fsck /usr to clean it up
enough
  to mount it read-only."

I dont think this is a big problem, you could always have logging
enabled,
if you are running 8 or 9

> f. ufsdump 0ucf - /usr | ufsrestore xf
Would tar be easier ?
cd /usr
/usr/local/bin/tar cvf - * | ( cd /usr2 && /usr/local/bin/tar xvf -)

Watch for symlinks if needed.

> h. mv /usr /usr_prev (do I need to do this in single user mode?)
That's what i would do.
> i. Reboot
sync;sync; reboot :)

Good Luck,

Since you have the /usr_prev, i think you should be ok...

>From Karl Vogel:
----------------
>> On Tue, 03 Jun 2003 14:39:17 -0400,
>> "Dave Warchol" <Warchol@harthosp.org> said:

D> I need to move /usr from under root "/" to its own partition (space
and
D> backup issues). The system is currently running under c1t1d0, with
one
D> large root partition. I don't have any space that I could use
D> temporarily on the existing disk. This is one piece in migrating
from a
D> smaller (c1t1d0, 18G) disk to a larger one (c1t2d0, 36G). The
steps
D> that I have are:

D> h. mv /usr /usr_prev (do I need to do this in single user mode?)

   Just make sure the mv is the absolute *last* thing you do before
   rebooting because all the libraries under /usr will become
   inaccessible, and nothing will work except static binaries.

   I created a new vfstab file, compiled a static version of "mkdir"
   and followed these steps when moving /usr:

        root# cd /usr
        root# mount /dev/dsk/c2t0d0s0 /newusr
        root# find . -print | cpio -pdumv /newusr
        root# sync
        root# cd /
        root# umount /newusr
        root# fsck /dev/rdsk/c2t0d0s0
        root# mv /usr /old.usr
        root# /sbin/mkdir /usr
        root# mount /dev/dsk/c2t0d0s0 /usr
        root# mv /etc/vfstab.newusr /etc/vfstab

   All the open files under the original /usr were still open under
   /old.usr, so at this point I rebooted.

   If you're going to keep the smaller disk, it may help to evenly
divide
   your swap space between both drives.

>From Andrew Maddox:
Sounds mostly fine, but one or two notes:

you don't need to change the name of /usr - you absolutely don't want
to, in
fact! What you want to do is just change vfstab to mount the new copy
of
everything in place of the old slice. Don't do anything to the
original
partition, just let it not be mounted. If you need to revert, you can
boot
from CD (or maybe into single-user mode) and change vfstab back, so
keep
both lines in there.

Using ufsdump/ufsrestore is good, either that or a tar piped to the new
FS
to retain ownerships and permissions.

Oughta work, though. Good luck!

>From Mark Cain:
---------------
>
> Hello:
> I need to move /usr from under root "/" to its own
partition
> (space and backup issues). The system is currently running under
> c1t1d0, with one large root partition. I don't have any space that
I
> could use temporarily on the existing disk. This is one piece in
> migrating from a smaller (c1t1d0, 18G) disk to a larger one (c1t2d0,
> 36G). The steps that I have are:
>
> a. Document and backup everything first.
> b. Create a new directory under root, /usr2
> c. Run newfs on c1t2d0s4 build the filesystem on the new usr
> patition on c1t2d0s4
> d. mount /dev/dsk/c1t2d0s4 /usr2
> e. cd /usr2
> f. ufsdump 0ucf - /usr | ufsrestore xf

I'd use ufsdump 0f

I think the c indicates a cartridge, and the default cartridge size
may not be large enough for you to copy your entire /usr directory.

Also, I'd not want to modify the dumpupdates file when doing a
directory
or partition copy.
 
> g. Change /etc/vfstab to include /usr as a filesystem
> h. mv /usr /usr_prev (do I need to do this in single user mode?)

Ouch. I'd do this while booted over the network or off a CD if
possible.
Once you've moved /usr, most of your commands (including the mv and
reboot commands) would probably fail.

You might be able to do the move and then stop-A and sync, but you
still have
to create a new /usr for the new partition to be mounted on and that
could
be difficult at this point.

It sounds like there's plenty of room on the new drive, so if you
can't
boot from the net or off a CD, just copy the existing root partition
over
to the new drive at a location where it won't interfere with your
new / and /usr partitions, modify the vfstab to refer to the
new partition, install the bootblock and boot off of the copy. Then
you
can do your rearranging while not using the old root directory.

> i. Reboot
> j. When comfortable that everything is ok, remove /usr_prev
> (reclaim space).
> k. Migrate the remaining partitions from the small disk
to
> the large disk, install the bootblk on the large disk and boot off
the
> large disk....

You probably need to modify the boot prom settings (nvram??) to use
the
new disk to boot from.

And I'd run fsck on the new partitions before using them and probably
try
to do a full backup (in single user mode) as soon as possible after
moving
them to give me a "reliable" starting point for backups. Actually,
I'd
fsck after doing the newfs also.

- Mark

>
> Just want to make sure (in advance) that I haven't missed anything.
If
> there is a better way, I am all ears.... I will summarize.
>
> Thanks
> Dave

>From David Beard:
-----------------
One crucial step you've forgotten - you'll need to rename /usr2
to /usr before rebooting. That'll be a little tricky once
you've renamed "/usr" though - /usr/bin/mv also needs some
runtime libraries (try ldd /usr/bin/mv), so you might need to
experiment with setting LD_LIBRARY_PATH to look at /usr2/lib
(et al) first, and use the new pathname for mv "/usr2/bin/mv

You might also want to check that /usr2 has the right file &
group ownerships and protection mask before and after mounting
it ...

I would do the whole lot in single user mode to ensure that /usr
remains quiescent during the dump/restore.

Oh - your usfrestore command is missing a "-" at the end.

Sorry I can't be more precise, I'm ad-libbing from home.
I hope this helps.

>From Charles Homan:
-------------------
I'm not sure you should move /usr even in single-user mode. You
definitely
won't like the results if you do it in multi-user mode.

Second, between steps "h" and "i" you need to "mkdir /usr" (since you
just
moved the directory you now have no /usr mount point.)

If it were me, I would boot from cdrom ("boot cdrom -s") then do the
steps
you mentioned (after mounting the root partition to "/a" - and
pre-pending
all of the paths you mention with "/a".) This has the advantage of
making
sure that nothing can change on the partition between the time you dump
it
to the new disk and the time you mount the new partition in the right
place.
The disadvantage is the length of the downtime is obviously greater.

Here's a question, though: if the goal is to migrate the whole machine
to
the new disk, why not do it all at once? You could use the same basic
methodology, but dump the entire root partition onto the new disk (also
as
one partition) and be done with it. Again, if done when booted from CD
you
don't have to worry about anything changing. Then install your
bootblock,
modify vfstab to point to the new disk, and you are done.

>From Crist Clark:
-----------------
>
> Hello:
> I need to move /usr from under root "/" to its own
partition
> (space and backup issues). The system is currently running under
> c1t1d0, with one large root partition. I don't have any space that
I
> could use temporarily on the existing disk. This is one piece in
> migrating from a smaller (c1t1d0, 18G) disk to a larger one (c1t2d0,
> 36G). The steps that I have are:
>
> a. Document and backup everything first.
> b. Create a new directory under root, /usr2
> c. Run newfs on c1t2d0s4 build the filesystem on the new usr
> patition on c1t2d0s4
> d. mount /dev/dsk/c1t2d0s4 /usr2
> e. cd /usr2
> f. ufsdump 0ucf - /usr | ufsrestore xf
> g. Change /etc/vfstab to include /usr as a filesystem
> h. mv /usr /usr_prev (do I need to do this in single user
mode?)

This is going to _really_ mess up the system (remember that /bin is
really a symlink to /usr/bin). I don't even think single-user mode
is good enough, unless you are implicitly indicating boot to
single-user
mode off of different media.

> i. Reboot
> j. When comfortable that everything is ok, remove /usr_prev
> (reclaim space).
> k. Migrate the remaining partitions from the small disk
to
> the large disk, install the bootblk on the large disk and boot off
the
> large disk....

I would, starting from your (d), being as safe as possible,

  d. Bring down system, boot off of other media (CDROM, netboot, etc.)
     into single user.
  e. mount /dev/dsk/c1t1d0s0 /mnt
  f. mount /dev/dsk/c1t2d0s4 /mnt/usr2
  g. cd /mnt/usr2
  h. ufsdump 0f - /mnt/usr | ufsrestore xf -
  i. Change /mnt/etc/vfstab to include /usr as a filesystem
  j. mv /mnt/usr /mnt/usr_prev
  k. mkdir /mnt/usr
  l. umount /mnt/usr2
  m. rmdir /mnt/usr2
  n. Reboot
  .
  .
  .

Alternately, you can still try the backup on the live filesystem, but
I'd still boot the root filesystem and /usr off of different media
before I'd try move /usr around.

>From Julie Baumler:
-------------------
While what you are planning to do looks fine, when we do this, we use
Live
Upgrade to build a new boot environment on the new disk; Live Upgrade
takes
care of everything from newfs to copying the data to setting the eeprom
so
the proper disk boots. It makes it particularly easy to split,
combine,
grow or shrink partitions. I simply use: "lucreate -c old -n new" and
then
assign partitions using the F-keys, after it is done copying, you
simply run
"luactivate new", and reboot onto the new disk. If you need to go
back, you
simply run "luactivate old" and reboot. It's easy, does most of the
work
for you, and is supported by Sun if you run into problems.

>From Hichael Morton:
--------------------
do everything in single user mode.
   safer
   quicker

sun's bigadmin site has a script to clone disks or paritions.
www.sun.com -->system administrators-->scripts
being a script, it can be modified for your specific needs.
it is quick and works flawlessly from my experience.

>From Ravi Kumar:
----------------
     i did the same thing on my machine a few weeks
back. the process u have suggested will work just
fine.

   - go into single user mode first
   - newfs the new partition
   - mount it
     $ mount /dev/dsk/cxtxdxsx /mnt

   - move /usr..i prefer to use tar
     $ tar cf - /usr | (cd /mnt; tar xf - )
   - add an entry to vfstab and reboot

  as a precaution, u can back up the root partition.
hope this helps.

>From Darren Dunham:
-------------------
>
> Hello:
> I need to move /usr from under root "/" to its own
partition
> (space and backup issues). The system is currently running under
> c1t1d0, with one large root partition. I don't have any space that
I
> could use temporarily on the existing disk. This is one piece in
> migrating from a smaller (c1t1d0, 18G) disk to a larger one (c1t2d0,
> 36G). The steps that I have are:
>
> a. Document and backup everything first.
> b. Create a new directory under root, /usr2
> c. Run newfs on c1t2d0s4 build the filesystem on the new usr
> patition on c1t2d0s4
> d. mount /dev/dsk/c1t2d0s4 /usr2
> e. cd /usr2
> f. ufsdump 0ucf - /usr | ufsrestore xf

Generally you'd use 'r' instead of 'x' for transferring an entire
filesystem.

> g. Change /etc/vfstab to include /usr as a filesystem

Make sure you set 'mount at boot' to 'no'.

> h. mv /usr /usr_prev (do I need to do this in single user mode?)

Safest of all would be to do it while booted from a cdrom, but it
should
be okay. You will not be able to run any dynamically linked program
at
that point, so most shutdown scripts will fail (as would 'reboot' and
'halt'). You could probably just remount your new disk into /usr
though
(since /sbin/mount is static).

> i. Reboot
> j. When comfortable that everything is ok, remove /usr_prev
> (reclaim space).
> k. Migrate the remaining partitions from the small disk
to
> the large disk, install the bootblk on the large disk and boot off
the
> large disk....
>
> Just want to make sure (in advance) that I haven't missed anything.
If
> there is a better way, I am all ears.... I will summarize.

Sounds okay to me. However if you're moving root to the larger disk,
why not do it all at once?

ufsdump|ufsrestore all partitions onto 36G
modify /etc/vfstab on 36G
installboot on 36G

reboot onto 36G

>From Ian MacPhedran:
--------------------
On Tue, 3 Jun 2003, Dave Warchol wrote:

> g. Change /etc/vfstab to include /usr as a filesystem
> h. mv /usr /usr_prev (do I need to do this in single user mode?)

Yes, and you'll also need to:

mkdir /usr
chown root /usr
chgrp sys /usr
chmod 755 /usr

after that.

> i. Reboot
> j. When comfortable that everything is ok, remove /usr_prev
> (reclaim space).

>From Joe Ritter:
----------------
You don't have to do this in single usermode no. You
just need to reboot after you have the /usr in place.

===Original Post===
Hello:
          I need to move /usr from under root "/" to its own partition
(space and backup issues). The system is currently running under
c1t1d0, with one large root partition. I don't have any space that I
could use temporarily on the existing disk. This is one piece in
migrating from a smaller (c1t1d0, 18G) disk to a larger one (c1t2d0,
36G). The steps that I have are:

a. Document and backup everything first.
b. Create a new directory under root, /usr2
c. Run newfs on c1t2d0s4 build the filesystem on the new usr
patition on c1t2d0s4
d. mount /dev/dsk/c1t2d0s4 /usr2
e. cd /usr2
f. ufsdump 0ucf - /usr | ufsrestore xf -
g. Change /etc/vfstab to include /usr as a filesystem
h. mv /usr /usr_prev (do I need to do this in single user mode?)
i. Reboot
j. When comfortable that everything is ok, remove /usr_prev
(reclaim space).
k. Migrate the remaining partitions from the small disk to
the large disk, install the bootblk on the large disk and boot off the
large disk....

Just want to make sure (in advance) that I haven't missed anything. If
there is a better way, I am all ears.... I will summarize.

Thanks
Dave
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers

• Previous message: sunmanager_at_topsoft.ca: "Ultra 1 and E220R max memory module size"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]