I noticed that the Fedora Magazine workflow has been several months in production and I recognize how difficult getting everything perfect for prime time can be. But I am still working on USB passthrough for VM testing and converting from grub to systemd boot so I thought I would return to the dracut approach for a moment and it turns out with new information the goal might be easier to reach than I had thought.
If anyone is interested, I contacted Yubikey support and they provided me the link below that can tell us more about what the readme from ykfde had sketched out.
It says: vim /etc/crypttab
Modify so it looks like this. luks-a6c32afd-3c35-4628-8653-5be499eaf0ce UUID=a6c32afd-3c35-4628-8653-5be499eaf0ce - fido2-device=auto``
and that means removing “none discard” at the end before replacing it with fido2-device, I’m guessing.
A question I had was when it says to view existing keyslot info, how do I do that? All this looks straight forward now. After I get QEMU passthrough it should work. As for constructive criticism, technical experts might improve their technical writing skills. An end solution without all it took to get there can be confusing. Although, maybe the standard is end result first, steps to get there afterwards?
Part of the problem is that the “end solution” is a moving target. The technology is gradually evolving and becoming easier to use. But people often find instructions for older and more-complex incarnations of it before they find the newer and easier version.
Sometimes you learn a little more by going down those rabbit holes though. So it’s not all bad.
Yeah, that’s why these forums are so nice. I’ve learned so much discussing these questions and learning from the replies. I was really happy when the QEMU passthrough you linked to worked. Almost there!
The question I have now is, how do I make a vda for it to install on to? I think I have to specify something about the -drive.
I think I’ve got traction on this. Systemd boot cryptenroll might be more complex, but I think I can bring together what I need to make the dracut yubi work.
By the way, QEMU even allows for making emulated u2f keys, which I thought was interesting. VMs could be spun up and authorized with emulated keys.
Yeah. That would be something like -drive if=virtio,format=raw,file=my-test.img.
You will need to make a my-test.img file beforehand to give qemu as a “vda” to read from and write to as though it were a hard drive. You can create such a file by writing some number of zeros with a command like dd if=/dev/zero of=my-test.img bs=1MiB seek=32000 count=0 (if= means “in file”, of= means “out file”, and bs= means “block size”). Be sure to always specify a “count” if you use that command to create a new file. Otherwise it will just keep writing until it completely fills your real hard drive and your system will crash because it has run out of space! You can press Ctrl-C on your keyboard to stop the dd command before it fills your drive if you realize you’ve forgotten the count= option. Using seek=<number> count=0 is a trick that creates a “sparse” file. It is better to make sparse files than actually writing out zeros to your disk because it is faster and it saves a little wear on your real hard drive. The parameters I’ve given as an example would create a 1MiB times 32000 = 32GB file.
I never tried making a mini partition/file with dd inside dev/primarypartition. The info I found from QEMU recommended making a .qcow file, but then I’m not sure how to designate that as the installation target within the installer screenshot below. If I used dd like you suggested, /dev/zero would show up in “installation destination?” Does that mean I could have a VM stored on a USB drive? That’s cool. Then I could run my OS on any host by inserting the USB and running QEMU?
No. /dev/zero is just being used as a data source to create the disk “image” file (when read from, /dev/zero just prints zeros). By creating a file containing nothing but zeros, it will look like a new, empty hard drive when attached to your virtual machine. In the VM, whatever disk “image” you attach will show up as /dev/vda.
If you want to “map” a thumb drive as your /dev/vda in your virtual machine, you should be able to use something like -drive if=virtio,format=raw,file=/dev/sdc (assuming /dev/sdc is your thumb drive). Be careful not to attach your system drive and erase it by mistake!
lsblk is useful for seeing what drives are attached to your system and where they are mounted. df -h is another command that does something similar.
I made the sparse file. [By the way, do you know anything about ‘quark’ errno and formatting? I specified bs=6G count=6 and it produced an output file of 31GB. That phenomenon is truly mysterious since it can happen when there is no network connectivity and wifi modules are removed. What is controlling formatting/writing at the deepest level?] I looked up sparse on wiki and other operands were suggested since bs= seek= and count= were not producing the expected result.
Now, how do I tell qemu-kvm that that sparse file is the vda? I think the options change in relation to one another.-drive. . . is for the .iso not the test image in the command that got me to the installer. Maybe something like-hda file=~/fedora.img (test image) but that didn’t work, it says no such file.
This is where I was going with the aggregate command → sudo qemu-kvm + -m 1024 -name f38 -drive file=~/Downloads/Fedora.iso,if=virtio {that is the installation medium} + -usb -device u2f-passthru {that is the passthrough} + -hda file=~/QEMUimg/fedora.img {that is the installation destination - does order of operations matter here?}
If you zoom in on the screenshot above of the “installation destination,” there are options like “multipath devices,” “SAN Devices,” “ISCSI”–do you know how a vda can be created from that installation GUI? That looks very complex. Never heard of a lot of that.
It’s probably best not to go too high with the bs= value. That is how much data to move at one time. You might think of it like a chain of people handing off buckets of water to move the water from one place to another. Assuming the people can only hand off buckets at a limited rate, it becomes possible to move more water faster (in parallel) by increasing the size of the buckets of water that they are passing along. However, there will always be a limit to how big of a bucket of water someone can lift. They same is true for computers – they have their limits. The example I provided should have worked. If you needed a bigger file, you should have been able to increase the seek= value.
Yes, the first -drive option you supply to qemu should become vda, the second will be vdb and so on. I wouldn’t use -hda that is for an older, slower type of hard drive.
Instead of using -drive file=~/Downloads/Fedora.iso,if=virtio, you might want to use -cdrom ~/Downloads/Fedora.iso to make sure that that file gets mapped to /dev/cdrom in the VM instead of using one of the /dev/vdX device nodes.
It’s probably best to ignore those for now. Those are advanced features that probably won’t be useful for what you are trying to do.
As an aside, I think it is important to first test any new, fundamental system change in a VM or test device before attempting it on a primary system. In other words, the VM test section of this discussion is not off topic. I will be satisfied to wait for the article after I successfully complete the Yubikey VM passthrough and modify dracut to require the key at boot. But I think there’s a high chance that this method will work.
Nice explanation of dd options. Metaphors can be very helpful. I remember a time when the only way I could get dd to work was with bs=1, otherwise the “header” was cut off and the OS would not boot. That was some “basic” EMF spooky action at a distance but a fun as a victory. I’ve seen partitions get switched around and other anomalies sans network connection, so I know there must be a lot of important things that can be done with dd.
Would you explain ,if=virtio because when I tried -cdrom ~/Downloads/Fedora.isowithout it the prompt was saying it couldn’t find the file?
There is a man (user manual) page for qemu. To access it, enter man qemu. It contains exactly that sort of information.
if=interface
This option defines on which type on interface the drive is connected. Available > types are: ide, scsi, sd, mtd, floppy, pflash, virtio, none.
Another convenient resource for command line examples is a program called tldr (I don’t think it is installed by default though.) Here is what tldr shows for qemu.
$ tldr qemu
qemu
Generic machine emulator and virtualizer.
Supports a large variety of CPU architectures.
More information: https://www.qemu.org.
- Boot from image emulating i386 architecture:
qemu-system-i386 -hda image_name.img
- Boot from image emulating x64 architecture:
qemu-system-x86_64 -hda image_name.img
- Boot QEMU instance with a live ISO image:
qemu-system-i386 -hda image_name.img -cdrom os_image.iso -boot d
- Specify amount of RAM for instance:
qemu-system-i386 -m 256 -hda image_name.img -cdrom os-image.iso -boot d
- Boot from physical device (e.g. from USB to test bootable medium):
qemu-system-i386 -hda /dev/storage_device
It doesn’t look like you should need if=virtio for cdroms. Is your file truly a cdrom image? What does file ~/Downloads/Fedora.iso show? It should report “ISO 9660 CD-ROM filesystem data”.
Although, man has all the information required in the abstract, I don’t think many people figure out the sort of complex string of precise options that QEMU requires through man. I’ll demonstrate that in a moment. tldr is cool, hadn’t heard of that. Hopefully developers keep adding to that list of commands. I’m pretty sure finding an expert in a particular command structure or taking a university course is required to be successful, unless you have another idea.
The Fedora.iso properties show that it is a Raw CD image owned by qemu user (system_u:object_r:virt_content_t:s0). I installed it in KVM the GUI way and now it is owned by QEMU. Should that interfere with making a new installation from it?
So when I tried sudo qemu-kvm -m 1024 -hda fedora.qcow -cdrom Fedora.iso -usb -device u2f-passthru -boot d
then the first the message was “Invalid physical address chosen! Physical KASLR disabled. Initramfs unvalid.” when I tried -hda + the sparse file. Then -hda .qcow just went to a black screen.
Command line virtualization has labyrinthine complexity. I might see if I can find an Oracle Virtual Box or QEMU forum to ask about this. Do you know where I might best direct my questioning?
Unfortunately, “Raw CD image” doesn’t really mean much. That just means that the file name ends in .iso. It is important that the filesystem in the image is actually a ISO 9660 if you want to mount it as a CDROM image.
1024MiB (1GiB) might not be enough to run a Fedora Live image. According to the documentation, 4GiB (4096MiB) is recommend.
It is true that some things are irreducibly complex. Take a handheld calculator for example. Someone might argue that it is “too complex” because you have to press four buttons just to find out what one plus one is! Obviously, a better user interface would have just one button that would give the answer. But then someone is going to come along and say, “This interface is lousy, it doesn’t have a button to answer what one plus two is!” Making a calculator with a “user friendly” one-click button to answer every possible math problem just isn’t possible. For some problems, the user must step up and do their part to comprehend things.
The SELinux permissions do not matter when you are accessing the file from the terminal because your terminal process runs “unconfined”. The SELinux permissions might be important if you are trying to start the virtual machine from a system service or daemon (e.g. on system startup). But as long as you are using the command line interface (CLI) it shouldn’t matter. You can verify that your CLI is running unconfined by entering ps -Z $$.
$ ps -Z $$
LABEL PID TTY STAT TIME COMMAND
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 22576 pts/1 Ss 0:00 -bash
-m 4096 worked! Thanks. I’m just saying it would probably take a very long time without help, so thank you. Now a 6GB ATA QEMUHardisk shows up at sda with 1.9 MiB free. But then the final step says “not enough space in file systems 630 MiB is needed.” I have to increase the size of .qcow? sudo qemu-img resize fedora.qcow 10G
Ok, I’ve got a test VM with a Yubikey passthru. Except, QEMU is still live on restart but with an encrypted removable mounted at live user. Then how do I restart the VM in its last, installed state? The KVM GUI does a lot automatically this command line way does not. I will start researching this.
After that, I will work on the last step of configuring fido2 to unlock luks (…/82462/21).
Omit the -cdrom <path-to-iso-file> option the second time you start the VM (after you’ve installed the OS to /dev/vda and shutdown) and it should behave as though the virtual computer were booted without a cdrom.
Thanks! Do you know why “waiting for PID #### to finish” happen? I can’t find that PID on Manager. Is there a command to terminate or kill specific PIDs? Ok, shut off networking and that stopped so I can work on terminal.
starting on 82462/21 cryptsetup luksDump /dev/sda3 should be changed to /dev/vda or how do I view the partition tree? Gparted doesn’t find the vda partition table.
Just from your question, I don’t know what command is waiting on what process. But ps -e (processes dash everything) is a popular command for listing the running processes on a system. (The first column is the process ID number.)
I tried the XFCE Spin because Qubes OS based on Fedora in large part uses XFCE probably just because it is light weight and Qubes (GRUB boot script) is where I first heard about Yubikey, Nitrokey, and Purism’s Key. That PID error happens in the Spin but I checked the sha256sum and it was verified.
“Check LUKS token(s) and keyslots” —> article doesn’t list command to do that exactly, might be the “LUKS header information” listed after cryptsetup. lsblk lists sda so it thinks of itself as 3 sdas when it is one vda and LUKS is on sda3.
Enroll tokens. “initializing FIDO2 credential on security token” Fingerprint applied. This takes awhile… OK. This is a good one. Nothing happens. Does that mean that the token is enrolled? I would clone the VM at this point, but since I am not using GUI not sure how to do that. I’ll see what the response is before trying the last command to reboot and see if everything turned out like expected. Here is the screenshot:
If lsblk is showing sda (scsi disk a) instead of vda (virtual disk a) it means that you are running a terminal on your host system, not in the virtualized PC.
Scratch that, I forgot that you were using the -hda parameter to qemu. That may well cause the device node to show as sda because Linux merged all the old ATA drivers into the SCSI subsystem a few years ago. If you had used -drive if=virtio,... then the drives would have shown up as vda, vdb, etc.
I’m not a good one to ask about LUKS encryption and security keys. I don’t have much experience with those technologies.
To clone the VM from the command line, you would enter something like cp fedora.qcow fedora2.qcow. Be sure to turn off your VM before attempting to do that or else the copy will be corrupt because the copy/clone is done linearly and changes to the earlier part of the file won’t be picked up while the latter part of the file is being copied.
