The new menu entries did work but are reversed for some reason…the one I expected to go into Grub went straight in, and vice versa…I just rechecked; Ubuntu Menu points to the grub64 file, Ubuntu Direct points to the Boot64 file. Maybe I just understood these backwards.
The bad news is my dd from the Passport does NOT work; there are no partitions on the SDD at all. I’m not sure how to account for this, I should at least have got the partition table at the front with the DD command!
How did you run the dd?
I think the right way would be to just dd the devices: sudo dd if=/dev/sda of=/dev/sdb bs=1M status=progress
Where sda - your USB Passport drive and sdb - your SATA SSD.
Actually that’s exactly what I did do overnight (I said I’d be doing something more complicated, that was it). Well, I manually created identical partitions to sdc2, 3 and 4 as sdb 1, 2, and 3 in gparted, at least as close as I could get.
[Edit: After some experimenting, doing sfdisk -d and piping would have been bad, because it would still have carried over the /sda1 partition (which is at the END of the disk even though its #1) which seems to have caused confusion. I’d have wanted to edit its output to omit this partition and renumber the others, then feed THAT into sfdisk. In fact if I have to repeat this process (and I might, using another SSD, just to be safe) it beats the daylights out of trying to manually duplicate the partitions. Fdisk -l doesn’t show them looking exactly the same though it was evidently close enough to boot.]
While waiting on that I made changes to efibootmgr to show the SSD and the USB drive.
This time the SSD apprently did boot…once. The second time it never offered me the prompt to decrypt the drive and eventually presented me with the error message:
/dev/mapper/qubes-dom0-root does not exist
/dev/qubes-dom0/root does not exist
/dev/qubes-dom0/swap does not exist
And so on.
I eventually discovered it was booting off the USB (despite my selecting the SSD in the boot menu) when it was successful, and failing when the USB wasn’t plugged in. Still investigating why. But the boot menu lies to me, it’s not booting or trying to boot from where I’m telling it to go.
We know the qubes installer simply cannot see ANY Sata drive on my box. We thought we could get around this by installing to USB and copying it to a SATA SSD, then we had to donkey around with the efi stuff to get it to find it (and for that matter the USB drive).
What if the software responsible for booting Qubes ALSO can’t see SATA drives (including the drive its actually on)? At some point it’s handed a bunch of file paths and so forth, and so long as the USB drive is plugged in, it will find them (and think it’s on /dev/sda). But that means it essentially boots the USB drive.
If so there’s simply no way to boot Qubes off of ANY SATA drive on my motherboard. Period. I’m thinking that SATA-aware software is loading things from the SSD to a ramdisk, and handing control over to the ramdisk. But the software ON the ramdisk can’t see the SATA drive! It CAN see the USB drive, and proceeds to boot that, blissfully unaware that that’s not the drive it came from.
If the USB drive isn’t there, of course, it can’t find the files it needs to continue, and hangs.
If this is what’s going on, I can’t run off anything but the USB drive, and basically, until I buy new hardware, all I can really do is just play with Qubes…which I did quite a lot of on the first USB drive (before it “disappeared.”) Now I know how to fix the disappearing and I can do a lot more playing with Qubes [very educational], but I can’t make it my default system, yet.
I am pretty confident based on what I have done, that I can get Qubes configured for my particular use case, albeit still on a USB. I think I might even be able to migrate from the USB to a real system, when I have one, and not have to recreate everything.
It’s possible that Qubes cloned from USB drive to SATA drive won’t be able to see the SATA drive too.
But in your case the problem seems that:
You are booting with USB drive AND SATA drive connected. If you copied partitions the right way they should have the same IDs in blkid. The GRUB is looking for block devices with specific IDs to boot from and if you have two block devices with the same IDs then I don’t know what will GRUB do.
Or you didn’t copy partitions properly and they have different IDs so GRUB can’t find partition to boot from on SATA drive.
Also you can try latest Qubes ISO build with kernel-latest from here, maybe it’ll fix the problem with disk detection: https://qubes.notset.fr/iso/
They do have the same IDs in blkid. Which explains in part why the USB drive boots.
The problem is, if the USB drive isn’'t plugged in, the SSD won’t boot properly, at all. It’s not simply a matter of the two getting confused; it’s that the USB is needed under current circumstances.
This afternoon I created an SSD from the newer USB drive, this time using SFDISK to do a dump, correcting for the sector numbers, and then feeding that into the other. Thus the partituion table is effectively identical (other than the missing 3.5TB empty partition.
Same issue. I conclude (having eliminated everything else I can) that not only can the installer not see the SATA drives on my system; the boot software cannot either.
I am actually going to go buy new hardware tomorrow; I’ll attempt to persuade the store personnel to at least let me see if the installer thumb drive can see the SATA hardware.
Meanwhile I can continue experimenting with Qubes on the two USB installs (one onto the full disk, one onto only 1/4 TB of it).
(I may or may not try that new ISO you linked to, but it will be an academic exercise. The fact of the matter is, I want beefier hardware to run Qubes anyway, this just means I buy it earlier.)