search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
544 stars 48 forks source link

Support for EFI boot #794

Closed marmarek closed 8 years ago

marmarek commented 9 years ago

Reported by marmarek on 4 Feb 2014 02:53 UTC EFI is more and more popular, soon there will be some machines with EFI-only boot, so we need badly support for it. Adding such support may be non-trivial, because Xen 4.1 do not support direct EFI boot (AFAIR it is supported in >=4.2 or even >=4.3). But perhaps some workaround like grub-efi can be used.

Migrated-From: https://wiki.qubes-os.org/ticket/794

marmarek commented 8 years ago

There is known UEFI firmware problem on some Lenovo devices (hang at EFI variables access). You can try to workaround it adding /mapbs to xen.efi options (you can do that from rEFInd - press F2 and edit options). There should be also other option /noexitboot, but it looks like a patch adding it is missing somehow in the current image...

wardwouts commented 8 years ago

/mapbs does not seem to make a difference, unfortunately. /noexitboot or /noexit are both ignored.

marmarek commented 8 years ago

Complete list of available EFI workarounds:

/noexitboot requires additional patch, which I've just applied. Building new image...

marmarek commented 8 years ago

Next images (main difference: updated xen to support /noexitboot): http://ftp.qubes-os.org/~marmarek/Qubes-20160208-x86_64-refind.iso http://ftp.qubes-os.org/~marmarek/Qubes-20160208-x86_64-refind.iso.asc

marmarek commented 8 years ago

@woju could you try to boot this image on your thinkpad? AFAIR previous one was hanging at efivars init, I wonder how this one behaves. If it still hangs, try to add /mapbs and /noexitboot workarounds.

dizmoduck commented 8 years ago

Nice job to all

My Asus Zenbook UX31A has no problem to UEFI boot the Qubes-20160208-x86_64-refind.iso from a memory stick.

It was not clear with optimum to boot to get a live boot without install

I could boot up "Verbots boot and install" to "Welcome to Qube xxx" but stopped for fear of auto install

With one to choose for a live boot?

marmarek commented 8 years ago

Sorry, there is no new Live image. And probably will be delayed because short on manpower... It is tracked in #1552.

jsgf commented 8 years ago

@marmarek 20160208 with /mapbs /noexitboot is the first to get into the installer on my Thinkpad T440s. Progress!

ag106428 commented 8 years ago

Is rEFInd a good idea regarding security though? Near as I can tell there's no way to get a signed binary or source package to make sure we're getting the real deal, the author isn't well known outside of this project and the source files seem to be exclusively hosted on SourceForge, which has been caught maliciously modifying software in the recent past... On 10 Feb 2016 4:22 am, "Jeremy Fitzhardinge" notifications@github.com wrote:

@marmarek https://github.com/marmarek 20160208 with /mapbs /noexitboot is the first to get into the installer on my Thinkpad T440s. Progress!

— Reply to this email directly or view it on GitHub https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-182045809 .

marmarek commented 8 years ago

On Thu, Feb 11, 2016 at 05:44:51AM -0800, ag106428 wrote:

Is rEFInd a good idea regarding security though? Near as I can tell there's no way to get a signed binary or source package to make sure we're getting the real deal, the author isn't well known outside of this project and the source files seem to be exclusively hosted on SourceForge, which has been caught maliciously modifying software in the recent past...

That's a good question. Also most of major distributions (Debian, Fedora, Ubuntu, ...) doesn't include refind in main repositories, so we can't rely on their verification (somehow harder targeted attacks).

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

jsgf commented 8 years ago

Does tboot help with an untrusted bootloader? Does Qubes use it?

rootkovska commented 8 years ago

NOTOURBUG

marmarek commented 8 years ago

Generally UEFI support is implemented. Other problems are buggy UEFI firmwares, and workarounds for them which we do or do not implement.

jsgf commented 8 years ago

@marmarek Unfortunately broken UEFI WRT Xen seems to be the common case - at least for me. This boot image was the first time I've managed to boot Xen to usermode on any of my UEFI platforms. Maybe I've been particularly unlucky, but it seems to be a strong stumbling block for client-side use of Xen (which is something I've used keenly in the past).

marmarek commented 8 years ago

Yes, as linked in one comment there seems to be a bug in EFI reference implementation, which affects Xen use case (IIUC calling ExitBootServices still with 1:1 memory mapping).

Anyway if you're affected with such bug, you can try some workaround, or if it doesn't help - simply switch back to legacy mode...

noseshimself commented 8 years ago

Am 11.02.2016 um 14:44 schrieb ag106428 notifications@github.com:

Is rEFInd a good idea regarding security though?

Is not having it and thus not being able to boot Qubes on hardware without legacy boot firmware better?

If you don’t think it’s trustworthy but don’t have any other choice you either take it, get less broken (and more trustworthy) hardware or start a formal verification process.

Achim

dwangoac commented 8 years ago

I am 12+ hours of research in to getting the Qubes R3.1 installer to boot on a MacBook Pro 10,1 Early 2013 laptop using literally any conceivable method. Depending on the key I use I either see fabian-z's "Unsupported device path component" issue or just a hang. Using rEFInd, my existing Linux Mint GRUB2 recovery prompt, or any combination of attempting to manually specify a vmlinuz and initrd directly from the R3.1 installer's prompt ends in a dracut shell with various forms of not having a proper root mounted. I've even tried PXE booting, but that also requires UEFI and my OpenWRT configuration is only equipped to handle legacy booting. There must be a way to force through this...

The furthest I can get is a dracut shell where I can see all of the files on any ext4 partition, including my existing Linux Mint partition and an empty partition I've already prepared for Qubes to be installed to. I just can't for the life of me figure out what /dev/root should be pointed at or how to continue booting from there, and I'm not even certain it's the "right" approach. I am more than willing to help test, troubleshoot, and hopefully improve the situation either here or in #qubes on IRC and any advice is appreciated.

marmarek commented 8 years ago

If I understand correctly, the best results you've got with rEFInd, right? Try point it to xen.efi.

Also take a look here: https://www.qubes-os.org/doc/uefi-troubleshooting/

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

dwangoac commented 8 years ago

On 2016-03-13 20:17, Marek Marczykowski-Górecki wrote:

If I understand correctly, the best results you've got with rEFInd, right? Try point it to xen.efi.

Hi Marek, thanks for the suggestions. Attempting to point directly at xen.efi using any method, be it GRUB2 from my existing install or any EFI prompt, seems to be futile; it usually prints "/EndEntire file path: /ACPI(a0341d0,0)/PCI(2,1f)/Sata(0,0,0)/HD(5,1d290800,56a3000,f68fcf01a84edd40,2,2)/File(\EFI\BOOT)/File(xen.efi)/Endentire"; if I type boot after that it does nothing. None of the /mapbs or /noexitboot or other flags seems to make any difference. I used an older rEFInd build I found in the support thread that predated R3.1; is there a newer one I should try?

Also take a look here: https://www.qubes-os.org/doc/uefi-troubleshooting/

I wish I could make it far enough to start playing with some of that. :)

ideologysec commented 8 years ago

Is your installer's xen.cfg file empty? I ran into a similar error on my MacBook Pro for that reason.

dwangoac commented 8 years ago

The /EFI/BOOT/xen.cfg file contains a [global] default=qubes followed by a [qubes-check] with kernel=vmlinz inst.stage2=hd:LABEL=Qubes\x20R3.1\x20x86_64 i915.preliminary_hw_support=1 quiet rhgb rd.live.jeck and ramdisk=initrd.img, along with 3 other similar entries. I think that's all sane, but as noted trying to do anything with xen.efi accomplishes very little, either resulting in the Unsupported device path component error or literally doing nothing at all on a boot directive. I'm continuing to experiment with trying to recover from a dracut shell now. Thanks for inquiring!

dwangoac commented 8 years ago

OK, crazy method I took: I used my Linux Mint GRUB2 environment to run linux (hd0)/isolinux/vmlinuz followed by initrd (hd0)/isolinux/initrd.img followed by boot. That gets stuck in Dracut with no /dev/root mounted, and thanks to miwa in #qubes on Freenode IRC I got a hint that the next step is to run /usr/sbin/dmsquash-live-root /dev/sdb1 (the path to the USB key's iso9660 filesystem), and from there typing exit to continue the boot, I'm now finally at a Welcome to Qubes 3.1 screen. This leaves it in a state where no installation source is available, but I'm going to try to mount my existing /ext4 and the .ISO file from there, I think.

marmarek commented 8 years ago

It you start vmlinuz directly from (whichever) bootloader, you are not running Xen, installation will fail. So even if it looks promising at start, it is wrong way.

If xen.efi is not working for you, I really recommend switching to legacy mode.

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

dwangoac commented 8 years ago

OK, I put a couple more hours into testing various combinations. I went back to the rEFInd method and used -- efi=attr=uc at the end of the chainloader and that seemed to finally work (MacBook Pro 10,1 Early 2013). It's "QUBES 20160208" which predates R3.1 so my next step is to try to specify the R3.1 installation media and complete an install, likely to a different USB key so I can then take the installed partitions and merge them into my SSD.

dwangoac commented 8 years ago

20+ hours in, I have managed to install to a partition on my MacBook Pro's SSD but I have yet to work out a way to EFI boot it. There is no possibility of legacy mode booting on this device and I have found very slim details on shim layers that can bridge the gap, if such even exists, so EFI is my only path forward.

Good news - I installed in EFI mode using the stock R3.1 build on a Gigabyte desktop and it was completely successful. I'm trying to figure out how to get my existing MacBook Pro working by copying the successful EFI boot portions from the desktop to the MacBook Pro's GRUB2 but I haven't yet sorted out the right incantations. Is there documentation on the steps EFI booting takes? I've been trying to look through the Fedora documentation but that's more oriented on how to write individual pieces rather than describing how the process flows. Thanks for continuing to help out on this!

marmarek commented 8 years ago

Take a look at this page: http://xenbits.xen.org/docs/4.4-testing/misc/efi.html

ag4ve commented 8 years ago

We should probably link to that somewhere in the Qubes docs as well as the Microsoft kb. At least until uefi install is seamless. On Mar 15, 2016 2:20 PM, "Marek Marczykowski-Górecki" < notifications@github.com> wrote:

Take a look at this page: http://xenbits.xen.org/docs/4.4-testing/misc/efi.html

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-196959060

dwangoac commented 8 years ago

I think I'm well beyond EFI now; the problem was there was an /etc/fstab entry for /boot and /boot/efi that used the wrong uuid which I've since corected. Unfortunately, it's now failing with "Failed to start Qubes Dom0 startup setup." and hard freezing after "Starting Wait for Plymouth Boot Screen to Quit...", and systemd / journalctl is binary logging which makes seeing what happened just that much harder, but I'll continue to plow forward. That's likely for a different discussion thread than this one, though. Thanks for the help!

dwangoac commented 8 years ago

Marek, is there any chance you can create a new rEFInd build? I know it's a lot to ask, but it's the only method that actually works on this MacBook Pro and I'd like to do a clean install with the R3.1 or better state. The problem with the rEFInd build from 2016-02-08 is the installer crashes when attempting to write the boot partition (at least on the Mac) and I'm hoping it's just a pre-R3.1 issue. (I'm planning on doing a reinstall to attempt to get a fresh start on fixing the Failed to start Qubes Dom0 startup setup problem.) Thanks again for all of the help!

antiplex commented 8 years ago

reading through this i wonder why plenty bioses have abandoned legacy bios and instead force its users to use buggy efi implementations :(

im my case i've been struggeling now for hours to install qubes r3.1 on my fujitsu celsius h720 (running the latest firmware 2.09) and can't get qubes installed properly.

when choosing the verbose install option the bootprocess runs until reaching EFI Variables Facility v0.08 2004-May-17 on normal install but with workaround -- efi=attr=uc the process gets stuck while displaying file path: /ACPI( ... /File(\EFI\BOOT)/File(xen.efi)/EndEntire on normal install but with workaround /mapbs /noexitboot the system stalls 4 lines later on line initrd.img: 0x00000000a1cd1000-0x00000000a33c9a34

tried several settings in bios/firmware such as turning on/off CSM (compatibility support module for legacy bios services) all yielding in the same dead end as it seems.

for some weird reason, when choosing the verbose install option and editing it to also contain /mapbs /noexitboot at the end of the chainloader line the installer is loaded and i can install the system. but what seems odd to me is that when i (as described at https://www.qubes-os.org/doc/uefi-troubleshooting/) edit the efi-boot-entry with efibootmgr, the params at the end of the line ("placeholder /mapbs /noexitboot") show up in a weird way in the freshly created entry as there are dots (.) between each character and the string starts right after the closing bracket of the entry. Boot00XX* Qubes HD(...)File(\EFI\qubes\xen.efi)p.l.a.c.e.h.o.l.d.e.r. ./.m.a.p.b.s. ./.n.o.e.x.i.t.b.o.o.t. is this how it is supposed to look like? to me, it looks like my input was interpreted as unicode and leaves me doubting if thats what might cause the hazzle...

when rebooting the boot process gets stuck showing 8 tux-penguins at the top of the screen.

following the scheme descibed i can also access the rescue-system but don't know what to do with it...

any ideas?

dwangoac commented 8 years ago

Antiplex, I'd recommend the rEFInd image from above with -- efi=attr=uc, except...

Marek, is there any update on the possibility of a newer rEFInd version? The problem is the older rEFInd version fails at efibootmgr -c -w -L Qubes -d /dev/sda -p 1 -l \EFI\qubes\shim.efi because efibootmgr is "cowardly refusing to create a boot option". Attempting to create a valid /boot/efi and even a separate /boot and re-running the installer fails because "You have not created a bootloader stage1 target device" and https://bugzilla.redhat.com/show_bug.cgi?id=1010495 is still an open issue. Installing to a different system and copying the entire installation over seems to be getting me the furthest, but I'm stuck because Qubes NetVM doesn't start, throwing a Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory error (presumably as a result of a failed root partition clone, I'm still investigating).

I started work on taking the rEFInd EFI directories from the last test image and merging in the R3.1 release but it wouldn't boot at all. Thoughts? Linux hasn't been this difficult to install for more than a decade. :)

dwangoac commented 8 years ago

50+ hour mark, it's 2:00 AM PST and I'm giving in for the night, but I'm very close to getting this working on my MacBook Pro 10,1 "Early 2013". Steps - install rEFInd from OS X so the Mac boots to it by default and set refind.conf to scan from all media types, i.e. the default option. Insert stock R3.1 USB key but boot "normally" to reach rEFInd, select the EFI option on the USB key, hit F2 to edit it, and add -- efi=attr=uc. Once reaching graphical Anaconda, ctrl+alt+F2 and edit /usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py and change the raise near line 1696 to a pass (or, just replace all of them :). Then, restart Anaconda with:

systemctl stop anaconda.service
anaconda-cleanup
systemctl start --no-block anaconda.service

Proceed with the installation and you will have everything except a valid xen.cfg, which you will have to build yourself. This is the part I'm getting stuck at, and others have gotten stuck here before as well; what goes in xen.cfg when using an LVM for root= parameters, and/or how do you determine what should go there? The problem is /dev/mapper is empty and booting stops at a dracut shell. I'll fall back to standard partitions next but it would be good to figure this bit out.

marmarek commented 8 years ago

Example xen.cfg: https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-177778620

Regarding empty /dev/mapper - is your disk even discovered there? Check /dev/sd* (or more convenient: fdisk -l - if it is present in dracut env...).

dwangoac commented 8 years ago

HI Marek - I should also quickly note that the MacBook Pro keyboard does not work in dracut, I have to use an external keyboard but at least that works. There is no fdisk in dracut but I do see /dev/sda4 with TYPE="LVM2_member" from blkid. If I attempt to mount it it fails saying unknown filesystem type 'LMV2_member'. My xen.cfg directly matches above, specifically kernel=vmlinuz-4.1.13-8.pvops.qubes.x86_64 root=/dev/mapper/core3-root vconsole.font=latarcyrheb-sun16 rd.lvm.lv=core3/root but because /dev/mapper is empty I don't know where the name core3-root would come from. I see no path forward with LVM as much as it seems like it would e a better choice so I will re-perform the steps from my last comment as well as your change in commit 2556a42 and see what I get. Thanks!

marmarek commented 8 years ago

For LVM - run lvm lvs to list volumes. For full LVM init, call lvm vgchange -ay (and if /dev/mapper is still empty, call lvm vgmknodes).

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

dwangoac commented 8 years ago

Marek, unfortunately none of those tools exist in dracut. As I indicated I opted to try again with standard partitioning but it's almost the same problem, now it's unknown filesystem type 'crypto_LUKS'. I'm beginning to believe I have the wrong initramfs. Should that have been generated during installation and placed somewhere?

marmarek commented 8 years ago

If there is no lvm, nor cryptsetup in initramfs, it indeed looks like a broken initramfs. You can regenerate it by booting recovery option of the installer (or simply doesn't immediately reboot the system after installation and switch to tty2). Then execute chroot /mnt/sysroot dracut -f (check the mount for actual directory - AFAIR it's /mnt/sysroot, but I may be wrong).

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

dwangoac commented 8 years ago

OK, this is likely the last update from me in this thread, and thankfully it's for a good reason - I finally have everything booting, with LVM, and even with LUKS! The problem was definitely an incorrect initramfs; after the install completed I failed to copy the file to the correct /EFI/qubes location and thus I was using a bad copy. I had additional problems because the suggested xen.cfg configuration did not work as I had no core3-root (and have no idea how something would be named like that), but simply adding root=/dev/dm-1 with no rd.lvm.ld specified worked fine and I was able to see the post-install welcome configuration wizard for the first time.

My luck changed after that as I have a 14e4:4331 BCM4331 wireless adapter that hard-freezes the system as soon as netvm is started with that device included. I've tried the /etc/systemd/system/qubes-pre-netvm.service permissive mode change as identified in the issue described at https://github.com/QubesOS/qubes-issues/issues/1261 and I've even (painfully) copied in firmware and re-run the b43-fwcutter tool but unfortunately any attempt at normal networking hard locks the system. Because a MacBook Pro of this era has no network port this means I have no networking at all unless I violate dom0 with a USB network adapter. These problems probably belong in the other thread but I wanted to extend my thanks to Marek for the help along the way, and I hope my notes in this history help someone else in the future.

wardwouts commented 8 years ago

Adding -- efi=attr=uc to the boot options in refind lets me boot into the installer on my lenovo yoga 2 pro. After installation adding efi=attr=uc to the options lines in /EFI/qubes/xen.cfg on the first partition results in a bootable system.

Things seem to work fine after that. (Well, KDE doesn't like HiDPI displays, but I can work around that.)

Thanks dwangoac & marmarek

antiplex commented 8 years ago

hmmm... still unsure if Boot00XX* Qubes HD(...)File(\EFI\qubes\xen.efi)p.l.a.c.e.h.o.l.d.e.r. ./.m.a.p.b.s. ./.n.o.e.x.i.t.b.o.o.t. (as posted about 5 days ago https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-197281948) is the way it is supposed to be. for those who successfully applied the fix described in https://www.qubes-os.org/doc/uefi-troubleshooting/ , how do the additional options added to the entries end look like? do the show dots between each character like shown above?

using rEFInd was repeatedly recommended to be used in order to fix such EFI-related problems but i'm lacking some sort of understanding about how to apply rEFInd. can anyone help me out with a short step-by-step description of what to boot/load/copy/... when?

cheers, anti

ghost commented 8 years ago

I think these images from marmarek contain Qubes with rEFInd instead of GRUB to overcome the issues.

Next images (main difference: updated xen to support /noexitboot): http://ftp.qubes-os.org/~marmarek/Qubes-20160208-x86_64-refind.iso http://ftp.qubes-os.org/~marmarek/Qubes-20160208-x86_64-refind.iso.asc

I personally made a USB 3.0 stick from the ISO using dd and tried to do UEFI boot, but it failed for the same reason as the official 3.1 does. Hangs on "EFI Variables Facility..." line. See my bugreport referenced by marmarek 3 days ago. I did not try "/mapbs /noexitboot", because it was not possible. I tried it on official 3.1 GRUB2 boot, but with no change.

Marmarek says its a vendor, or Xen bug, but it does not affect Fedora 23 respin. I can do UEFI boot on it. I think there is no hope for my HP Probook 4730s to do UEFI boot for Qubes 3.1, I will have to get by using Legacy BIOS.

antiplex commented 8 years ago

@Slazer Thanks for pointing me to these ISO's, i must somehow have overseen those ;( now i also understand why dwangoac asked for some updated rEFInd images a few posts above as the .iso files you linked must pre-date qubes v3.1 so i'll give those a shot and see how it turns out (see below).

I've come across the hang on "EFI Variables Facility..." line on the standard Qubes-release as well but was able to get around through "/mapbs /noexitboot" but got stuck after editing the efi-boot-entries as my system won't boot. if my devices firmare would let me i'd happily use legacy bios but somehow my fujitsu h720 provides some CSM (compatibility support module) that is supposed to provide some legacy bios services but my issues remain as it seems not really possible to disable uefi...

well... now i tried to use marmarek's rEFInd version but failed to see how i could modify the boot-menu entries (to try different options/combinations of -- efi=attr=uc, -- efi=attr=uc) as possible in the standard qubes version by pressing 'e' in grub. how would i do that on marmareks build?

ParadiseBurn commented 8 years ago

I waneed to thank everyone for input here! I know tail end was mostly regarding Mac's but had some MAJOR hiccups first time installing Qubes 3.1 and this thread lead me down some good roads!

I did want to chime in with my own general observations regarding some of the EFI and freezing. I mean not sure of EFI specific, but I decided to work my way forward, installed R2. Started upgrading templates etc, working my forward to kind of "shade tree" upgrade / troubleshoot (maybe a stretch being first time Linux user, upgrading borderline Legacy/UEFU aged windows 8 machine).

So I made a snap judgement to try newest stable Qubes Kernel 3.19 via console and was running semi solid loading in then BANG! Freeze on boot, lockup after initial extended login. I rolled back to early kernel (worked fine) the kernel (3.19.018) I researched and found some similar issues in Fedora Git hub and was apparently pretty common. There were numerous issues with 3.19 causing lock up and freeze (usb related) right after initial login in or during OS initial loading after user login.

I'm going to work my way forward version by version until I do more research, but you might try a different kernel version? I was seeing that 3.19.030 had some luck, but it seems that in general 3.19 had some pretty unhappy customers.

ideologysec commented 8 years ago

You can try the other kernel that Qubes should ship with; edit your xen.cfg to have dom0 use the 4.1.13-pvops kernel instead of 3.19.

ParadiseBurn commented 8 years ago

No good on either, can't even load OS. The only kernel I've got functionality on so far is 3.12.40, I'm working my way forward On Mar 28, 2016 1:36 PM, "Aktariel" notifications@github.com wrote:

You can try the other kernel that Qubes should ship with; edit your xen.cfg to have dom0 use the 4.1.13-pvops kernel instead of 3.19.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-202500242

ParadiseBurn commented 8 years ago

I did get it to install 3.0, working on updates and kernel now On Mar 28, 2016 3:29 PM, "Tim Collins" timcollinsal1@gmail.com wrote:

No good on either, can't even load OS. The only kernel I've got functionality on so far is 3.12.40, I'm working my way forward On Mar 28, 2016 1:36 PM, "Aktariel" notifications@github.com wrote:

You can try the other kernel that Qubes should ship with; edit your xen.cfg to have dom0 use the 4.1.13-pvops kernel instead of 3.19.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-202500242

ghost commented 8 years ago

Please, where could I download any of these?

I would like to test any of these, as it might have solved my issue. I am able to compile stuff, though some advice, links or tutorials might come in handy.

marmarek commented 8 years ago

There are no new images yet. You can build one yourself - instructions here: https://www.qubes-os.org/doc/qubes-builder/ https://github.com/qubesos/qubes-builder

Also watch Fedora 23 dom0 - there will be links for test images when available.

ghost commented 8 years ago

My comprehensive comment got wiped after Vivaldi crash, so I will be short. Just compiled the master branch of marmarek, but the boot still hangs on "EFI Variables Facility..." line like before. The UEFI troubleshooting nor rEFInd did not help.

As soon as the fedora-23 branch at installer-qubes-os gets merged with master, I can recompile the master branch with DIST_DOM0 ?= fc23 and see if UEFI boot works on my HP ProBook 4730s laptop. I have great expectations, because the UEFI bug prevented me from installing Fedora 23 ISO, but was quickly fixed in one of the Fedora 23 ISO respins.

I wonder what I can expect from fc23 in dom0, instead of fc20 like in Qubes3.1. Given the fact it is a master branch, I should be prepared for instability, right?

marmarek commented 8 years ago

On Sun, Apr 10, 2016 at 05:24:20PM -0700, Martin Páleník wrote:

My comprehensive comment got wiped after Vivaldi crash, so Ill be short. Just compiled the master branch of marmarek, but the boot still hangs on "EFI Variables Facility..." line like before. The UEFI troubleshooting nor rEFInd did not help.

As soon as the fedora-23 branch at installer-qubes-os gets merged with master, I can recompile the master branch with DIST_DOM0 ?= fc23 and see if UEFI boot works on my HP ProBook 4730s laptop. I have great expectations, because the UEFI bug prevented me from installing Fedora 23 ISO, but was quickly fixed in one of the Fedora 23 ISO respoins.

I wouldn't expect much from that. The hang on "EFI Variables Facility..." on Lenovo machines is totally unrelated to distribution there. Generally at that point only Xen+kernel is running, nothing else. Maybe there is some patch in kernel used in Fedora 23?

I wonder what I can expect from fc23 in dom0, instead of fc20 like in Qubes3.1. Given the fact it is a master branch, I should be prepared for instability, right?

Yes ;)

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?