This system doesn't have removable media, except thru USB. I have a USB DVD and I've copied the ISO onto USB key as well. On DVD I see a grub menu with all entries just chainload to xen.efi. I verfied the ISO with sha512 hash, and verified the DVD when it was burnt. Used dd to copy ISO to USB, but as I write this I realize the USB has 2 partitions so I will dd it again after reformatting to a single partition using gparted. Not sure that will matter but it just occurred to me.
When I boot usb key no grub and different errors
This mobo uses an MSI "Click BIOS". I have zeroed out all keys. I have disabled all secure boot options. It's kindof odd where the key management lives, but I disabled all options under the "Advanced/Windows OS Configuration" menu.
There are 3 areas that relate to booting:
1) Advanced/Windows OS Configuration menu
2) Boot menu
3) Under Save / Exit - boot overrides
I can access an EFI shell under #3, but don't know what the cmd line to invoke is. Help not useful for listing devices. When booting off the DVD I can list the devices by typing ls <tab>. There is an SSD + HDD + whatever usb devices I plug in.
Under the Boot menu is a Boot mode, which has 2 settings: UEFI or UEFI+Legacy. In UEFI only mode (the main one I've focused on) there are 7 options for boot order. I set 2 and disable all the rest. 1=UEFI USB Key, 2=UEFI USB CD/DVD.
Under Windows OS Configuration there are 4 settings:
1) Windows 8.2/Windows 10 WHQL
2) Windows 7
3) MSI FAST Boot (no scan for boot devices, use only configured)
4) FAST Boot
I have all 4 options set to disabled, which implicitly disables Secure Boot I believe. BTW - the MSI mobo manual is no help for BIOS setup.
If I enable option 1 I can see additional Secure Boot options, including key management. I have backed up then cleared all keys, then disabled secure boot by switching option #1 back to disabled.
With boot mode = UEFI I briefly see 8 or 9 lines of text and then am dumped into grub prompt which erases that info. If I boot the USB DVD I get the 4 Qubes lines which chainload to xen.efi with various options. I have read the troubleshooting guide and appened efi=attr=uc and one other variation (nobootexit I believe) which has no visible effect.
Not sure why grub runs when booting off DVD when BIOS allows ONLY UEFI. That looks like a legacy boot response to me. Silly to boot a UEFI grub which chainloads to an EFI, so perhaps BIOS is not doing ONLY a UEFI boot as the setting indicates.
Not sure what to try next. I did stumble onto a PDF file from Linux.org IIRC about how Open OS devs CAN boot using Secure Boot by checking if the UEFI BIOS is in "setup mode" and if so the OS can then install it's own keys. The PDF described the process in considerable detail. I don't know why Qubes doesn't use that method, unless they discovered there are too many bugs in UEFI implementations or UEFI versions capable of that process are too new and not widespread enough to rely on.
Anyway, looking for any help or alternative to get Qubes installed you can offer. I have an old rEFInd CD I could try to boot, maybe it could be booted and from that it could load Qubes from the USB key. Other than that I am not sure what to do next.
I'm pretty sure this is a legacy booted installation process. It fails to start X, and falls back to text mode. I began to run thru the installation steps but it fails to partition the disk. It doesn't offer anything like the typical installation options to pick a device and then a partition scheme. I notice it complains about not having keys for the SSD device, which is probably why partitioning fails. Could be why X won't start as well.
I am going to go back and restore the factory keys (they're all deleted now) and turn secure boot back off after doing so, then seeing if that will change things.
The kabylake systems seems not to be that well supported on linux yet. Maybe someone who has had success with one can help.
Ok, thx for the reply. I've gone over the BIOS setting several times. The last time I upped the video RAM to 500MB based on other posts but it had no affect.
I see a lot of people mention UEFI but I have not seen it explicitly stated UEFI is not supported. Secure Boot is a subclass of UEFI. The fact the errors mention keys when I have disabled secure boot is troubling and points to a BIOS bug it seems to me.
I am able to boot a GParted Live CD and partition the drives, which is based on Debian linux, and that shows no signs of errors. I am going to try to install linux Mint with UEFI just to see if I can without errors or what errors I might get.
I am disappointed its so difficult to install, but I was warned so no surprises it is. No other linux distro I've used installs a xen hypervisor either, so that is a major difference, plus this is bleeding edge hardware.
The GParted starts X Windows with default settings too.
When I used the efi shell override I was able to launch the xen.efi with:
fs0:
cd EFI\BOOT
xen.efi placeholder qubes
I made sure the BIOS boot mode was UEFI and not EFI+Legacy, and I booted from the USB key.
I previously partitioned the SSD using a GParted Live CD and I could see all of those partitions. However I elected to delete them all and let Qubes "autopart" the drive instead.
The installation was generally straightforward. There was a very long pause when the progress bar reached 790 out of 900ish, but it finally completed and gave me the Successfully Installed message.
I have 2 drives but I was only asked for a passphrase once that I recall. If I was asked for one a second time I used the same value, that I'm absolutely positive of.
I still have 2 major hurdles to resolve:
1) The system will not boot Qubes automatically, I must use the efi shell override to boot off the SSD.
2) Once booted I get the gray screen with a Q in the middle, and a prompt for a disk password. It doesn't accept the passphrase I was asked for during installation.
If I hit the ESC key it switches to text mode and asks for a password / phrase for each drive. Entering the same value I provided during installation doesn't work, and suggests to use systemctl with a very long arg.
At first I thought #1 was caused by not providing a hard disk boot option, but after adding it as the only option I am directed to setup.
I noticed that there are 2 devices that seem to point to the same EFI partition. Only 1 will start the OS using:
fs0:
cd \EFI\Qubes
xen.efi
I used no args. I presume it gets the details from the xen.cfg file.
So here I am at the next hurdle to overcome. Time to google again, and should I not find any help from that will try:
Re: Great difficulty
1) Using recovery/rescue option of installer
2) Going through installation once more
Any and all suggestions welcome.
good idea I should of suggested that.
I still don't understand why you can't boot on legacy mode. only diff I see my bios has 3 options. uefi, uefi+legacy, or legacy only. I use legacy only but I don't see why it should make a diff.
I don't bother with uefi cause secure boot aint used. I'm not sure why else one would need it?
Another guy in another thread has similar issue to you. Are you also using another os on a diff drive and swapping? maybe your bios gets confused. Or maybe its just the partitioning? The installer should be able to partition your drive for you. I have most bios features off. like fast boot off top of my head. I have to double check my controller hand offs but I believe I have those off too. These new mobos certainly have alot of usb options worth double checking. I have it set to other os, secure boot and everything else off.
I have no more suggestions for you so hopefully someone else can chime in.
The main reason is b/c legacy booting does not work well with GPT partitioned drives. Besides, GPT partitioning is a newer and superior scheme, with far fewer limitations. Same is true of UEFI although it's currently a PITA primarily b/c there is no certification process or adequate test procedures to normalize its' implementation across manufacturers.
After reviewing the troubleshooting page I used the efi shell to make a copy of /EFI/qubes on /EFI/BOOT and renamed the xen.efi & xen.cfg and the system boots Qubes off the SSd directly now.
I couldn't resolve the encryption passphrase issue so I ran thru the installation a second time without encrypting the drives after using the GParted DVD to remove the encrypted partitions. I want to encrypt the filesystems but not yet sure how to do that with the (apparently) buggy installer that doesn't save the passphrase. I need to run through another installation again and confirm the behavior before claiming definitively the encryption passphrase is incorrectly handled.
> Another guy in another thread has similar issue to you. Are you also using another os on a diff drive and swapping?
No, this is a brand spanking new machine and Qubes is now the only OS installed. But since you mentioned swap, I noticed there is a swap entry in /etc/fstab despite specifically not setting one. The installer even warned me about it. I don't think it's good for the life of the SSD to use it for swap. Also unfamiliar with the scheme Qubes uses for swap. I decided to leave it as Qubes set it up for now.
>maybe your bios gets confused. Or maybe its just the partitioning? The installer should be able to partition your drive for you. I have most bios features off. like fast boot off top of my head. I have to double check my controller hand offs but I believe I have those off too. These new mobos certainly have alot of usb options worth double checking. I have it set to other os, secure boot and everything else off.
>
> I have no more suggestions for you so hopefully someone else can chime in.
Appreciate your reply, but aside from the encryption passphrase issue I think I've crossed the main hurdles. The rest is just getting familiar with how Qubes does things.
The friend of mine who tuned me onto Qubes said he was limited to a single resolution of 800x600 and had to recompile a new kernel to provide more choices. I am limited to a single resolution of 1024x768 so I will probably need to do the same thing. He mentioned it involved a few more steps to do that than on a typical Linux system but nothing too difficult.
It set me straight regarding exactly how Secure Boot was intended to function and dispelled my perspective it was Microsoft who tainted it's design to make it difficult to boot alternate Op Systems.
I'll grant you that achieving a truly secure boot process is a more complicated process than previous approaches, but the blame for most difficulties lies more with BIOS vendors than Microsoft, their strong-arm tactics not withstanding.
Another factor is lack of a certification process or testing procedures which I mentioned above.
Certification can be a bad thing as well, as that could become a point of control that limits practical use only to those who can pay a fee. If the fee is too high it would be exclusionary and possibly prohibitive to smaller open source projects.
I hope that the next release of Qubes will endeavor to fully utilize Secure Boot and thus improve it's integrity and ease installation. Of course given the variability of UEFI implementations it may prove to be too exclusionary to certain hardware manufacturers.
I don't see Qubes as overly concerned about that however, as even without Secure Boot it has rather specific hardware requirements as it is.
Richard Stallman admits now that secure boot is ok to use for security purposes, and has for some time now, because its "failed its intended purpose"...
So I still dont' see why even fsf people hesitant about it. Maybe microsoft never even had no intended purposes who knows, who cares. I still dont' trust them cause of how they pushed and using win10. But I do hope also Qubes use secure boot in the future. To me its too silly not to.
And I keep saying it ont he forums. But unless you just want Qubes for experimentation of cool tech. Dual booting even with detachable hdd's undermines qubes security by alot imo.
tks for your post alot of users have this issue.
> tks for your post alot of users have this issue.
No prob. Hope it proves helpful to others, that's why I posted.
So I simply reinstalled a 3rd time, doing everything the same as the 2nd time except I left the checkbox for encryption checked. I also had the network cable plugged in this time, but didn't explicitly configure networking. However I did see a few log entries that leads me to believe the network drivers were activated, tho other log entries seemed to indicate no network service was started.
I see the installer uses tmux which I am familiar with. Between the vitual consoles and tmux windows I popped around during the installation and looked at mounted devices, watched the anaconda log etc.
After installation was complete I created the user account and completed the install, then rebooted. This time when the system started and asked for the disk passphrase it accepted it and I then completed the post installation configuration.
Now it trully is a matter of coming up to speed on how to do things "the Qubes way", such as backups and updating the kernel.
There were no issues with the passphrase on this 3rd install attempt, and now I have a fully secure and encrypted system.