Re: Etch Software RAID Upgrade Trouble & Suggested Installer Improvements
Claus Fischer <firstname.lastname@example.org> 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
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