On Saturday, June 11, 2016 at 5:13:41 PM UTC+2, gabi...@gmail.com wrote:
>
> On Tuesday, 31 May 2016 20:47:37 UTC+1, patie...@terminalmoronicy.com 
>  wrote: 
> > On Sunday, May 29, 2016 at 7:34:46 PM UTC-4, Marek Marczykowski-Górecki 
> wrote:-----BEGIN PGP SIGNED MESSAGE----- 
> > 
> > Hash: SHA256 
> > 
> > 
> > 
> > On Thu, May 26, 2016 at 08:25:48PM -0700, patie...@terminalmoronicy.com 
> wrote: 
> > 
> > > I also have a t460s and encountered many of the problems above.  I 
> updated the qubes patches (excluding pvusb) to apply against kernel v4.5.2 
> and tossed in an out-of-tree patch for Skylake.  Bumping to 4.5.5 didn't 
> require any further patch-wrangling (except that the Skylake patch had been 
> merged in the meantime). 
> > 
> > 
> > 
> > Was that patch backported also to 4.4.11? 
> > 
> > 
> > 
> > 
> > 
> > Yes - I checked and the particular patch that fixed suspend for me is 
> also in 4.4.11.  I am now curious how many of the p-states improvements 
> have been backported as well...  
> >  > I've been running the result for a few days and everything seems to 
> be working well. 
> > 
> > > 
> > 
> > > https://github.com/patientnil/qubes-linux-kernel/tree/devel-4.5 
> > 
> > > 
> > 
> > > Notes: 
> > 
> > > 
> > 
> > > - The pvusb patch looks the trickiest to port, and the associated 
> tools show that scary experimental warning. I didn't pursue it, it's 
> sitting there commented out. 
> > 
> > 
> > 
> > Yes, ignore it. In fact it is already commented out in series.conf file 
> > 
> > for some time. 
> > 
> > 
> > 
> > > - Sound, trackpoint buttons, wifi, suspend all work (though I haven't 
> tried reenabling TPM yet).   
> > 
> > 
> > 
> > Camera also works, and enabling the TPM in TPM 1.2 mode does not 
> interfere with suspend.  The system will not suspend/resume properly if the 
> TPM is set to PTT mode (using my patched 4.5.5 kernel in Qubes 3.1 - I have 
> not tried a 4.4.11 kernel). 
> > 
> > I have not yet played with AEM. 
> > 
> > > - I get occasional screen artifacting (horizontal lines) but I am 
> using the qubes-R3.1 display packages - before a reinstall I had better 
> luck with updates in the unstable repo. 
> > 
> > 
> > 
> > Are those artifacts across the whole screen, or only particular windows? 
> > 
> > 
> > 
> > 
> > The artifacts go all the way across the screen, without stopping at 
> window boundaries.  They are rare, and seem to be "fixed" when moving 
> windows around. 
> >  > - While updating the kernel config, I had some sort of snafu, and I 
> later had to go reenable a bunch of fundamental things like IP_MASQ.  The 
> config should be reexamined (I'm planning to pare it down to just the 
> things I need).  If this was to be merged to the main tree it should be 
> redone.  Presumably there are rules of some sort as to what to include? 
> > 
> > 
> > 
> > Generally the rule is "enable all drivers are modules". 
> > 
> > 
> > 
> > 
> > Good to know - if I update my repo for later 4.5 kernels I will update 
> the config to respect this policy. 
> >  > [snip] 
> > 
> > 
> > -tom 
>
>
> Hi Tom, 
> I'm kind of stuck here: 
> I ran the commands that installed the kernel-4.4.10-9 
> sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel 
> sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel-qubes-vm 
>
> And in the Global Settings kernel-4.4.10-9 is selected. 
>
> But Xen cannot continue when starting. I need to Wait for the Xen screen 
> to prompt and manually and quickly do Tab > Advanced settings > Select the 
> kernel 4.1.13.9 (old one) 
> Once the machine is booted, kernel-4.4.10-9 is still selected on Global 
> settings. 
> This solved the Wifi issue, but not the sleep issue, and it has the pain 
> of manually selecting the Old kernel on each boot. 
>
>
> If I change the Global Settings to use the 4.1.13.9 (old), the machine 
> boots with no problems, but I do not have Wifi. 
>
> How can I remove the kernel-4.4.10-9 from booting? 
> Or need to format it again all together. 
>
> Thanks, 
> Gabriel 
>

There is a difference between what kernel your dom0 will boot when you 
start your computer and what kernel your other VMs will boot with when you 
start them. The yum package *kernel-qubes-vm* package installs/upgrades the 
kernel your VMs will boot and *kernel* upgrades what kernel your 
computer/dom0 will boot. The 'Default kernel' under 'Global settings' only 
affects what kernel the VMs inside Qubes will boot afaik, not the dom0 
kernel.

You control what kernel dom0 will boot inside */boot/efi/EFI/qubes/xen.cfg*. 
At the top you can set the default variable to the name of one of the 
sections after it, you should be able to find your 4.1 kernel there. Change 
that value, save the file and from now on what kernel is booted should be 
changed. Beware that any kernel upgrade will probably change the default to 
the newest one again.

/Linus

-- 
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/f67a0f76-beb2-4183-b5cf-c187be81622c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to