[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Etch Software RAID Upgrade Trouble & Suggested Installer Improvements

Claus Fischer <claus.fischer@clausfischer.com> writes:

> On Tue, Jan 09, 2007 at 09:11:57PM +0100, Goswin von Brederlow wrote:
> : > 4. Netinstall image should have some packages
> : >
> : >    I'm not sure on that ... but having grub, a
> : >    kernel and a modules package would have been
> : >    an immense help.
> : 
> : They used to be on there. Are you sure you have a netinst and not
> : mini.iso/netboot or businesscard image?
> Yes, I had. I'll take that point back; you're right.
> What I would have needed, however, is a way to get to the
> stage where one can install onto the target, without
> overwriting the fstab or modifying the target's
> partitions.

You can configure all the partitions and set them to use as is,
without formating. But debootstrap won't run cleanly if there is
already a system on there in my experience.

> : >      - leave out lost+found
> : 
> : Why?
> Because the lost+found directory (NOT its contents)
> is quite misleading when copied to a target system that
> has no 'mount boundary' there. I.e., when the source
> has /tmp/lost+found, but the target has /tmp directly
> on root, the source's /lost+found shouldn't be copied.
> Just like e.g. the journal 'file', but that one's not
> needed for the user generally so you can hide it always.

Except when you try to rescue all possible data from abroken system
where lost+found might contain valuable contents. I would rather have
them included in an emergency backup.

> : >      - leave out /proc, /sys, the automatic /dev
> : 
> : use the same filesystem flag, or better see enxt comment
> Not so nice for about six mounted partitions.
> : >      - copy all "real" files
> : >      - copy the /dev on harddisk under the mounted devfs
> : >        (using mount -bind or so)
> : 
> : Why do you have an devfs mounted? But if you do or have udev there
> : then the dir is lost.
> (Not fully, see mount -bind. I've tried it recently and it worked.)
> : Mount the device again under a different mountpoint without any
> : submounts. No devfs, no udev, no proc, no sys. Then you can just copy
> : the whole thing.
> Basically mount -bind.
> : >    There is really need for a good program that does it;
> : >    IMHO that program should be cp.
> : 
> : rsync. That also works when you have to copy over the network. And
> : include the ssh.udeb on the image.
> Yes, it's doable; in fact, I used rsync.
> But with the various virtual file systems (/proc, /sys, /dev),
> in particular with underlying real ones (/dev), with special
> files like list+found, with access control lists etc.
> it has become very hard to do the equivalent of
>   "copy all real files with attributes to new location"
> I didn't say it was undoable, it's just become a PITA.

Does rsync know about attributes? I would want to include lost+found
and all the other filesystems are easily avoided by using a different
m,ount point or limiting to one filesystem. So for me that only leaves
special attributes out in the cold.

> : wodim <iso-file>
> Someone pointed that out already, and I'll look into it.

At least on a normal system that works. Not sure if a rescue system
would have the right links in /dev. But if you find out that they
don't then that is something to fix after creating a wodim.udeb for
the rescue mode.

> Thanks for your comments
> Claus


Reply to: