Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Demi, Viktor Ransmayr schrieb am Montag, 13. Juni 2022 um 21:14:57 UTC+2: > > On Sun, 12 Jun 2022, 22:59 Demi Marie Obenour, < > de...@invisiblethingslab.com> wrote: > >> >> > You were right - but - I have no clue what went wrong & what to do next >> ... >> >> $ sudo sed -i 's/4\.0/4.1/g' /etc/yum.repos.d/qubes-r4.repo >> >> should fix that >> > > Upgrade of template is still running ... > > I'll provide another update as soon as it's finished. > It is still running, after more than 10 hours. - This should have finished by now, correct? Here are my notes & logs: ### Change the template for 'sys-firewall' back from 'debian-11' to 'fedora-34'. * Close all Study-VMs - and - close the affected 'sys-whonix' VM ... ### 2022-06-13 ~ 18:48 (UTC) * Perform the template change - and - get back here ;-) ### 2022-06-13 ~ 18:51 (UTC) Open the 'fedora-34' template & apply the suggested change - OK? - See "Log-002". ### 2022-06-13 ~ 19:00 (UTC) Start the update of 'fedora-34' template suggested by Qubes Updater - See "Log-003". * 2022-06-13 ~ 19:15 (UTC) -> Still ongoing * 2022-06-13 ~ 19:30 (UTC) -> Still ongoing * 2022-06-13 ~ 20:00 (UTC) -> Still ongoing * 2022-06-13 ~ 21:00 (UTC) -> Still ongoing * ... * 2022-06-14 ~ 05:45 (UTC) -> Still ongoing ??? ### Log-002 [user@fedora-34 ~]$ cd /etc/yum.repos.d [user@fedora-34 yum.repos.d]$ cat qubes-r4.repo [qubes-vm-r4.0-current] name = Qubes OS Repository for VM (updates) baseurl = https://yum.qubes-os.org/r4.0/current/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/current/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=1 [qubes-vm-r4.0-current-testing] name = Qubes OS Repository for VM (updates-testing) baseurl = https://yum.qubes-os.org/r4.0/current-testing/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/current-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r4.0-security-testing] name = Qubes OS Repository for VM (security-testing) baseurl = https://yum.qubes-os.org/r4.0/security-testing/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/security-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r4.0-unstable] name = Qubes OS Repository for VM (unstable) baseurl = https://yum.qubes-os.org/r4.0/unstable/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/unstable/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-unstable gpgcheck = 1 enabled=0 [user@fedora-34 yum.repos.d]$ [user@fedora-34 yum.repos.d]$ [user@fedora-34 yum.repos.d]$ sudo sed -i 's/4\.0/4.1/g' /etc/yum.repos.d/qubes-r4.repo [user@fedora-34 yum.repos.d]$ [user@fedora-34 yum.repos.d]$ [user@fedora-34 yum.repos.d]$ cat qubes-r4.repo [qubes-vm-r4.1-current] name = Qubes OS Repository for VM (updates) baseurl = https://yum.qubes-os.org/r4.1/current/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/current/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=1 [qubes-vm-r4.1-current-testing] name = Qubes OS Repository for VM (updates-testing) baseurl = https://yum.qubes-os.org/r4.1/current-testing/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/current-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r4.1-security-testing] name = Qubes OS Repository for VM (security-testing) baseurl = https://yum.qubes-os.org/r4.1/security-testing/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/security-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r4.1-unstable] name = Qubes OS Repository for VM (unstable) baseurl = https://yum.qubes-os.org/r4.1/unstable/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/unstable/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-unstable gpgcheck = 1 enabled=0 [user@fedora-34 yum.repos.d]$ ### I intend to cancel the upgrade operation. - Any
Re: [qubes-users] qubes update -- how to hold an old kernel ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Jun 13, 2022 at 10:28:43PM +0200, haaber wrote: > Dear Marek, > > kernel testing would be so much easier if the xen.cfg would allow an > option like > > default=menuselect > > to get a boot menu -- instead of > > default=[5.16.whatever] > > which makes it actually necessary to "hack" the xen.cfg via a > live-linux-usb intrusion if a kernel should fail to work ... that > produces an attack-vector & is annoying. > > > Maybe such a function exists already? If not that would be a feature > request! That's the main reason why Qubes 4.1 doesn't use xen.cfg at all. There is standard grub, where you have menu, editor etc. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmKnnvMACgkQ24/THMrX 1ywXBAf+PU9g3NQ81dwzbVWBzM1x1cRO9MBCsTb/oalKoU9ywOOvok+wDU5pcaC8 8e5QHH0yn4eLFd5cT3x0OGCu6RY8IuPKbKRoUxfpoP+XyQL7Q3iuSEQJ08B8eUj1 Ia/OAjdDKR+IcwlCzSSQnkhyuDXTHwfvOe6nTVxVuykAXqfQgY1QVEUivCDLx475 bMOAkWjSRIt9xM9pKo/JTMYz4E/XJ6qxy3j/hvQO9V0gVjnBk+HICpEZ/y8IErx0 tczn9EejONvx5iH/6lUBQR7gq4p9ncHVnVRiT7Uim+Ha1GICUgZOv20HYlA/RsfI bFSD3aWKCB3DN5sdVHmnDUSlfH0E3g== =FHSZ -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/Yqee9GqPzitE4cCb%40mail-itl.
Re: [qubes-users] qubes update -- how to hold an old kernel ??
Dear Marek, kernel testing would be so much easier if the xen.cfg would allow an option like default=menuselect to get a boot menu -- instead of default=[5.16.whatever] which makes it actually necessary to "hack" the xen.cfg via a live-linux-usb intrusion if a kernel should fail to work ... that produces an attack-vector & is annoying. Maybe such a function exists already? If not that would be a feature request! Thank you, Bernhard There are a couple more options to choose from - for LTS kernels we keep some of them updated, even after the default is switched to the next one. For R4.0 there is for example kernel-419. You can check available options via `qubes-dom0-update --action=search kernel`. 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. Aaehm... It is my work computer, i need it every day and can not risk anything... Is there a safe/standard procedure in qubes to compile the bisects, add them to grub without removing the working kernel, etc.? Not that I am aware of, sadly. Marek (CCd) might have suggestions. For any tests, I usually place kernel+initramfs under some arbitrary name that does not interfere with version-based entries. And do that by installing kernel "manually", exactly to avoid dnf/rpm removing older packages. For the grub entry, I usually edit /boot/efi/EFI/qubes/grub.cfg manually (copy existing section and just replace file names). But regenerating it with grub2-mkconfig should be safe too. This does require manual cleaning after testing is finished, though... Here is example script to build and install kernel in dom0: #!/bin/sh set -e make olddefconfig make -j2 kver=$(make kernelrelease) sudo make modules_install sudo cp arch/x86/boot/bzImage /boot/vmlinuz-test sudo dracut -f --kver="$kver" /boot/initramfs-test.img it can be launched from kernel sources. > -- 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/33edb1a2-38dc-9b34-5ac3-b22a91c6e1b0%40web.de.
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Demi, On Sun, 12 Jun 2022, 22:59 Demi Marie Obenour, wrote: > > > You were right - but - I have no clue what went wrong & what to do next > ... > > $ sudo sed -i 's/4\.0/4.1/g' /etc/yum.repos.d/qubes-r4.repo > > should fix that > Upgrade of template is still running ... I'll provide another update as soon as it's finished. 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/CAAeSrGJpXF30vxeDYjTTYpdPfM-QGicFTVZXk2T61ZQNEr6uow%40mail.gmail.com.
