Hello @rjo74618,
Thank you for taking your time to offer your input, and for trying to make sense of this confusing problem.
I actually came across that same topic during my searching here for potentially related threads. While it has some similarities to this, the solution found there appears to be to format the raw device. That is exactly what I am trying to avoid because formatting sda prior to encryption and LVM partitioning introduces visible structure to the raw device, including a cleartext partition table.
I understand that I am most likely able to proceed with installation if only I format sda with something like ext4 and add an MBR table at the beginning of the disk, since that is what Anaconda is complaining about (the lack of any MBR). That precludes my goal of deniable full-disk encryption on the main drive, however, and renders it as a mainly standard installation. At that point, I have much less incentive to store /boot on a separate USB drive (sdb) as well, since the partition table will already be a dead give-away that the disk is likely more than just random junk data.
I suspect you may be right that Anaconda just does not know what to do with a raw device other than to insert a partition table, despite being able to see the well-defined structure and partitioning inside the unlocked LUKS volume. This is very unfortunate, and seems to be a clear limitation of the installer if not altogether a bug (though the Red Hat/Fedora developers will of course claim it is a “feature”). Other installers, particularly “bottom-up” ones like those used by Debian and Ubuntu and especially minimal bootstrappers like pacstrap and debootstrap, do not limit the user’s freedom in this way. And it seems that I am not the only one who has experienced this, either, as this Fedora 16 bug report from 2011 shows (closed as WONTFIX). It was perhaps put best on the [qubes-users] mailing list: Anaconda is “ugly wood”.
I previously attempted to explore the possibility of a “partitionless” or “superfloppy” installation (more specifically, a raw data disk drive without any VBR/MBR/GPT partition table) in my first post on this forum, very early on in this saga, because I anticipated that the Anaconda installer might not be friendly to such custom setups. That unfortunately went nowhere, so I am now circling back to where I started; only this time, I am afraid I may have to conclude that this whole month-long journey was toward a dead end.
At this point, I am more than happy to just manually install Qubes OS from scratch if at all possible, through a series of terminal commands that implements what the Anaconda installer would otherwise do for me, like pacstrap in Arch or debootstrap in Debian. If necessary, I am willing to consider writing my own Kickstart file if that can achieve what I want. I am completely comfortable with the command line and would love nothing more than to bypass Anaconda altogether, but the chances of that look bleak.
I am still hoping that this is just a bug that I can hotfix in the installer or somehow circumvent by manually assigning mountpoints from the terminal and forcing an installation, but I do not know how I can go about doing that from here. The “Begin Installation” button remains grayed out because Anaconda still insists that I configure the “Installation Destination”, despite having a fully configured system ready and mounted from tty2. If only I could skip that step, rather than continue to be treated like an idiot by Anaconda, I would be running Qubes OS right now.
I left Windows years ago because I felt myself pushing up against the walls of the OS environment, handcuffed and prevented from tinkering any further with a system that treats me like it knows best better than I do. I did not feel free. I am beginning to feel that way about Fedora now, right out of before the gate, with this Anaconda installer being my first exposure to it. I hope a solution can be found for this problem of mine that does not involve reverting back to a more standard installation. If not, then I may have to proceed with one and restructure the system post-installation, but that should not have to be done and I would not know where to start anyway.
If you have any further ideas or advice, I am willing to entertain just about any creative solution you can imagine. I know this is not your field of expertise, as you said, but your willingness to help is admirable. Thanks again for your time.
Kindest regards,
John