Omar, can you do a

sudo dmesg -w

then plug in a USB cable connected to a device known to work and put any error messages here?

How can something be "too stable" or "too unstable"? Isn't it kind of like saying you're too pregnant? Either your pregnant, or you're not.

updated, rebooted, and still no GUI. Confirmed that the changes are still in the file.

Below is text from my /etc/default/grub -- both lines are commented out. I will try uncommenting, updating grub and rebooting, then report.

Also, this will need to be uncommented;

Can you paste a copy of /etc/default/grub here?

Great that it works now.

I ran sudo aptitude install openttd and it installed and I was able to run the game. Just to be sure, I removed both openttd and aptitude and reinstalled just openttd using apt and that worked too. I can't pinpoint what has changed but it's working now.

Please try install using aptitude - in case that reveal more/different details: sudo apt install aptitude and then sudo aptitude install openttd

When I run apt-mark showhold, nothing is returned from that command.

I think that you can clear this up by doing;

The error message hints that held packages may be the cause.

I had no problem a month ago.

Seems this was reported upstream more than a year ago: https://bugs.debian.org/884372

This has been a problem since late last year. You may want to follow this tracking item.

This is very helpful @mak, thanks. I'll read up.

The problem is solved. It was a conflict with my virtual machines that was using the wifi network.

Looks like I somehow always ignored those issues when processing bugs, sorry for that!

I can do it, unless you are faster with it - it's a really trivial upload anyway :-)

In other words: Feel free to reassign to me for now if you prefer

Ah, sorry - I was wondering why I had "missed" to file this issue sooner, and your remark now hints that there was a good reason.

Can you check if this is still an issue? There have been lots of changes on the locale handling in the PureOS initial setup and installer.

No problem with processing delay: Had it been urgent then I would have shouted louder :-)

FTR, this goes together with https://github.com/systemd/systemd/pull/9864 where I am still waiting on feedback.
The current situation with localed on Debian is really suboptimal.

FTR, the reason for blocking nvidia-settings was "References non-free NVIDIA driver".
Package is removed from blacklist now.

Yikes, looks like this issue fell through the cracks completely, sorry for that.

2019-03-24 07:27:13 - INFO: Imported 'mate-sensors-applet_1.20.3-1.dsc' to 'landing/main'.
2019-03-24 07:28:21 - INFO: Imported 'mate-sensors-applet-common_1.20.3-1_all.deb' to 'landing/main'.
2019-03-24 07:28:22 - INFO: Imported 'mate-sensors-applet_1.20.3-1_amd64.deb libmate-sensors-applet-plugin-dev_1.20.3-1_amd64.deb mate-sensors-applet-common_1.20.3-1_all.deb mate-sensors-applet-nvidia_1.20.3-1_amd64.deb libmate-sensors-applet-plugin0_1.20.3-1_amd64.deb' to 'landing/main'.
2019-03-24 07:28:24 - INFO: Imported 'libmate-sensors-applet-plugin-dev_1.20.3-1_arm64.deb mate-sensors-applet-common_1.20.3-1_all.deb libmate-sensors-applet-plugin0_1.20.3-1_arm64.deb mate-sensors-applet_1.20.3-1_arm64.deb' to 'landing/main'.

@jeremiah.foster The data on this URL lists which packages are in certain seeds and why. Some might be explicitly requested, while others are implicitly added via dependencies of packages that were not explicitly requested to be in the default set.
A "standard" PureOS installation consists of the "minimal", "standard" and a desktop seed (e.g. "gnome"), while the desktop seed is itself comprised of a common platform seed ("desktop-common") combined with a desktop specific one ("gnome" or "plasma").
So, if you want to know what is explicitly added to the GNOME flavor of PureOS, https://master.pureos.net/raw/germinate/pureos.green/gnome.seedtext could be interesting, while tables like https://master.pureos.net/raw/germinate/pureos.green/gnome also contain implicitly added stuff and sizes.

Needs a fake upload as the PureOS version is higher than the one in Debian.

If you have not already, you may want to look at /etc/resolv.conf and see if any nameservers are there. Many moons ago, though not on Linux, I had a vpn that would create new dns data. When it crashed, I could not get out of my local system because the it was trying to use the vpn-created entries and had no clue. I had to undo the changes before things would work again.

Wanted to bump this and check on it, thank you.

On tilix I do the command ifconfig and I see my wifi antenna that is well connected to my network.
I made a "ping puri.sm" but impossible to resolve the domain

Pinged Debian bug…

@mak you wrote this in a related discussion (in a non-public chat where you gave permission to quote in public):

Laniakea can sync a specific list of packages from any suite into landing, however this is definitely not a smart idea on PureOS as it currently is. We did that mistake on Tanglu in the past. Since PureOS doesn't rebuild all packages synced from Debian, there might be subtle incompatibilities, or synced packages would just flat out not work due to dependency issues. Or the synced experimental packages would break other stuff if not rebuilt against them, GLib is a primary candidate here (but we also had DBus interface incompatibilities occasionally).
So, if we sync stuff from random suites, I would also opt for rebuilding all Debian packages for PureOS, which in turn would require us to do transitions like Debian does (which would mean people would have to monitor and do those).

4.1.0+dfsg.1-1 is now in PureOS so the issue is gone.

I was commenting on a PureOS forum topic, and I discovered the same error when using Software->left application icon->Software Repositories. My system log file displayed the above stack.

Scope of this issue now relaxed to include source-identical but rebuilt packages.

Whoops, sorry: I totally misread this issue: Clearly not that PureOS is too unstable.

I generally find that it is easier to handle issues when framed by describing the "issue" (i.e. the thing broken or missing) as the topic - rather than an open-ended question.

Comments that were removed can be discussed in a separate issue: https://tracker.pureos.net/T722

Installed on L15 V3.

Earlier systems implemented it as a screw or switch on the mainboard. The current solution is an onboard controller (CR50, IIRC) dedicated to debugging and owner control

"cat: /etc/default/grub.cfg: No such file or directory"

Btw, gksu will not work at all on Wayland as wayland does not allow GUI apps to be run as root without some reconfiguration (which intentionally isn't done), and on Xorg I guess it's just broken because nobody looks at its code anymore.
So, I think we should just close this bug.

@jonas.smedegaard Apparently gksu wasn't auto-removed from PureOS because sbackup had a dependency on it. That package itself is cruft though, so I just dropped both from the archive.
Interestingly, sbackup was not considered for autoremoval in PureOS, I will have to take a closer look at why that happened later (my guess is that it has something to do with the package being NMU'ed and building only arch:all binary packages).

Why do PureOS distribute gksu at all? It was dropped from Debian a year ago: https://tracker.debian.org/pkg/gksu

What does

1. grub.cfg #
2. DO NOT EDIT THIS FILE #
3. It is automatically generated by grub-mkconfig using templates
4. from /etc/grub.d and settings from /etc/default/grub

#

Since you insist, @jeremiah.foster, on expanding/redefining the scope of this issue to be about switching *GENERALLY*, I cannot help and therefore unsubscribe from participation here:

Can you paste a copy of you grub.cfg file? Either here or in a pastebin somewhere? That might help debugging the issue. You grub.cfg file likely won't have any secret info, just things like the command line to boot your system as well as the UUID of your disks.

From the phone perspective we we'd like to pull a rather fixed set of packages from e.g. Debian experimental during the freeze automatically (assuming Debian's GNOME team ends up putting the packages there) but after all it's more of an example of a general pattern: grab packages a, b, c from repository x (ideally including required dependencies not present in the target distribution).

It's not, I installed the module and the same happens.

Nope. Installing libcanberra-gtk-module and libcanberra-gtk0 doesn't help.

I can reproduce this. I also get a message "Gtk-Message: 09:43:04.539: Failed to load module 'canberra-gtk-module'" when I run this so perhaps the error is there.