Consider having a 4.0.1 release

[andrewdavidwong]

Since Release 4.1 is still a long way off, let's consider issuing a new 4.0.1 ISO that includes all patches up to this point plus the new templates. Many of the rough edges of the initial 4.0 release have been smoothed out by now, so this might make it easier for current 3.2 users who have been watching 4.0 from the sidelines to upgrade.

[qubesissues]

@andrewdavidwong Are these smoothed out rough edges coming through with updates? Because my Qubes 4 was installed from the last Release Candidate and it still behaves terribly. I have to refresh the Qube manager 75 times per session (literally) and basically ever Issue I have posted is still not resolved. Including the fact that the dom0 never shows that it needs updating.

Is it possible that one of the bugs is that updates are not coming through? I am considering downgrading to 3.2 because my productivity is down about 30% since moving to 4.0 So if you say things are getting smother then maybe there is a problem with getting these updates and if I solve that then things are going to be better?

[qubesissues]

@andrewdavidwong Are these smoothed out rough edges coming through with updates? Because my Qubes 4 was installed from the last Release Candidate and it still behaves terribly. I have to refresh the Qube manager 75 times per session (literally) and basically ever Issue I have posted is still not resolved. Including the fact that the dom0 never shows that it needs updating.

Is it possible that one of the bugs is that updates are not coming through? I am considering downgrading to 3.2 because my productivity is down about 30% since moving to 4.0 So if you say things are getting smother then maybe there is a problem with getting these updates and if I solve that then things are going to be better?

[qubesissues]

@andrewdavidwong I can confirm that dom0 has not had an available update for several weeks. Is that supposed to be?

[qubesissues]

@andrewdavidwong I can confirm that dom0 has not had an available update for several weeks. Is that supposed to be?

[RefinedSoftwareLLC]

@qubesissues When I run cat /etc/qubes-release it get Qubes release 4.0 (R4.0), if yours still shows a Release Candidate (-rc), then you may need to manually update.

Accordingly, current users of 4.0-rc5 can upgrade in-place by downloading the latest updates from the stable repositories in both dom0 (https://www.qubes-os.org/doc/software-update-dom0/#how-to-update-software-in-dom0) and TemplateVMs (https://www.qubes-os.org/doc/software-update-vm/#installing-or-updating-software-in-the-templatevm).

[RefinedSoftwareLLC]

@qubesissues When I run cat /etc/qubes-release it get Qubes release 4.0 (R4.0), if yours still shows a Release Candidate (-rc), then you may need to manually update.

Accordingly, current users of 4.0-rc5 can upgrade in-place by downloading the latest updates from the stable repositories in both dom0 (https://www.qubes-os.org/doc/software-update-dom0/#how-to-update-software-in-dom0) and TemplateVMs (https://www.qubes-os.org/doc/software-update-vm/#installing-or-updating-software-in-the-templatevm).

[andrewdavidwong]

@qubesissues:

Are these smoothed out rough edges coming through with updates? Because my Qubes 4 was installed from the last Release Candidate and it still behaves terribly.

Well, I said that many of the rough edges have been smoothed out, but of course they may not be the ones causing what you consider to be terrible behavior.

I can confirm that dom0 has not had an available update for several weeks. Is that supposed to be?

I'd recommend asking about this on qubes-users, where you can provide some more details about your setup, which could help to figure out what might be going wrong.

[andrewdavidwong]

@qubesissues:

Are these smoothed out rough edges coming through with updates? Because my Qubes 4 was installed from the last Release Candidate and it still behaves terribly.

Well, I said that many of the rough edges have been smoothed out, but of course they may not be the ones causing what you consider to be terrible behavior.

I can confirm that dom0 has not had an available update for several weeks. Is that supposed to be?

I'd recommend asking about this on qubes-users, where you can provide some more details about your setup, which could help to figure out what might be going wrong.

[qubesissues]

@RefinedSoftwareLLC

$ cat /etc/qubes-release
Qubes release 4.0 (R4.0)

I have no reason to doubt this. But it was suspicious because (a) dom0 never updates and (b) I have all of the bugs on Qubes 4 that I have had since I installed rc4. So when (c) there was a suggestion that things are smooth enough for a new release I thought maybe the problem was with updating. But this cat command says otherwise.

[qubesissues]

@RefinedSoftwareLLC

$ cat /etc/qubes-release
Qubes release 4.0 (R4.0)

I have no reason to doubt this. But it was suspicious because (a) dom0 never updates and (b) I have all of the bugs on Qubes 4 that I have had since I installed rc4. So when (c) there was a suggestion that things are smooth enough for a new release I thought maybe the problem was with updating. But this cat command says otherwise.

[qubesissues]

@andrewdavidwong

I'd recommend asking about this on qubes-users

Good idea. Where is this? It is not another project here in GitHub.

[qubesissues]

@andrewdavidwong

I'd recommend asking about this on qubes-users

Good idea. Where is this? It is not another project here in GitHub.

[esote]

@qubesissues qubes-users is a mailing list. As far as dom0 updates go, the last one I had was on June 12th, where Xen (among other things) was updated to 4.8.3-8. You can check your update history by running sudo dnf history list in dom0, and as well to check your Xen version xl dmesg (version num is at the top of the output).

[esote]

@qubesissues qubes-users is a mailing list. As far as dom0 updates go, the last one I had was on June 12th, where Xen (among other things) was updated to 4.8.3-8. You can check your update history by running sudo dnf history list in dom0, and as well to check your Xen version xl dmesg (version num is at the top of the output).

[andrewdavidwong]

@qubesissues:

I'd recommend asking about this on qubes-users

Good idea. Where is this? It is not another project here in GitHub.

As @esote said, qubes-users is the mailing list for Qubes users to ask questions have discussions. See:

https://www.qubes-os.org/support/

And specifically this section:

https://www.qubes-os.org/support/#qubes-users

If you search for "qubes-users" on DDG or StartPage (and probably every other search engine), the web interface for the group is the first result, and the Support page linked above is the second result. (The web interface also links back to the Support page.)

https://duckduckgo.com/?q=qubes-users
https://www.startpage.com/do/dsearch?query=qubes-users

[andrewdavidwong]

@qubesissues:

I'd recommend asking about this on qubes-users

Good idea. Where is this? It is not another project here in GitHub.

As @esote said, qubes-users is the mailing list for Qubes users to ask questions have discussions. See:

https://www.qubes-os.org/support/

And specifically this section:

https://www.qubes-os.org/support/#qubes-users

If you search for "qubes-users" on DDG or StartPage (and probably every other search engine), the web interface for the group is the first result, and the Support page linked above is the second result. (The web interface also links back to the Support page.)

https://duckduckgo.com/?q=qubes-users
https://www.startpage.com/do/dsearch?query=qubes-users

[Aekez]

• I think this is a really good idea.

  • Although would it be feasible without taking a too big hit on resources and time? I wouldn't personally mind waiting that extra time for 4.1. if it means having a more stable release in-between though, for reasons listed below.

  • New hardware to be supported in kernel and firmware packages. For example Qubes 4 does not boot out-of-the-box on the new AMD Ryzen Mobile APU's, and needs controversial (and tricky) methods to install Qubes. A release between 4.0. and 4.1. with better hardware support for new hardware, would be very ideal for many (especially if there is a long time before 4.1. is ready).

  • Is it possible to give Qubes two kernels out-of-the-box for both the installer and dom0 itself? For example, one kernel for stability (which runs fine on older more supported hardware), and a newer kernel-latest for the new modern hardware?

  • Also if lack of space to fit the iso to a DVD size (like last time), then could it be feasible to remove some of the less important apps in Qubes, and instead pull them down via qubes-dom0-update? This way it could help preserve the DVD size limit without issues?

  • I'm not too sure about this one, but having more identical Qubes systems (after a lot of major updates), could potentially make it easier on the upcoming bug reporting and fixes?

  • I'm all in to support the idea for more people to have the opportunity to have the best experience with Qubes possible, especially for newcomers who are trying Qubes out for the first time. Newcomers may easily leave Qubes again if not enough is done to convince them to stay with Qubes, unlike long-term users whom can take more of a beating before the risk of giving up on Qubes). I definitely agree that a more refined Qubes 4 release with less issues, would go a far way to help the quality feeling of Qubes 4, especially if Qubes 4.1. is far off.

[Aekez]

• I think this is a really good idea.

  • Although would it be feasible without taking a too big hit on resources and time? I wouldn't personally mind waiting that extra time for 4.1. if it means having a more stable release in-between though, for reasons listed below.

  • New hardware to be supported in kernel and firmware packages. For example Qubes 4 does not boot out-of-the-box on the new AMD Ryzen Mobile APU's, and needs controversial (and tricky) methods to install Qubes. A release between 4.0. and 4.1. with better hardware support for new hardware, would be very ideal for many (especially if there is a long time before 4.1. is ready).

  • Is it possible to give Qubes two kernels out-of-the-box for both the installer and dom0 itself? For example, one kernel for stability (which runs fine on older more supported hardware), and a newer kernel-latest for the new modern hardware?

  • Also if lack of space to fit the iso to a DVD size (like last time), then could it be feasible to remove some of the less important apps in Qubes, and instead pull them down via qubes-dom0-update? This way it could help preserve the DVD size limit without issues?

  • I'm not too sure about this one, but having more identical Qubes systems (after a lot of major updates), could potentially make it easier on the upcoming bug reporting and fixes?

  • I'm all in to support the idea for more people to have the opportunity to have the best experience with Qubes possible, especially for newcomers who are trying Qubes out for the first time. Newcomers may easily leave Qubes again if not enough is done to convince them to stay with Qubes, unlike long-term users whom can take more of a beating before the risk of giving up on Qubes). I definitely agree that a more refined Qubes 4 release with less issues, would go a far way to help the quality feeling of Qubes 4, especially if Qubes 4.1. is far off.

[Aekez]

@qubesissues
If you're worried about missing out on dom0 updates, then you can draft a copy of all the dom0 current update packages from here https://yum.qubes-os.org/r4.0/current/dom0/fc25/rpm/ and then compare it with all the packages currently installed in your dom0.

Different ways this can be done, I recon that it shouldn't be too tricky with the proper commands to find all packages ("rpm -qa packagename" for example) and compare the two lists. But how to do this isn't for this issue thread.

Though if you do find missing dom0 updates, then maybe it would be good to create a new issue for that. But it's probably just updates staying longer in current-testing before ready, or focus that shifted to work on 4.1., rather than you're missing out on dom0 updates (but who knows, it's always a good idea to check anyway, imho).

[Aekez]

@qubesissues
If you're worried about missing out on dom0 updates, then you can draft a copy of all the dom0 current update packages from here https://yum.qubes-os.org/r4.0/current/dom0/fc25/rpm/ and then compare it with all the packages currently installed in your dom0.

Different ways this can be done, I recon that it shouldn't be too tricky with the proper commands to find all packages ("rpm -qa packagename" for example) and compare the two lists. But how to do this isn't for this issue thread.

Though if you do find missing dom0 updates, then maybe it would be good to create a new issue for that. But it's probably just updates staying longer in current-testing before ready, or focus that shifted to work on 4.1., rather than you're missing out on dom0 updates (but who knows, it's always a good idea to check anyway, imho).

[marmarek]

Generally I'm for having 4.0.1 and 3.2.1, but I'd like at least fix keyboard layout issue for that, preventing openqa tests to succeed (https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.0&build=4.0-20180610&groupid=1). It is this bug: #3352
To solve this, we need to find what exactly change the keyboard layout back to us. The only idea I have how to do that is installing the system and watching the process carefully (including exact time when layout is changed), then inspect all possible logs carefully to find what was running at that time. It may be some package's installation script (use rpm -q --scripts <package> to get it).
I'd really appreciate help with this. You can either grab final 4.0 iso, or image linked on the tests above (a build from 2 weeks ago). Both have exactly the same problem.

[marmarek]

Generally I'm for having 4.0.1 and 3.2.1, but I'd like at least fix keyboard layout issue for that, preventing openqa tests to succeed (https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.0&build=4.0-20180610&groupid=1). It is this bug: #3352
To solve this, we need to find what exactly change the keyboard layout back to us. The only idea I have how to do that is installing the system and watching the process carefully (including exact time when layout is changed), then inspect all possible logs carefully to find what was running at that time. It may be some package's installation script (use rpm -q --scripts <package> to get it).
I'd really appreciate help with this. You can either grab final 4.0 iso, or image linked on the tests above (a build from 2 weeks ago). Both have exactly the same problem.

[Aekez]

@marmarek
Regarding language randomly switching, I think I might have found three clues (at least I can cause it to reproduce the switch back to us keyboard language roughly 50% of the time with one of them, the first clue below). Also all 3 clues seems related to each others, and seem to happen in some other Linux distros' as well.

• First clue seems that it is tied to xorg and keyboard being disconnected / connected. I found the Xorg log at /var/log/Xorg.0.log indeed includes the keyboard language changes as said in comment nr. 82 in the link below . See the comment nr. 82 here https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1246272. This comment also gave me the idea to check it on my own Qubes laptop. Sure enough, correcting the wrong resolution (xorg resolution bug) and changing it back to a proper resolution on my HDMI screen (connected with USB-C port), causes my laptops USB keyboard to change language. However the odd part is that the laptops keyboard stays the same, so there are effectively two keyboard languages at the same time, one for each keyboard. Running setxkbmap then gets both laptop and external USB keyboard back to the same language. Only tested in dom0. There is a second bug here, which causes the resolution to not fit in 1920x1080 pixels, where I need to change down to 1680x1050 resolution (not all temporary resolutions work), and then back to 1920x1080 again, in order to get the proper 1920x1080 resolutions. This is where I can cause the USB keyboard to change language, which happens when I fix the resolution bug caused by removing and re-inserting the USB-C dongle that holds both the USB keyboard and the HDMI TV screen. Interestingly, the USB keyboard only reverts back to US keyboard language once I correct the resolution bug, and not before that.

  • I don't get resolution bugs if I use HDMI directly in the HDMI port, rather than the USB-C port, however, I have not yet tested if it makes a difference. I'm not sure if the keyboard bug is tied to USB-C or the resolution bug itself, but it seems Xorg related at least?

• The second clue is that different language settings seems to cause conflicts when different apps are running. This is also speculated in the comment nr. 69 in the same link up above.This also seems tied to the third clue, or maybe even the first clue as well.

• The third clue seems to be that it goes bad after switching system languages for the first time post-system-install (causing mixed language settings). Generally I can relate to this too, but I haven't checked it enough times to see if its true. But I get the feeling that staying with whatever language that was picked during the Qubes installer, will keep working normal after installing. But the moment one changes language settings after the system has been installed, it seems like it causes the keyboard bugs. Maybe there are lingering keyboard language settings that causes a reset back to US?

This isn't anything concrete, but I hope it can be useful.

[Aekez]

@marmarek
Regarding language randomly switching, I think I might have found three clues (at least I can cause it to reproduce the switch back to us keyboard language roughly 50% of the time with one of them, the first clue below). Also all 3 clues seems related to each others, and seem to happen in some other Linux distros' as well.

• First clue seems that it is tied to xorg and keyboard being disconnected / connected. I found the Xorg log at /var/log/Xorg.0.log indeed includes the keyboard language changes as said in comment nr. 82 in the link below . See the comment nr. 82 here https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1246272. This comment also gave me the idea to check it on my own Qubes laptop. Sure enough, correcting the wrong resolution (xorg resolution bug) and changing it back to a proper resolution on my HDMI screen (connected with USB-C port), causes my laptops USB keyboard to change language. However the odd part is that the laptops keyboard stays the same, so there are effectively two keyboard languages at the same time, one for each keyboard. Running setxkbmap then gets both laptop and external USB keyboard back to the same language. Only tested in dom0. There is a second bug here, which causes the resolution to not fit in 1920x1080 pixels, where I need to change down to 1680x1050 resolution (not all temporary resolutions work), and then back to 1920x1080 again, in order to get the proper 1920x1080 resolutions. This is where I can cause the USB keyboard to change language, which happens when I fix the resolution bug caused by removing and re-inserting the USB-C dongle that holds both the USB keyboard and the HDMI TV screen. Interestingly, the USB keyboard only reverts back to US keyboard language once I correct the resolution bug, and not before that.

  • I don't get resolution bugs if I use HDMI directly in the HDMI port, rather than the USB-C port, however, I have not yet tested if it makes a difference. I'm not sure if the keyboard bug is tied to USB-C or the resolution bug itself, but it seems Xorg related at least?

• The second clue is that different language settings seems to cause conflicts when different apps are running. This is also speculated in the comment nr. 69 in the same link up above.This also seems tied to the third clue, or maybe even the first clue as well.

• The third clue seems to be that it goes bad after switching system languages for the first time post-system-install (causing mixed language settings). Generally I can relate to this too, but I haven't checked it enough times to see if its true. But I get the feeling that staying with whatever language that was picked during the Qubes installer, will keep working normal after installing. But the moment one changes language settings after the system has been installed, it seems like it causes the keyboard bugs. Maybe there are lingering keyboard language settings that causes a reset back to US?

This isn't anything concrete, but I hope it can be useful.

[marmarek]

Yes, I think it's useful, thank you!
The idea that something called by udev is responsible helps a lot. I'd guess that during the installation, there are multiple places where udev trigger is called, which also will cause re-issue of udev events (and Xorg picking them up). There is still a question where exactly old keyboard layout persists in Qubes case, but it should be easier to find now. Comment 77 and 80 there contains a list of things to look into.

[marmarek]

Yes, I think it's useful, thank you!
The idea that something called by udev is responsible helps a lot. I'd guess that during the installation, there are multiple places where udev trigger is called, which also will cause re-issue of udev events (and Xorg picking them up). There is still a question where exactly old keyboard layout persists in Qubes case, but it should be easier to find now. Comment 77 and 80 there contains a list of things to look into.