On Tuesday, September 11, 2018 at 9:55:47 AM UTC-5, Guy Frank wrote: > On Tuesday, September 11, 2018 at 5:21:16 AM UTC-5, awokd wrote: > > On Fri, September 7, 2018 10:21 pm, Guy Frank wrote: > > > On Friday, September 7, 2018 at 4:15:23 PM UTC-5, Guy Frank wrote: > > > > > >> On Friday, September 7, 2018 at 5:34:49 AM UTC-5, Marcus Linsner wrote: > > >> > > >>> On Friday, September 7, 2018 at 12:27:04 PM UTC+2, Marcus Linsner > > >>> wrote: > > >>> > > >>>> Actually I just looked, my MBR starts with lots of zeroes until the > > >>>> partitions are defined > > >>> > > >>> In fact the MBR contains the definition of only one (dummy)partition, > > >>> since it's GPT, like: > > >>> > > >>> [ctor@dom0 ~]$ sudo dd if=/dev/sda of=here.mbr bs=512 count=1 > > >>> 1+0 records in > > >>> 1+0 records out > > >>> 512 bytes copied, 8.5102e-05 s, 6.0 MB/s > > >>> [ctor@dom0 ~]$ fdisk -l here.mbr > > >>> GPT PMBR size mismatch (468862127 != 0) will be corrected by w(rite). > > >>> Disk here.mbr: 512 B, 512 bytes, 1 sectors > > >>> Units: sectors of 1 * 512 = 512 bytes > > >>> Sector size (logical/physical): 512 bytes / 512 bytes > > >>> I/O size (minimum/optimal): 512 bytes / 512 bytes > > >>> Disklabel type: dos > > >>> Disk identifier: 0x00000000 > > >>> > > >>> > > >>> Device Boot Start End Sectors Size Id Type > > >>> here.mbr1 1 468862127 468862127 223.6G ee GPT > > >>> > > >>> but this doesn't matter. > > >>> > > >>> I see the 'Boot' field is present only here (when type is dos, but > > >>> not when type is gpt) > > >> > > >> Hi Marcus: Thanks so much for your input on this! You're on the right > > >> track to think this is a UEFI issue. I've learned more about my > > >> problem, so let me explain. > > >> > > >> I have new hardware and the BIOS that comes w/ it *absolutely refuses* > > >> to run MBRs for internal storage (HDD, SSD). Problem is that when I > > >> transfer the Qubes ISO over to a USB drive, it sets up the drive with a > > >> MBR (fdisk -l shows 'msdos' or 'dos'). Apparently the Qubes installer > > >> takes a cue from the install medium and installs with a MBR, not with > > >> UEFI / GPT (again, checked with fdisk -l). When I try to run the > > >> installation, even though it's all there, the BIOS refuses to treat the > > >> installation as a bootable disk--so it boots nothing and throws an > > >> error. > > >> > > >> If I understand your suggestion, it's to set the BIOS to UEFI and try > > >> to install. Problem is it will not read my usb drive with the Qubes > > >> install on it--because the drive has a MBR and UEFI mode will not read > > >> a thumb drive that isn't UEFI / GPT. > > >> > > >> I therefore looked for instructions on how to convert the Qubes > > >> installation USB drive to UEFI / GPT (and then install w/ BIOS set to > > >> UEFI). I followed the instructions here: > > >> > > >> > > >> https://www.qubes-os.org/doc/thinkpad-troubleshooting/ > > >> > > >> > > >> Ran into two problems. One is that I get an error at the end of > > >> creating the GPT thumb drive saying that there is no grub.cfg file to > > >> write out to the USB. [specifically: sed: can't read > > >> /run/tgttmp.xI67OE/EFI/BOOT/grub.cfg: No such file or directory] Have > > >> no idea what causes that, but perhaps a grub.cfg is not essential. The > > >> second problem I run into is that, contrary to the instructions, I see > > >> no xen.cfg under .../EFI/BOOT, just a BOOT.cfg. I change the label to > > >> BOOT in this cfg file, the only one in that directory. > > >> > > >> > > >> When I try to install, I get a 'Panic on CPU 0' and installation halts > > >> before I get to the Qubes GUI install. The error seems to be that Xen > > >> can't read the cmos time to set its time. One of the calls is to > > >> efi_get_time. > > >> > > >> When I installed from a MBR USB stick, I got to the Qubes QUI install > > >> w/o any fatal errors. So am guessing there's something about > > >> efi_get_time that isn't cooperating w/ my computer's hardware. > > >> > > >> At this point, I don't know whether I should give up because Qubes is > > >> not yet compatible with my hardware (Dell Precision 3630), or whether I > > >> should continue my efforts, perhaps by finding alternative instructions > > >> for creating UEFI USB sticks for installation. > > >> > > >> Best, Guy > > >> > > > > > > > > > OK, then, I read somewhere that DVD-ROM installations will install either > > > UEFI or Legacy, depending on the setting of the BIOS. So, I tried > > > burning a DVD w/ Qubes and running that. I get the same error as above, > > > including the efi time problem (which I suspect also shows the install is > > > going to UEFI), so it looks like when I do succeed in installing from a > > > UEFI media, I simply run headlong into a software bug related to my newer > > > hardware. I can't find any info on the bug online and have no idea how I > > > might fix it. Qubes, then, looks like it's out for me. This is the 2nd > > > time I've tried to use Qubes and run into severe problems. Oh well, > > > would be a great OS to be using, but if I can't, I can't. > > > > If you do want to give this another go at some point, try this one: > > https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-freezes-before-getting-to-anaconda--disable-efi-runtime-services > > . It's an ugly solution but let me get Qubes installed on a troublesome > > computer. > > Hi awokd: Thanks for the astute reply. I've been meaning to mention on this > board that I tried exactly what you are suggesting. And, yup, Qubes > installed. However, there have been some problems. I'll open a new post > with my problems on that. > > Thanks again! > Guy
Apparently a new post will not be necessary. I did some digging on this users group and learned that the following command would enable my ethernet controller (so it wasn't a driver issue at all): qvm-pci attach --persistent --option permissive=true --option no-strict-reset=true sys-net dom0:00_1f.6 So, it took me only about 55 hours of tearing my hair out to get Qubes running on my computer. Admittedly, I'm not an IT professional, but I know a fair amount about linux systems, which I've been using for 12 years. If the goal is that more people adopt Qubes, it really should be a lot easier to install (and hopefully won't run into difficult bugs while running--have already had two boot ups where I couldn't get the qubes manager or any qube other than dom0 running. error was something like 'unable to open line 9 in qubes.qubes.manager'). Ok, so there are bugs in the UEFI firmware, but shouldn't it be possible to do a bit of testing in the code to see if the bug is there and then automatically implement some of the fixes on the UEFI troubleshooting page? And shouldn't an OS be able to recognize and run an Ethernet card w/o the user issuing root commands? Well, easy for me to say--I don't have the programming skills to actually contribute to Qubes and I realize the development team for Qubes isn't large and has limited resources. I persisted w/ Qubes because it seems to have some marvelous capabilities. So, kudos to the development team, albeit some frustration as well. Best wishes, Guy -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/839078fc-be72-453f-8cd0-0e4cf03ae039%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
