Re: [qubes-users] Problems with announced Fedora 35 templates
Hello user 'catacombs', Catacombs schrieb am Freitag, 10. Juni 2022 um 14:56:48 UTC+2: > > HI, I am not an extremely knowledgeable Qubes user, but, I did not want > your post to go on like no one cared. I am pretty sure the developers do > care, they just need to spend their time working on --- stuff. And that > might include exactly what will be helpful to you. > > I had some problems installing and using Fedora 35, and then updating it > later. Sigh. > > When I originally installed Qubes 4.1, I chose the option to update over > Tor. Used to be I needed to start the Tor Browser for that to work. If > nothing else, Tor Browser downloads really slowly. I once started to > download an iso of like a gigabyte, and it would take hours. I am > suggesting that in some cases, trying to download can have timing issues > where some things drop out. And I can guess the system set up by our > Qubes developers is not supposed to do that. and I can not prove that it > does. Just when it rains here. My connection hiccups. I am just > tolerant and try again. > > I like the solution I think the developers are working on right now. > > https://github.com/QubesOS/qubes-issues/issues/7544 > > Which explains itself. > Thnaks for making me aware about the planned release of Qubes OS 4.1.1. With kind regards, Viktor -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b0f8b444-e0f7-4ad4-ada6-6c51f3c0b150n%40googlegroups.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Demi, Demi Marie Obenour schrieb am Freitag, 10. Juni 2022 um 23:42:57 UTC+2: > > >> I've not modified anything - and - the "Global Settings" look OK. > > >> > > >> I tried to open a console in 'sys-firewall' - but - can't login :-( > > >> > > >> I had expected that I could do so, using my credentials, i.e. user > 'vr' > > >> plus my password ... > > >> > > At least in the default setup (no sys-gui-gpu), your credentials are > specific to dom0. Everything else will let you log in on the console > as any valid user without a password. “root” will give you a root > shell, while “user” will give you a shell as the same user that GUI > programs run as. > Thanks for that clear explanation. > > > I tried to open a console in 'sys-firewall' - and - could not login. > > > > > > However, I (obviously) could open a terminal in 'sys-firewall' ... > > > > > > Here's the content of /etc/qubes-rpc/ : > > > > > > [user@sys-firewall ~]$ cd /etc/qubes-rpc/ > > > [user@sys-firewall qubes-rpc]$ ls > > > qubes.Backup qubes.PdfConvert qubes.SuspendPostAll > > > qubes.ConnectTCP qubes.PostInstall qubes.SuspendPre > > > qubes.DetachPciDevice qubes.ResizeDisk qubes.SuspendPreAll > > > qubes.Filecopy qubes.Restore qubes.USB > > > qubes.GetAppmenus qubes.SaltLinuxVM qubes.USBAttach > > > qubes.GetDate qubes.SelectDirectory qubes.USBDetach > > > qubes.GetImageRGBA qubes.SelectFile qubes.UpdatesProxy > > > qubes.Gpg qubes.SetDateTime qubes.VMRootShell > > > qubes.GpgImportKey qubes.SetMonitorLayout qubes.VMShell > > > qubes.InstallUpdatesGUI qubes.ShowInTerminal qubes.WaitForSession > > > qubes.OpenInVM qubes.StartApp > > > qubes.OpenURL qubes.SuspendPost > > > [user@sys-firewall qubes-rpc]$ > > > > > > > With Fedora 34 having reached EOL now, is there anything else I can do, > > other than a complete new installation of Qubes OS R4.1 ? > > Installing “qubes-core-agent-dom0-updates” in sys-firewall’s template > should fix the problem. > I checked which 'qubes-core' packages are installed in the 'sys-firewall' VM on my system. Here are the results: [user@sys-firewall ~]$ [user@sys-firewall ~]$ dnf list --installed | grep qubes-core qubes-core-agent.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-dom0-updates.x86_644.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-nautilus.x86_644.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-network-manager.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-networking.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-passwordless-root.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-qrexec.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-systemd.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current [user@sys-firewall ~]$ So the package is installed - but - it is on version '4.0.65-1.fc34'. - That does not look right to me ... Do you have any further suggestions, what I could still try? Or should I just wait until the dev-team will release Qubes OS version 4.1.1? With kind regards, Viktor -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d82121f8-a944-4707-892b-952cb1505dfen%40googlegroups.com.
Re: [qubes-users] qubes update -- how to hold an old kernel ??
On Saturday, June 11, 2022 at 1:09:47 AM UTC+2 haa...@web.de wrote: > > Which kernel version do you need to hold? You can update a subset of > > packages by giving them as arguments to qubes-dom0-update, but I would > > like to know what the forseeable problems are. > > The reason is simple: all (!) 5.x xen kernels I tested so far > crash/freeze my system in less than 5 minutes, often only seconds (open > issue on github since 18 months). Therefore I keep a 4.19 kernel for xen > (only) -- until now the updater respected that: it installed some new > 5.x kernel and kernel-latest. Every single time, I bravely try them out, > and each time they crash: each time I can revert back to 4.19 by a > linux-life usb hack. > > Last kernel update wants to remove my 4.19 kernel, and no way I can > accept that, given the history. ( again a curse on Intel and Dell for > their buggy hardware ). > > best, Bernhard > > Same here (Dell XPS13). The only usable dom0 kernels are 4.x and 5.4.88 (already gone :-0) and 5.4.175 (please let me keep that!). Everything else either crashes dom0 (e.g., 5.15) or stalls sys-usb (e.g. 5.12.). It says "00:14.0 USB controller problem", might be a usb3.0 problem, tried various things, nothing helped, my BIOS has no option to disable xHCI. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/27cf7fb7-3288-451a-8b74-83ea04f8d5een%40googlegroups.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
On Thursday, June 9, 2022 at 1:10:45 AM UTC-4 viktor@gmail.com wrote: > Hello Qubes Community, > > > Here's the content of /etc/qubes-rpc/ : >> >> [user@sys-firewall ~]$ cd /etc/qubes-rpc/ >> [user@sys-firewall qubes-rpc]$ ls >> qubes.Backup qubes.PdfConvertqubes.SuspendPostAll >> qubes.ConnectTCP qubes.PostInstall qubes.SuspendPre >> qubes.DetachPciDevicequbes.ResizeDiskqubes.SuspendPreAll >> qubes.Filecopy qubes.Restore qubes.USB >> qubes.GetAppmenusqubes.SaltLinuxVM qubes.USBAttach >> qubes.GetDatequbes.SelectDirectory qubes.USBDetach >> qubes.GetImageRGBA qubes.SelectFilequbes.UpdatesProxy >> qubes.Gpgqubes.SetDateTime qubes.VMRootShell >> qubes.GpgImportKey qubes.SetMonitorLayout qubes.VMShell >> qubes.InstallUpdatesGUI qubes.ShowInTerminalqubes.WaitForSession >> qubes.OpenInVM qubes.StartApp >> qubes.OpenURLqubes.SuspendPost >> [user@sys-firewall qubes-rpc]$ >> > > With Fedora 34 having reached EOL now, is there anything else I can do, > other than a complete new installation of Qubes OS R4.1 ? > > Sorry for not replying for a while but somehow I had been blacklisted from posting to the forum. Still not sure why that happened. I did reply by email but that bounced with a forum gateway denial response. I could login to the forum but it would not let me reply to anything. Other Discourse forums were also giving me problems so its possible somebody was spamming using my email address and thus put me on some kind of global blacklist, but that is just a guess. It looks to me that your current sys-firewall template is not up to date for your current R4.1 version, or just broken. If you have any other templates on your system (e.g. debian-11, fc35-minimal, fc35-xfce ) you might want to try switching sys-firewall to something else and then try to use qvm-template to download a working template of the f35 flavor. If that does not work you might try to just download a new template manually from here: https://yum.qubes-os.org/r4.1/templates-itl/rpm/ If needed, you will need to move that rpm to media accessible to your dom0 for the local rpm utility install. Once that template is installed, update the template asap, and then you should switch your sys-firewall to use that template and then try qvm-template again. Once sys-firewall has an up-to-date and working template this problem should be resolved. btw - I learned this the hard way myself years ago (R3.1 days) and now I always keep an extra unmodified template around for emergencies such as this. I also use a different and more simplified template tailored explicitly for both sys-net and sys-firewall so that future updates are less likely to break my connectivity. If anything happens to my connectivity I can just switch one or both VM's to use that alternate template while I debug the problem. When migrating to Qubes R4.1 I also had a similar problem after restoring my old templates from backup onto the new Qubes R4.1 system. The old templates did not work correctly with the new system so I needed to get a pristine fc35 template to get things working while I upgraded my older fc34 templates in place. Mixing the two on the new system was just a can-of-worms and updating them all in place to f35 is advisable rather than leaving them around as fc34 in a broken state. If your customizations to your fc34 template was minimal then making a clean break to fc35 is likely a very good idea. I hope this helps. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d4a863a6-09bb-4f71-92a2-6ebea4c2bd49n%40googlegroups.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Jun 11, 2022 at 12:41:08AM -0700, Viktor Ransmayr wrote: > Hello Demi, > > Demi Marie Obenour schrieb am Freitag, 10. Juni 2022 um 23:42:57 UTC+2: > > > > >> I've not modified anything - and - the "Global Settings" look OK. > > > >> > > > >> I tried to open a console in 'sys-firewall' - but - can't login :-( > > > >> > > > >> I had expected that I could do so, using my credentials, i.e. user > > 'vr' > > > >> plus my password ... > > > >> > > > > At least in the default setup (no sys-gui-gpu), your credentials are > > specific to dom0. Everything else will let you log in on the console > > as any valid user without a password. “root” will give you a root > > shell, while “user” will give you a shell as the same user that GUI > > programs run as. > > > > Thanks for that clear explanation. You’re welcome! > > > > I tried to open a console in 'sys-firewall' - and - could not login. > > > > > > > > However, I (obviously) could open a terminal in 'sys-firewall' ... > > > > > > > > Here's the content of /etc/qubes-rpc/ : > > > > > > > > [user@sys-firewall ~]$ cd /etc/qubes-rpc/ > > > > [user@sys-firewall qubes-rpc]$ ls > > > > qubes.Backup qubes.PdfConvert qubes.SuspendPostAll > > > > qubes.ConnectTCP qubes.PostInstall qubes.SuspendPre > > > > qubes.DetachPciDevice qubes.ResizeDisk qubes.SuspendPreAll > > > > qubes.Filecopy qubes.Restore qubes.USB > > > > qubes.GetAppmenus qubes.SaltLinuxVM qubes.USBAttach > > > > qubes.GetDate qubes.SelectDirectory qubes.USBDetach > > > > qubes.GetImageRGBA qubes.SelectFile qubes.UpdatesProxy > > > > qubes.Gpg qubes.SetDateTime qubes.VMRootShell > > > > qubes.GpgImportKey qubes.SetMonitorLayout qubes.VMShell > > > > qubes.InstallUpdatesGUI qubes.ShowInTerminal qubes.WaitForSession > > > > qubes.OpenInVM qubes.StartApp > > > > qubes.OpenURL qubes.SuspendPost > > > > [user@sys-firewall qubes-rpc]$ > > > > > > > > > > With Fedora 34 having reached EOL now, is there anything else I can do, > > > other than a complete new installation of Qubes OS R4.1 ? > > > > Installing “qubes-core-agent-dom0-updates” in sys-firewall’s template > > should fix the problem. > > > > I checked which 'qubes-core' packages are installed in the 'sys-firewall' > VM on my system. > > Here are the results: > > [user@sys-firewall ~]$ > [user@sys-firewall ~]$ dnf list --installed | grep qubes-core > qubes-core-agent.x86_64 4.0.65-1.fc34 > @qubes-vm-r4.0-current > qubes-core-agent-dom0-updates.x86_644.0.65-1.fc34 > @qubes-vm-r4.0-current > qubes-core-agent-nautilus.x86_644.0.65-1.fc34 > @qubes-vm-r4.0-current > qubes-core-agent-network-manager.x86_64 4.0.65-1.fc34 > @qubes-vm-r4.0-current > qubes-core-agent-networking.x86_64 4.0.65-1.fc34 > @qubes-vm-r4.0-current > qubes-core-agent-passwordless-root.x86_64 4.0.65-1.fc34 > @qubes-vm-r4.0-current > qubes-core-agent-qrexec.x86_64 4.0.65-1.fc34 > @qubes-vm-r4.0-current > qubes-core-agent-systemd.x86_64 4.0.65-1.fc34 > @qubes-vm-r4.0-current > [user@sys-firewall ~]$ > > So the package is installed - but - it is on version '4.0.65-1.fc34'. - > That does not look right to me ... > > Do you have any further suggestions, what I could still try? You should be able to manually change your DNF repositories in sys-firewall’s template. “dnf --best --refresh distro-sync” should then take care of the rest, unless I have missed something. > Or should I just wait until the dev-team will release Qubes OS version > 4.1.1? You should not have to do this. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKkyuUACgkQsoi1X/+c IsFmyQ/+Mvzo04A53PLM8Oc6Iu3hZzK6MbqMNon9Tc+YGDU2Wizwhdj02Xy0XXIt BshmNrnPn0bAtZs5hbcjRFc1Bvk6fnQ8/7tscHEuauqnXe1yN8TsB/Zt6JWxKAbl VvkWb33/+fGZyMn3FJxrvsDRMgjYDn020hEfic+R0jAmJubpzfBva0xXP8Pgd2Aa mAV4YGAlKzXRny142yQt8m0iDXyZGQe3gAdIyMXuL0q30KKF4L6rbKNDX8y5dJ3/ I05kakpi+MZyiVzO2d2U5Ylen3RE1J+zvhVkTwUGX3S2zOwWdrW4iTgYvF8Bvxxh Hfu8WpBjgkLxZKaoh8yy/HbzJEmrVPRs4gMc8Cvwb1umcseszDZXVOtyMsSZp+T3 nBEvdZ2LpTezd0qKL2p2AiyvEZVjQQdBDGKQ3o1b2lVWVt5fR3dSFC9DLizVsabz kV3k+tVl6MfUPvWIZdKondxDutxTLb5DIfGfKh3VfQr7Dhzpvs6lVJN3W/V8nMDm EbiHceJF9AOzkU+fhueMi7srxxkgO46BNFttsNnjVxhJEp5ARLvPSH0ckNYweZV2 M7IUwUg4pmMCtrY8cM2li1977MkbNoHyGRlnIcORvzD/su1wc2OZOeg8S0wnx4tU kP8uelWiM2sQaIY30CRL6F/8itnYXs6sykKr0exeoktOAdbA2lM= =p7Aa -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this gro
Re: [qubes-users] Problems with announced Fedora 35 templates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Jun 11, 2022 at 08:52:18AM -0700, Steve Coleman wrote: > > > On Thursday, June 9, 2022 at 1:10:45 AM UTC-4 viktor@gmail.com wrote: > > > Hello Qubes Community, > > > > > > Here's the content of /etc/qubes-rpc/ : > >> > >> [user@sys-firewall ~]$ cd /etc/qubes-rpc/ > >> [user@sys-firewall qubes-rpc]$ ls > >> qubes.Backup qubes.PdfConvertqubes.SuspendPostAll > >> qubes.ConnectTCP qubes.PostInstall qubes.SuspendPre > >> qubes.DetachPciDevicequbes.ResizeDiskqubes.SuspendPreAll > >> qubes.Filecopy qubes.Restore qubes.USB > >> qubes.GetAppmenusqubes.SaltLinuxVM qubes.USBAttach > >> qubes.GetDatequbes.SelectDirectory qubes.USBDetach > >> qubes.GetImageRGBA qubes.SelectFilequbes.UpdatesProxy > >> qubes.Gpgqubes.SetDateTime qubes.VMRootShell > >> qubes.GpgImportKey qubes.SetMonitorLayout qubes.VMShell > >> qubes.InstallUpdatesGUI qubes.ShowInTerminalqubes.WaitForSession > >> qubes.OpenInVM qubes.StartApp > >> qubes.OpenURLqubes.SuspendPost > >> [user@sys-firewall qubes-rpc]$ > >> > > > > With Fedora 34 having reached EOL now, is there anything else I can do, > > other than a complete new installation of Qubes OS R4.1 ? > > > > > Sorry for not replying for a while but somehow I had been blacklisted from > posting to the forum. Still not sure why that happened. I did reply by > email but that bounced with a forum gateway denial response. I could login > to the forum but it would not let me reply to anything. Other Discourse > forums were also giving me problems so its possible somebody was spamming > using my email address and thus put me on some kind of global blacklist, > but that is just a guess. The forum mirror of the mailing list is read-only. Not sure if that is the culprit. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKky7IACgkQsoi1X/+c IsH/AhAAnVrY9/dKsAeplvGFe4YStiCDMOZ4OjhVWVZUUWMDBLliWO97BM6Mngd6 gq1RTUF4tyXoaCEu3hgChB/zlWJsRAZeaJcR1AXixULHvIy5zDdbUGqhB5fthqTm 9pOeKCElb9SXKbwpWXkSoP3XidYRn+nG4wrGziASfHRI7LTvIRBVa08Zr5b0Bn8f ngmFjMmQ5LTdYf+1cszfjwvL/YsVAvOfCwShuixt8EjFt30f0fTAlYEQ1At7aTdL ISp+P4BLgg01oZ63+gHyW8aYpRNtMjCig4EmTHXhfruI5Z9j+uK7FpYZ9jhE5V/B Yg4bIvGxWXIM5PoCKSuU3/jqG+9m9R/X7iCbw7Bv6YAXgBHTXwuVczj74L1Afr2O /5wupFiMQGVXetiVZPpdsXPEnHrmcpzdoV7cJ3yKdnF5YGTpbEui3fL6c3w+Hpj/ 9GOkUhs4/y+8myNEhq5EGpuFCHnUBeOjWznlarITOwSXdKIwWi2NKj/PL27k3eSf htsNhI7LMRC9j5rC/SVFoItZWfmRJ/nabxdzIBL1Gwb5ewYKMp1h9T5Pkvltg021 i0oy8Ief4r3QyIoeHwYpeE3zqwTa7G+3zCRrVtGUVEOkysYM4y2xJcBUhgihfH0b fx+49ILWrBeMeorTFCy/2dKlW01m1z6hF383RwgNdsacKC/HM+U= =j6j5 -END PGP SIGNATURE- -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YqTLsnbZ1bw7x1hQ%40itl-email.
Re: [qubes-users] qubes update -- how to hold an old kernel ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 (FYI, it looks like you forgot to CC the mailing list) On Sat, Jun 11, 2022 at 10:45:44AM +0200, haaber wrote: > Dear Marie, > > > > > Which kernel version do you need to hold? You can update a subset of > > > > packages by giving them as arguments to qubes-dom0-update, but I would > > > > like to know what the forseeable problems are. > > > > > The reason is simple: all (!) 5.x xen kernels I tested so far > > > crash/freeze my system in less than 5 minutes, often only seconds (open > > > issue on github since 18 months). Therefore I keep a 4.19 kernel for xen > > > (only) -- until now the updater respected that: it installed some new > > > 5.x kernel and kernel-latest. Every single time, I bravely try them out, > > > and each time they crash: each time I can revert back to 4.19 by a > > > linux-life usb hack. > > > > > Last kernel update wants to remove my 4.19 kernel, and no way I can > > > accept that, given the history. ( again a curse on Intel and Dell for > > > their buggy hardware ). > > > > Try removing one of the newer kernels on your system. > That did not help. But I could use the output and manually install all > the lines qubes-update suggests, but not remove the old-kernel. > qubes-update did download them all. I would have to make sure not to > introduce a security flaw (not checking signatures), and invoking maybe > dnf directly with the correct full package name?: the (terminal > qubes-update) line qubes-dom0-update unpacks the packages in a temporary directory. They are then copied to an anonymous temporary file in the final directory by rpmcanon, and only linked into the filesystem if rpmcanon verifies the signature successfully. The signature is then checked *again* by rpmkeys before you even get the “Is this ok [y/N]” prompt. In short, no, you will not introduce a security flaw doing this. > microcode_ctl.x86_64 2.1-35.qubes1.fc25 qubes-dom0-cached > > would have to become one word, but I do not know the "linking char": a > dot? like > > microcode_ctl.x86_64.2.1-35.qubes1.fc25 > > or underscore? like > > microcode_ctl.x86_64_2.1-35.qubes1.fc25 You need to move the architecture to the end, and then use a dash to join the name and epoch/version. In your example, you would run $ sudo dnf upgrade microcode_ctl-2.1-35.qubes1.fc32.x86_64 > But I am unsure if that is a "safe way" to go It is. > > Also, would you > > be willing to try disabling panic_on_oops? That won’t fix the bug, but > > it has a chance of leaving the system running afterwards. Adding > > kernel.panic_on_oops=0 and kernel.panic_on_warn=0 to /etc/sysctl.conf > > should do the trick. > > I'll try that, of course. I'll keep you informed ... That would be great. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKkzgMACgkQsoi1X/+c IsFILA/+J7K+pc8P60DufMajZscukK6blfOFUd0BCyb9uEWgoVaE/b0K4hXDCVRE 3sud/2qz6arpjZxCdmrNk48/0S2r+lpeAHghhM/osOWNBb/1b4jZdgH2bJemaS5N KSuoLDCNpqUhKN8kzNP6XiuMZrkvluv2nsRr+w1cbdJREB92PFyJGvkIJfqHQOuE 1lJu39qW/msIJrU1Zki3f9cUsJ9vG9pFVOo98P7Uxa6C9Utu2wP9OZdLNojOMEDc yXmob1YwbNJYiFW6SN7blCO79Qhgo+WZaSq0CYxDnM7r8C0YJbd64UNOR+F0NuA8 2f9ySzc+kB9HLUqf3iJOaYXLZIbvHUQaSUQaY0zRVrjhg8gt2p3ylTyjQwzsOza0 P/jKclYz+woXJwQr8Pq7CeIvcUM9doinB+u/9NCjDiQiUuJIINrHPbZ9kuQvhDoi QvMZ5Pm6fp6a6uya+FeNfVSoQ4V2xCYlgfW5cD0noyldrzqNFrQ9Qz5kCLuMAawS NVL3OOmzyENSJrLntaZkRnBr2X4H6H0s5C1zBCE47gsoW47R5x/91wuyOAk2r2zO gi5mFKwSx7in0H8umSwAJ4o2yHsbnesuSSVmTAZW2vIV/TWOSLAMHmpuj1iI6M7w TGM9ffsUDsEATlEUVdBNBsM4JlVe4Uxh26glzd73v0OI9gOwSQw= =U8A5 -END PGP SIGNATURE- -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YqTOA7V4NYy/KAPw%40itl-email.
Re: [qubes-users] qubes update -- how to hold an old kernel ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Jun 11, 2022 at 10:54:39AM +0200, haaber wrote: > Dear Marie, > > > Try removing one of the newer kernels on your system. > > lets think it the other way round: if I, say, safe-copy the > vmlinuz and initramfs-files of my 4.19 kernel, can I just play them back > to the EFI/qubes folder & modify the xen.cfg "as usual" in case of 5.x > kernels bugging? As a kind of "very manual install" -- or wouldn't that > work ?? That would likely leave you without the needed kernel module packages, which would be bad. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKkzk8ACgkQsoi1X/+c IsH2Dw//fAMldDf1ghepx1mz2tBBUz3zij5TwNvYAIhrWRMFDly8I1m9oChRzQh1 taWE60N8Cm9F14DKFQeY469ZgUbjbtRsKcJGjopsokKtRJ8o3sFZQ1fcNm8aTsIh av8nsL+A86P4YDp3LDeLPn9pxXbDDq78FhDxBgOLKALECxUJMAstkpCIFcEoCC7m WY30nHop6k+u87nZw4Db8zbEPORmBpcstaUSLPLtkwyHg1m0qLcA3lkuhikU80h0 +rxo42SSYwMxFoeyAHbQ9rhn+nOVnL8osFR4z+LZ4x77cVwTVIIYKYqQE4GnSJkw XehQ2SLIhQd4E0CZ6NZjZcCHLvkSYepGpxQxn8whxz5LR2VT/KkzOgn9ZykHU5t5 oEuU4+K4PShhlZAIgEmwpo+QMKEY0DENIJL5i94ao8NS28lKHvlPkefOtJh4Q/oI kuzolBI+wEytm75MdWJXqnVcFsKiqUW2JobnxfV2wnAho6Q4AMYgK6XL4GiB8VyP 1GkncV4SUxzoxUHsxg9N15WTzZu5M6oM0m5szIPGx409CxuK35U0v7vLXVgLSe/P pr1PHLMwupXvvQnpXWJHoA4NZ0OlOpvb+mg2dIy425+SfG/HZcj/ret2rP28WaYk a1McpvNYuZHzZc+Vf0/Ulz1YV5+quWA8MxKhnKE0fdgdFabGgdI= =SZac -END PGP SIGNATURE- -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YqTOT%2BN5EjZOvyCf%40itl-email.
Re: [qubes-users] qubes update -- how to hold an old kernel ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Jun 11, 2022 at 03:00:09AM -0700, Peter Palensky wrote: > > On Saturday, June 11, 2022 at 1:09:47 AM UTC+2 haa...@web.de wrote: > > > > Which kernel version do you need to hold? You can update a subset of > > > packages by giving them as arguments to qubes-dom0-update, but I would > > > like to know what the forseeable problems are. > > > > The reason is simple: all (!) 5.x xen kernels I tested so far > > crash/freeze my system in less than 5 minutes, often only seconds (open > > issue on github since 18 months). Therefore I keep a 4.19 kernel for xen > > (only) -- until now the updater respected that: it installed some new > > 5.x kernel and kernel-latest. Every single time, I bravely try them out, > > and each time they crash: each time I can revert back to 4.19 by a > > linux-life usb hack. > > > > Last kernel update wants to remove my 4.19 kernel, and no way I can > > accept that, given the history. ( again a curse on Intel and Dell for > > their buggy hardware ). > > > > best, Bernhard > > > > > Same here (Dell XPS13). The only usable dom0 kernels are 4.x and 5.4.88 > (already gone :-0) and 5.4.175 (please let me keep that!). > Everything else either crashes dom0 (e.g., 5.15) or stalls sys-usb (e.g. > 5.12.). > > It says "00:14.0 USB controller problem", might be a usb3.0 problem, tried > various things, nothing helped, my BIOS has no option to disable xHCI. I am hesitant to ask, since it would require running unsigned code (yuck!), but would you be comfortable doing a kernel git bisection? That would allow figuring out exactly which commit caused the problem, and would vastly improve the likelihood of the bug being fixed. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKkzwoACgkQsoi1X/+c IsH4GBAAjTkR270uIN2dukR91U3Ed/c6SYkY3VDiIcyACBg4eYSnKp15U64sfqcX tormUiDo5EJgVJmMn5//XovQh6HhKC0NxDz29Gt3bVMTaUXKhxZsTYNdq0gaNxWZ soYVwIW0e5+qXnu5vMytl2mLJaFKo+an1o4KxooF89D8IDHjY1hThOKOB8REPsEu sOY1xal74dxJVNiWivJaHd0Unru41Of6oegFZQVqZ2fty7NJiSPBdu6GB591rBBH jbce2YfwR5R4nllpvx3lKHZxxLfwvTHYbz3BxLpMvdof2IheE2+cxv2vstTT6ykV t9SYnApBT3ytddgypa6iOsmhlccCJ/h+TZEvJN+1/HNBTRzZcSE2c4Fv9+OxTa03 NK2wrIDYRa6LeZHe6RJU8ykeJB+m1Ojap+N2J1nhlC+/5C/bUhPvDScwfXbrP9pJ JyGAvuonGXagBY6vjg2tSMM4eeNpetHURHm5iuufVsarlAUg/IQkzERhnWY2saov DB1hmouC0aKf8O5riLKmudQWNGl+CY7VCMAJu97GHBBPN8edSEhSg5jXoRA4JRrV +5nPf8VQfgry+IEsSeSqWedcU6CJ0Q14j2LxsklrqANS7pTrh9eGQFLPALptiWTM 7Zl6ODTqqTZyv/XQCnrg34LUEH08tiubr7lN3BLfNfiX+Wx+3g0= =S7ZL -END PGP SIGNATURE- -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YqTPCSB3lZrCpAWk%40itl-email.