mån 2003-07-21 klockan 15.16 skrev Ole-Egil Hvitmyren: > And prep and a few others don't use a filesystem on the boot partition, > so same applies here. There's no reference to the boot partition in fstab. > But still, /etc/fstab never hurt anyone, so I fail to see how > bootable-system depending on created-fstab is bad? bootable-system is a virtual package provided by boot loader installers (I don't know how it works for archs without boot loaders though). I see no problem whatsoever with debootstrap depending on created-fstab to make sure that it actually has been configured before reboot. Some boot loaders need /target/etc/fstab, they should depend on created-fstab. Others do not, they should not depend on created-fstab. It really is that simple. :-) However, a much bigger problem is the following: * User partitions his hard drive, creates some file system and mounts them on /target/... * User installs base, and a boot loader that requires /target/etc/fstab (at this point, the virtual package created-fstab will be configured, or rather, the package that provides it) * User realizes he actually wants to have /target/home on a separate partition and arranges that. No problemo, base-installer, kernel-installer and friends don't touch /target/home, so this is clean. * User reboots, but /home is not mounted, because /target/etc/fstab has not been regenerated. This, in my opinion, is a general design problem in d-i. How do we fix it? Of course we can hack around it by *always* regenerating fstab in prebaseconfig, but what if the user has manually adjusted the fstab? /Martin -- Martin Sjögren martin@strakt.com Phone: +46 (0)31 7490880 Cell: +46 (0)739 169191 GPG key: http://www.strakt.com/~martin/gpg.html
Attachment:
signature.asc
Description: PGP signature