That is quite likely part of "Activity Stream" which has been removed in PureBrowser, compared to Firefox ESR: See T534

From a user experience POV it would be better to not be bothered like this.

• 79.125.105.113 is duckduckgo. I am not sure why this would load on /boot/
• Please re-ask the user to get the contents of these requests (ie. the port 80 ones as they won't be encrypted.

More info:

I set the keyboard layout to "English (US, alt. intl.)" in the GNOME "Region & Language" settings panel but it didn't help

Sure thing; resolving.

After upgrading my system with apt on the command line, I had this warning (don't know if it is related) :

To me this ticket should be closed, as we have achieved the initial goal (packaging the equivalent of gpg-encrypted-root into PureOS).

Pinged Debian bug...

Merged upstream, we'll just have to wait for a release but there is no "next step" for now, so marking as "resolved".

Going to unassign myself for the time being. :)

gnucash is now back in Buster and thus PureOS; closing :)

and am working on packaging it for PureOS.

I'm going to unassign myself here; concentrating on Reproducible Builds. :)

I understand. My only comment is that Ubuntu's boot process is less free and overall protects your privacy a bit less, but I understand there is a trade-off between privacy and convenience that we all have to make personally.

Thanks @jeremiah.foster . I had not configured Exim to run, so I've followed your instructions here to disable it. But back on topic, I think my boot time already was fast, before I upgraded my kernel and ran into this issue where it just hangs forever while trying to boot. Disabling Exim definitely didn't fix that.

Indeed, this appears to have nothing to do with Firefox (?).

So using Qemu on Ubuntu didn't give the flashing ordeal like in VirtualBox, but it would seem that there are other issues such as keys stick and performance is atrocious.

I have not put an issue to Ubuntu just yet.

What we do different with Firefox is _remove_ some functionality that Mozilla ships by default and then also force-include some WebExtensions which Debian ship as well but do offer for their users to freely decide if they want part of their Firefox experience.

One difference between us and Debian is that we modify Firefox with various privacy tools and add-ons. @jonas.smedegaard would you be able to determine if the patches we add might be the source of the web calls out? Perhaps there is a black list being downloaded at first run or similar.

I cannot rule out that it is a virus or a hacking attempt. But then again, I cannot rule out either that I am right now part of a secret government LSD experiment and hallucinating my computer screen - I just cannot make much use of such speculation.

Thanks for those new details.

Maybe they could run opensnitch to see if we can get more detail about the processes opening the ports? It looks like the web browser is doing this since they're 443 or port 80

• downloaded from pureos.net/download
• sha sum matched
• burned from win 7 operating system burning tool
• user is from Slovenia
• no VPN is used
• dns is encrypted by RATtrap firewall

Awesome! Thanks @soapergem! Have you configured Exim (a mail transfer agent) to run on your laptop? If not my recommendation would be to disable it. You can disable it, which just stops it from starting up, this way;

I am closing this issue. It appears to be fixed today. Thanks.

It was a wild guess at what might cause the issue at the _host_ side which is not PureOS.

@jeremiah.foster It does not make sense to me why/how this bug is closed.

For the record (as I understand time's up for your concrete case), use of Logical Volume Management (LVM) can provide a user experience of a single "virtual" partition, stitched together from multiple underlying physical "volume" partitions.

Thanks for the info, @jonas.smedegaard

I was using the NVIDIA graphics driver. I switched the profile to an Intel based driver with X.Org X server drivers and still the same results. Can you let me know what video drivers PureOS supports?

well, in my splitting-hairs mode it is factually alarming: It set off an alarm, of the cenventional blinkenlight type.

I believe it is only the install routines for PureOS that has problems with EFI, the installed PureOS works fine with EFI.

Hi Jeremiah, I understand the difficulty, and would love to provide as much detail as I can. I've attached the output of that command, though (spoiler alert) I don't think it's terribly helpful:

Regarding swap, yes you can run without swap. It can be nice to have however if you don't have a lot of memory.
Regarding cryptsetup, that is a warning and not an error, this shouldn't be preventing your boot

After recently upgrading my kernel I had a very similar issue. You basically roll the dice to see if the new kernel will actually boot. Sometimes it will. More often it won't; it will just hang forever with a message much like this one:

no that does not seem alarming in itself

@jeremiah.foster I recommend to put as issue subject the issue (not its solution), and not rename to its solution when closed either: Example: References will then sensibly show the _problem_ as striked out, not confusingly that the solution is striked out.

You were told that this is a pristine live image, or you are guessing?

@jonas.smedegaard Yes, user starts PureOS live from a CD (they do not have disks in their computer), and this happens during bootup, before they even start desktop. (IIUC)

Yes, PureOS is a general purpose operating system, it is possible to install things on it that attempts to contact a certain IP number every time it boots.

What evidence is there that the password was "destroyed"? Is it possible that something else happened? I say this because the GNOME disks dialog is stating that there was an error changing the passphrase, it doesn't say that the password was changed or destroyed.

This affects Ubuntu as well, leading me to believe the issue is upstream in GNOME disks; https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1790979

Here are the warnings from cryptsetup's FAQ. We need to determine which one is relevant to GNOME Disks before advising users to use GNOME disks.

It looks like using GNOME disks may change the LUKS header file when it does a wipefs. I would warn users about this and instead refer folks to this resource: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#2-setup

@jeremiah.foster as per @chris.lamb advice, I want to raise a concern about this, we either need to fix it now, or to somehow warn users about this issue.

This FAQ may help: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions

Seems to me that problems running PureOS in an emulator is an issue with that emulator.
I can suggest that you try raise this as an issue in Ubuntu.
A wild guess could be that you use some non-free graphics driver (e.g. for NVIDIA hardware) which might work great for some things but have issues with other things.

This was reported in Debian recently: http://bugs.debian.org/921030

(hm, not really resolved, but seems that's the option we got in this interface)

Thanks for trying, @jgn2112

@jeremiah.foster Better to merge new issue into older - especially when the older is referenced from other places as is the case here.

Let's close this one out guys. I wasn't able to get it working and gave up as I dont have the time.
I appreciate all the help.
Incidentally, I sold the computer to a guy who was handy with linux scripts and he said a "short" script would solve this. But again, its beyond my scope and time constraints.
PureOS seemed like a really slick OS too.
Maybe someday.

I asked him show lshw again to see if hardware is detected, correct driver used and capabilities detection. He said WiFi does not work now he upgraded. On the version before, it only failed to connect.

This is likely a duplicate of https://tracker.pureos.net/T202

Just to elaborate on that: The pureos-*installer executables are either compatibility scripts or helper scripts that change installer configuration to the OEM settings. All of them eventually will launch Calamares.

Where are we on this? Have things connected or are there still issues that I can help with?

Honestly I don't know where this bug or issue might be. On my Librem13 v3 with a 34" external screen and at 100% scaling both displays "just work". Can you share a screenshot of your "display mode" in the control center?