I just completed a bluetooth transfer of a photograph from my Pixel to the Librem 13 v3.

I did an apt update and installed a new deb -- firmware-atheros -- and that helped the situation. I have Debian repos enabled, not sure if firmware-atheros is in PureOS repos.

I can confirm this, seeing similar issue.

[   18.375949] usb 1-3: firmware: failed to load ar3k/AthrBT_0x11020100.dfu (-2)
[   18.375954] usb 1-3: Direct firmware load for ar3k/AthrBT_0x11020100.dfu failed with error -2
[   18.375956] Bluetooth: Loading patch file failed
[   18.375964] ath3k: probe of 1-3:1.0 failed with error -2

Done. This was satisfying, not having to deal with the build of this beast it great!

Thank you.

Yes, that would be my advice. You can do a dist-upgrade anyway and try and fix your system if it gets in a misconfigured state, but that can be time consuming and difficult. Usually with ten days or so that type of package conflict goes away as new software and bug fixes come into the repos.

So, there is a kernel panic because the kernel can't seem to find a file system to mount. How did you install GNOME? Did you use a USB stick or an ISO or similar? Or are you using apt-get or some other means?

The Librem's have a version that I think represents the physical device on the back, one of my Librems says "Librem 13, version 3." If you want to find the software version, or version of the overall OS, try this command (you may have to install inxi);

$ inxi -Fxrz

Which on my system produces;

System:    Host: sigmund Kernel: 4.18.0-2-amd64 x86_64 bits: 64 compiler: gcc v: 7.3.0 Console: tty 1 Distro: PureOS 
           base: Debian buster/sid 
Machine:   Type: Laptop System: Purism product: Librem 13 v3 v: 3.0 serial: <filter> 
           Mobo: Purism model: Librem 13 v3 v: 3.0 serial: <filter> BIOS: coreboot v: 4.7-Purism-4 date: 03/20/2018 
Repos:     Active apt repos in: /etc/apt/sources.list 
           1: deb https://repo.puri.sm/pureos green main
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://deb.debian.org/debian stretch main contrib non-free
           2: deb-src http://deb.debian.org/debian stretch main contrib non-free
           3: deb http://deb.debian.org/debian stretch-updates main contrib non-free
           4: deb-src http://deb.debian.org/debian stretch-updates main contrib non-free
           5: deb http://security.debian.org/ stretch/updates main contrib non-free
           6: deb-src http://security.debian.org/ stretch/updates main contrib non-free

You can see from output above that I'm running a 4.18 kernel. My distro is PureOS based on Debian Buster / Sid (so testing) and that my repos are PureOS 'green' mixed with Debian stretch. In the "Machine:" line I note that coreboot version is 4.78-Purism-4 from 03/20/2018. PureOS "green" may be a rolling release which means that the userland packages (and kernel potentially) are updated continually.

I believe @kyle.rankin mentioned systems were shipping with the June release due to issues, but this was a month ago. How can I check the version shipped on my unit?

I think the problem in general is that python3 was upgraded to 3.7 and several packages are dependent on python3 being less than 3.7. (Note the "Depends" line above. hplip also shows python3<<3.7 if one runs apt show on it.) I have the same problem with apparmor-utils and opened a new task, not having previously looked at this one. I noticed hplip--I don't use it to my knowledge--was also uninstalled for me on 12/20. This was the same update with python3 going to 3.7. Unfortunately, I am dependent on a Purism-modified package for python3-libapparmor. (The one in buster shows python3 << 3.8 as the dependency.)

Same problem? https://tracker.pureos.net/T657

Seems that website doesUser-Aagent sniffing.

I think that the version of PureBrowser you showed there is quite old. I wonder if we need to discuss with the distributor about updating the software on the devices? I propose we bring this to a Production / QC meeting.

Is this a duplicate of https://tracker.pureos.net/T595?

Confirm. Since PureBorwser identifies itself as PureBrowser, instead of Firefox, the addons site thinks you are not using Firefox and won't let you install extensions.

Firefox developer version (redish color) vs PureBrowser (greenish), side by side, loading the same page on PureOS

Is there any chance we'd have the UEFI support in PureOS 8.0 Release?

I'm going to go ahead and wontfix this as most of the changes are not appropriate to Debian and should be handled another way anyway, not via a "config package".

Link dump:

@kyle.rankin Okaley, so what's the next step here? This should have hit PureOS by now :)

Pinged upstream bug: https://gitlab.com/lamby/osinfo-db/merge_requests/1#note_127118132

Pinged Debian bug...

Okay, thx. I tried it because I did not want retainet packages. Then should I wait theses packages can be upgraded without theses conflicts?

Yeah, unfortunately the Librems are very often shipped with old software, Polywell didn't stay up-to-date with new releases. But issues like we had recently with the OEM setup of course also don't help with these issues.

This is not so surprising for a 'dist-upgrade'. I don't know if you want to do the dist-upgrade or not, perhaps you need those important packages and don't want them removed, but if you like you can try just doing a regular apt upgrade that will not be as invasive.

Cool. I have another Librem that was sent to me for testing, I'm going to look for this too on that one. I worry that some of the machines may be shipping with older software.

Hmm yeah, then the PureOS version installed on that machine is likely very old.
In any case, after you update your system the issue will go away completely.

This appeared on a laptop that was shipped to me this week. I'll check the vintage of the software.

This is a task on my list, but it will take a lot of work and time to resolve properly. Dak isn't really designed for this, so some changes will be needed (just a normal dinstall run currently takes more than an hour alone).

I think this is an ancient bug - did you try a very old installation image of PureOS?

apt dist-upgrade

This weather is far more of for smokey bourbon...

ACCEPTED in Debian.

Can you share the command you used? Also, what is in your /etc/apt/sources.list (or /etc/apt/sources.list.d/* ?

Now just lean back and drink gin&tonic for a few weeks while Debian and Laniakea processes it to PureOS green :-D

Accepted in Debian. (Grr at your insistence of License-Grant! j/k)

Package is libhostfile-manager-perl tracked in Debian as bug#916437.

@chris.lamb: Please have a look at the Debian package now in NEW queue, and approve if acceptable.

In T595#12043, @sean.obrien wrote:

the recommendation was unofficial and I'd rather not push on it...

why enabling the compatibility mode, as it seems like we do for PureBrowser by default, doesn't fix the problem is a mystery to me.

@jonas.smedegaard the recommendation was unofficial and I'd rather not push on it... could end up with policy that isn't in our interest. Waterfox uses the same style of UA string, and they have compatibility with the addons store.

Seems directly tied to Laniakea: Assigning to @mak

@sean.obrien Is the conversation with Mozilla, leading to their suggesting that particular string, public? If so, please provide URL.

@mladen.pejakovic My point is that "Compatibility mode" is something specific in the context of Firefox.

Confusingly that page talks about "compatibility mode" which is *not* what it is about: Compatibility mode is already enabled.

A known workaround is to configure PureBrowser to impersonate Firefox: https://tracker.pureos.net/w/troubleshooting/firefox_compat_mode/

Is there a workaround until an update is sent out?

@kyle.rankin Do you recall more detailed how/where the Tails website broke? Is it still the case?

I can't reproduce this.

What is the error message you're getting from update-initramfs?

For reference, this is the JS library that the Mozilla addons team uses to figure out the UA: https://github.com/faisalman/ua-parser-js/

@jonas.smedegaard clarification - I visited addons.mozilla.org in a new browser tab after making that UA change, and was able to install addons that would fail with the previous UA string. I assume the UA override in about:config does *not* fix the problem for the browser as a whole, which is why browsing through the "addons manager" still barks at you for not running a compatible browser.