It took me a few days, but I think the solution I found is simpler.
At least for getting Qubes installed.  I still don't have it booting
from the hard drive, but I can do a rescue boot and proceed from there.

My computer is an H-P compact desktop.  The Qubes install (4.0-rc3 for
x86_64) doesn't like something about either the Intel ethernet or the
Intel i915, so it doesn't automatically try vnc and Xorg fails.
And with text, the disk autopart fails for lack of an encryption
password for the LVM partition.

I let the default (not text) install fail, unable to start Xorg.
I press Alt-Tab until I get the shell window.  I find the network
interface name by running networkctl.  I run dhclient with the
interface name as the sole argument.  I use ifconfig to find the
IP address that DHCP assigned.  I remove /var/run/anaconda.pid.
I run

 anaconda --vnc

On a remote computer behind the same router I start a vnc client and
connect to the Qubes target IP::5901.  I think the client (tightvnc
on Windows 8.1) defaults to port 5900, and the anaconda sets up 5901.

Just do the graphical install on the vnc client and all goes well right
up to the reboot failing to boot from the hard drive, which I consider
to be a separate problem.

On Tuesday, February 10, 2015 at 7:54:29 AM UTC-7, george wrote:
> No graphics available with Qubes kernels which prevents installation due 
> to anaconda issues.  I'm sure the following could be improved and maybe 
> all included in the kickstart file but that wasn't my priority.  I got 
> Qubes installed and working like this:
> 
> Before starting you need the kickstart file and the Fedora kernel rpm on 
> removable media (sdb1 in my case but check your own setup).  Similarly, 
> sda in the kickstart file may not be right for you.  Also check 
> language, keyboard and timezone.
> 
> Some wrinkles I found:
> - Don't change the hostname from "dom0" as it will break things
> - anaconda in text mode demands a user is set up
> - Qubes first-boot also sets up a user, couldn't skip this either
> - With two users strange stuff happened in first-boot
> - That's why I delete a user before doing anything and need root login
> - In one test run I saw nomodeset as a kernel parameter and that caused
>    graphics to fail, after finding that I never saw it again
> 
> Boot installation media and hit tab, adding (after "quiet")
> ks=hd:sdb1:/ks.cfg
> 
> Installation should run with no further interaction.
> Once it is complete change to another console (Alt-F2)
> # mount /dev/sdb1 /root
> # cp /root/kernel*.rpm /mnt/sysimage/var/lib/qubes/updates
> # umount /root
> 
> I chose /root as the mount point as it didn't seem to have anything 
> important in it. It worked so I didn't think any further about it.
> 
> Back to console 1 and press the finished key which will reboot.
> Still no graphics, so after boot finishes with a blank screen,
> find a text console to log in on as root.  Then
> 
> # userdel -r deleteme
> # yum install /var/lib/qubes/updates/kernel*.rpm
> # grub2-mkconfig -o /boot/grub2/grub.cfg
> # dracut -f
> # vi /etc/yum.repos.d/qubes-dom0.repo
>    add "exclude = kernel" at end of [qubes-dom0-current] section
> # passwd -l root
> 
> Reboot and (hopefully) enjoy.  Don't forget to change the LUKS password, 
> or put a proper one in the kickstart file if you're happy to can erase 
> it safely or keep it secure some other way.
> 
> So far so good for me.  There is a TPM but I haven't got round to 
> testing that yet (and it will be a while).

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8cc5e2a6-d0f6-4289-8095-c7b8caa2c1a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to