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
MfG
Goswin
Reply to: