Adding the full syslog error containing all of the call traces{F44013}
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 21 2018
Show. The installation Worked =) thanks.
Feb 20 2018
@tharvill That was the case. Did:
I had a similar experience. I believe (not sure) that PureBrowser switched it's app dir from ~/.purism/firefox to ~/.purism/purebrowser. When I fiddled with profiles.ini in the two I could get back my add-ons, etc.
It looks like the bug is in debian too: https://bugs.debian.org/889990
Possibly related: I had a couple of Firefox extensions installed prior to upgrade that I can no longer install via addons.mozilla.org - I was previously able to, but now I get an error saying I need to install Firefox in order to install.
virsh cpu-compare domain.xml
Feb 19 2018
In GNOME Tweaks, change "Mouse Click Emulation" back to "Area".
Feb 18 2018
In T267#5207, @chris.lamb wrote:Can you confirm this is being run with *no* ~/.config/chromium ? (eg. moved out of the way prior to running?) I cannot reproduce this, alas.
Ideally, Software would automagically open and install third party .debs and no one would have to even worry about gdebi or Archive Manager wanting to install the app.
Sure, but not with gdebi!
Feb 17 2018
That is not a job of PureOS and this is PureOS tracker. Also PureOS is only 64bit and last time I checked, steam was still usually 32bit built so you would need plethora of 32bit libs.
I'm not suggesting that Steam be included in PureOS. These are packages needed to run the Steam client. Are they non-free? If a customer chooses to install and run Steam, they should be able to.
You surely want a way to open compressed zip/tar.gz/tar.xz etc. archives in the default install.
Feb 16 2018
Steam client is nonfree software so it will never be part of PureOS.
Either povray 1:3.7.0.4-2pureos1 went through NEW when I uploaded it on November 27 - three days _before_ your changes, or in went through NEW caused by your interventions.
The package went through NEW after I synchronized it with Debian, which leads to this situation now:
INFO: Can not sync povray: Target version '1:3.7.0.4-2pureos1' is newer/equal than source version '1:3.7.0.4-2'.
So, we can only properly sync this with Debian when the Debian version is newer (the archive will not allow downgrades).
Done
Reopening but lowering to low priority: Package is currently fixed but likely to be dropped (see T330) and may then reappear and if so need fix reapplied.
If this is happening on Librem 13v2 laptop, please see this: https://tracker.pureos.net/T328
tested with windows on corebeoot. No issues. Only when we install and test pureos that have this issue.
I have to add, that this is a clean install. (WIth AMI bios)
Feb 15 2018
CPU described in domain.xml is incompatible with host CPU
Feb 14 2018
Any chance somebody could run the above
(w/no patches.)
Will do! Thanks!
OK, it may be from an older install or something has gone wrong on my side for some reason...
My system after the most recent updates is running the following versions:
/etc/resolv.conf is not created correctly on a clean install of PureOS
What version of libvirt, qemu and gnome-boxes is pureos currently shipping? Any patches on top of Debian proper?
Yes because it is supposed to be automatically updated.
Okay but doesn't the resolv.conf have a big warning in it saying "do not edit this file"? :p
Ah, I was a little behind on updates. When I upgrade to the latest versions of packages (on my Librem 13v2) it fails to start. :)
For some reason, on my PureOS install, /etc/resolv.conf was not a symbolic link to /etc/resolvconf/run/resolv.conf and was never updated.
@kyle.rankin the setcap is only for a follow up problem. It won't help with the CPU type conflict.
Feb 13 2018
I can't reproduce this:
Hm, I can't reproduce this: https://i.imgur.com/as3SNtc.jpg
Hm, I can't reproduce this: https://i.imgur.com/as3SNtc.jpg
I tried the setcap command but still got the same error on PureOS.
Oh, installation on Debian buster works with e.g.:
@chris.lamb that's the same issue. Could someone having this problem please run
@chris.lamb yes, I think that's the same issue. I hope to get around to look at it again later this week.
Is this related to T292 ?
Feb 12 2018
You may ignore this bug as it seemed to be related to a network issue on my side (maybe my provider). It is now working.
Feb 11 2018
Which version of Gnucash are you trying to build? libgoffice-0.8 is removed from Debian testing (which PureOS is based on), but there is a newer version of Gnucash (2.7.3) in the Debian Experimental repositories, which require libgoffice-0.10.
@tharvill Underlining this is not a (recent!) regression is helpful, thank you. I am fairly certain it's a somewhat structural problem with the Debian Installer generally which will require some work in Debian itself.
I'd like to weigh in and let you know the same thing happened to me in my new Librem 15 purchase of a month ago. I keyboarded my way through the setup and then the trackpad worked after final boot into the windowing environment.
I meant this URL as reference to goffice-0.8 on Debian 10
Feb 9 2018
Thanks a lot. Also for checking the 52.6 release!
The issue appears to be resolved. Switched to include both 'landing' and 'green,' fully updated and on PureBrowser 52.6.
Feb 8 2018
Still looking for an upstream bug reference. https://bugs.archlinux.org/task/55785 suggests that it may be fixed upstream, in which case we need to get the fix into Debian Testing and then PureOS.
Feb 7 2018
Please mention the version of PureBrowser that you do not experience the issue.
<avph> KaKaRoTo: does purism have any plans on using vboot btw?
<KaKaRoTo> avph, I'm not familiar with it, so I never looked into it. I was asked that same question last week and I opened this task for it : https://tracker.pureos.net/T315
<KaKaRoTo> it's mostly about "what is it? what is it for? do we need it? can we enable it ? etc..."
<KaKaRoTo> avph, so if you're familiar with vboot and want to give us some pointers on that, I'd appreciate it
<nico_h> mostly for a secure update mechanism
<nico_h> so not every malware can write to the flash chip
<avph> well it won't run the malware mostly :)
<nico_h> um, scratch the latter
<KaKaRoTo> nico_h, how does it achieve it? needs a portion of the flash to be read-only, no ? does it use an IFD region for that ?
<KaKaRoTo> does it require a TPM or is it a way to get verified boot without TPM ?
<nico_h> Google uses the write-protection feature and /WP pin of the flash chips
<nico_h> I'm not sure if it requires a TPM (I think only for downgrade protections or something)
<avph> KaKaRoTo: no read only is (or can be) achieved with southbridge registers. TPM is to prevent updates rollback but the secure boot and safe updates are still there
<KaKaRoTo> /WP pin of the flash chip with protect the entire chip, not just a portion of it
<nico_h> no, /WP pin to protected part of the flash chip
<nico_h> usually, /WP only protects the block protection setup of the chip not the whole chip
<nico_h> but... that depends on the chip
<nico_h> KaKaRoTo: the general idea is: 1. have one part RO during runtime (can be achieved with early programming of PCH registers, as avph pointed out). 2. the RO part only runs other (updated) parts if a signature verification worked out
<KaKaRoTo> ok
<KaKaRoTo> I assume the early programming of PCH registers is done by vboot itself already
<avph> not sure but certainly saw stuff like that
<KaKaRoTo> I have this in my TO-READ list, so I'll explore that more later : https://www.coreboot.org/git-docs/Intel/vboot.html
<nico_h> unlikely, as it's mostly only used on chromebooks with the /WP thing
Also experiencing this issue - can't start any VM from a known good ISO. Running PureOS OEM image, gnome-boxes is 3.26.2 - issue persists across multiple DEs and reboots.
Feb 6 2018
I'm no longer seeing this issue and could probably be closed.
More debug info:
I added more logging and tried again. here are the (sanitized) results:
I've uploaded virsh capabilities output as well
When you attempt to start a pureos live cd image in Boxes, you will get the following error in the terminal:
Hi,
can you please do a
I'm not seeing this anymore so task could be closed.
Feb 5 2018
You won't taint it because this task/project is about writing a bash script, there's no proprietary bits in the bash script itself. Unless it's about the FSF requirement and the fact that the script itself will manipulate a binary file? Somehow I'm not sure that's a valid reason, considering that the librem-coreboot-updater script is already in PureOS and this task is about porting that script to the fwupd system
Either way, whether it's tagged PureOS or not, a PureOS developer is still probably the best person for the task here.
After discussion, removing the PureOS tags as we don't want to risk tainting PureOS with the remaining proprietary software in our coreboot firmware. This project will remain on the coreboot side.
More work on this today. Got compiling going etc, and the "system-info" call works, etc. etc. \o/
Given most of the work for this is not coreboot work, but PureOS work integrating an existing firmware image (which we'd treat as a binary blob) with fwupd, I don't know that this is really a coreboot project as much as a PureOS project.