SEO

Why not just umount /dev/u, exposing /u directory which is now under root.
Restore the /u filesystem, change /etc/default/filesys to not mount /dev/u
to /u.

brian@aljex.com <brian@aljex.com>
>Yes, but it's not possible without doing a full tape backup & restore.

>Any of the supertars can fdisk and reformat a hard drive during restore
>so using one of those you can do a full master backup, with bit-level
>verify enabled, then do another, and if both suceeded without error
>then you can boot to the restore floppy, use the recovery software
>advanced options to override the defaults and create one big fs (don't
>forget to retain swap and recovery spaces though) and then restore onto
>that, and /u will just be a directory after that.

>I suggest doing the restore onto another disk rather than blowing away
>the original disk however.
>There is certainly a lot of ways to botch this and if you are asking
>the question then you obviously do do this routinely, and so, better
>restore onto a different disk so that you can always plug the original
>disk back in and resume running on that no matter what happens.

>supertars = backupedge / lonetar / ctar
>install any of their demos if you don't have one of them already, then
>buy it and instruct the customer to change tapes every day and take one
>home every night.

"R Squared News" <rtr@rsquared.com> wrote in message
news:FJSdnSYRGt5Y9dTfRVn-hg@rcn.net...
> Why not just umount /dev/u, exposing /u directory which is now under root.
> Restore the /u filesystem, change /etc/default/filesys to not mount /dev/u
> to /u.
>
That would certainly work, assuming he isn't trying to reclaim the space
that is currently in use by the /u filesystem.

For that matter, if he doesn't care about getting the space back, he can
just copy -vorm /u /u.new. (Unless there are sticky bit issues.)

Then, do what you suggest and unmount /u and edit /etc/default filesys.
(However, I would prefer to do a mkdev fs and remove /u all together so
there is no chance of it getting accidentally remounting and causing a lot
of confusion.)

Then, he can just delete the /u mount point and mv /u.new /u.

Fabio

> Then, do what you suggest and unmount /u and edit /etc/default filesys.
> (However, I would prefer to do a mkdev fs and remove /u all together so
> there is no chance of it getting accidentally remounting and causing a lot
> of confusion.)
> Then, he can just delete the /u mount point and mv /u.new /u.

That's what I've done.
But before, I installed Bru and made a full back-up and a recovery
boot disc in case of!!!

Your solution worked. And I did'nt have to restore the system.
My chance was that the system has only few hours of life and /u was
made inadvertently.


Thank's a lot everybody,

Michel

R Squared News typed (on Tue, Mar 29, 2005 at 09:40:05AM -0500):
| Why not just umount /dev/u, exposing /u directory which is now under root.
| Restore the /u filesystem, change /etc/default/filesys to not mount /dev/u
| to /u.
|
| brian@aljex.com <brian@aljex.com>
| >Yes, but it's not possible without doing a full tape backup & restore.
|
| >Any of the supertars can fdisk and reformat a hard drive during restore
| >so using one of those you can do a full master backup, with bit-level
| >verify enabled, then do another, and if both suceeded without error
| >then you can boot to the restore floppy, use the recovery software
| >advanced options to override the defaults and create one big fs (don't
| >forget to retain swap and recovery spaces though) and then restore onto
| >that, and /u will just be a directory after that.
|
| >I suggest doing the restore onto another disk rather than blowing away
| >the original disk however.
| >There is certainly a lot of ways to botch this and if you are asking
| >the question then you obviously do do this routinely, and so, better
| >restore onto a different disk so that you can always plug the original
| >disk back in and resume running on that no matter what happens.
|
| >supertars = backupedge / lonetar / ctar
| >install any of their demos if you don't have one of them already, then
| >buy it and instruct the customer to change tapes every day and take one
| >home every night.
|
R Squared News typed (on Tue, Mar 29, 2005 at 09:40:05AM -0500):
| Why not just umount /dev/u, exposing /u directory which is now under root.
| Restore the /u filesystem, change /etc/default/filesys to not mount /dev/u
| to /u.

Robert... how you doin?? :-)

Any symlinks vs regular links to deal with?
Just because /u was no longer mounted would not remove the real
data on the /u partition... nor free up the space occupied by the
/u mounted partition weither the data was removed or not.
I personally like having a /u partition even if only one HD.

- Jeff Hyman

In article <20050331163908.GA4603@lonestar.cactus.com>,
Jeff Hyman <scolist@cactus.com> wrote:
>R Squared News typed (on Tue, Mar 29, 2005 at 09:40:05AM -0500):
>| Why not just umount /dev/u, exposing /u directory which is now under root.
>| Restore the /u filesystem, change /etc/default/filesys to not mount /dev/u
>| to /u.
>|
>| brian@aljex.com <brian@aljex.com>
>| >Yes, but it's not possible without doing a full tape backup & restore.
>|
>| >Any of the supertars can fdisk and reformat a hard drive during restore
>| >so using one of those you can do a full master backup, with bit-level
>| >verify enabled, then do another, and if both suceeded without error
>| >then you can boot to the restore floppy, use the recovery software
>| >advanced options to override the defaults and create one big fs (don't
>| >forget to retain swap and recovery spaces though) and then restore onto
>| >that, and /u will just be a directory after that.
>|
>| >I suggest doing the restore onto another disk rather than blowing away
>| >the original disk however.
>| >There is certainly a lot of ways to botch this and if you are asking
>| >the question then you obviously do do this routinely, and so, better
>| >restore onto a different disk so that you can always plug the original
>| >disk back in and resume running on that no matter what happens.
>|
>| >supertars = backupedge / lonetar / ctar
>| >install any of their demos if you don't have one of them already, then
>| >buy it and instruct the customer to change tapes every day and take one
>| >home every night.
>|
>R Squared News typed (on Tue, Mar 29, 2005 at 09:40:05AM -0500):
>| Why not just umount /dev/u, exposing /u directory which is now under root.
>| Restore the /u filesystem, change /etc/default/filesys to not mount /dev/u
>| to /u.

>Robert... how you doin?? :-)

>Any symlinks vs regular links to deal with?
>Just because /u was no longer mounted would not remove the real
>data on the /u partition... nor free up the space occupied by the
>/u mounted partition weither the data was removed or not.
>I personally like having a /u partition even if only one HD.

Hi Jeff.

I'll go along with separate partitions. It keeps the OS on one
partition with no user and/or application polution.

What that means is that when it's time to perform anything that
may require a driver addition and/or a relink, I'll unmount
the /u [and all others] and leave one the OS - typcally under
1GB.

Once unmounted I'll use LT or BE [depending on client] and backup
the entire OS partition. Typically 5 to 10 minutes and well worth
it.

Then I do the OS work, and reboot, and if thing are OK all I've
done is take 10 extra minutes to make a backup of the OS as
it stood immediately before the work.

I started doing this after learning the hard way - really hard - on
a client system that just grew and grew.

Years ago when a driver failed to install, it's removal script
took out parts of the OS in addition to it's one detritus.

Same system - years later - something went awary and kernels could
not be relinked. And things were left in an fragile state.

The system was going to have the OS upgraded in about 6 months, so
the OS was not upgraded to fix the problem deep down. But
when this happened all I did was boot to the emergency floppies,
and I >>remade< the OS file system to be sure nothing was left that
was not suposed to be there, and then loaded the OS partition
I had made just before I started this.

This may not seem to be of too much concern on small systems,
but if you don't split things and have a large OS partition,
the reload of the OS will take a lot of time, so much so that often
you don't backup the OS prior to the work.

And anothter plus - is that if there is any corruption when you may
have to reload the OS where something when wrong, I've found
that if any FS is going to be corrupted it is almost invariably
/ and that all other partitions usually survive intact.

Bill


--
Bill Vermillion - bv @ wjv . com