My plan was to do a networkless installation on: /dev/hda1 --> /boot /dev/hda2 --> swap /dev/hda3 crypted and remapped as /dev/mapper/root --> / /dev/hda4 (ntfs non-mounted) I enter this into the gtk-installer (installer-dialog does not enable entering mapped dev-nodes) and everything went fine until the installation of grub. Logfiles to be attached. If there is anything more you need, just ask.
Created attachment 119558 [details] /var/log/installer.log.failed
This happened because of the assumption in the grub configuration code that a dev node ends with a number. Although, this shouldn't have happened, anyway. It appears that there's an incorrect assumption that when looping through the mounts, /boot will come before /. Codeman, can you look at this?
Actually, doesn't a cryptoloop / require a custom initramfs? If so, there's no possibility the installer will ever support it unless genkernel supports it directly.
I have the source for gentoo-sources and genkernel and its deps on a USB-stick to be able to chroot into the installation afterwards and doing a "emerge gentoo-sources genkernel && genkernel all --luks --menuconfig" to compile the needed things into kernel. This also gives a luks-ready initramfs. The fact that the installer fails is the only thing that prevents me to make this happend.
Is this not a issue for evms/lvms and /dev/mapper in general? Just to make my previous comment more clear: From my experiences the only thing preventing the networkless installer from support luks as-is is some things in livecd-kernel being compiled as module, (I believe) the initramfs being generated without luks-support (the --luks flag for genkernel) and most critical this bug. If this was fixed then the only missing thing for me should be adding "crypt_root=/dev/hda3" to the arguments passed to the kernel at boottime, and as the installer support this... But it is enough fixing this bug as it seems like the installer is the only way makeing a networkless install on x86 according to the docs I have found.
The installer doesn't (and probably won't) support non-standard setups like this. If you want it to, please submit a patch.
