@deeplow do you mind to pin it somewhere if it’s possible? Thank you.
Pinned it on this category.
Added the “signed” word to the title to make this fact more evident.
11 posts were merged into an existing topic: Verifying Qubes 4.1 weekly builds
5 posts were split to a new topic: Last Boot Option Not Remembered (build 20210410)
I’ll do some recurrent cleaning for space consideration. I keep only ISOs for the current month now.
sorry I am a bit new - where should I submit bug reports for the weekly alpha builds ?
I think you can use Qubes issues tracker: Issues · QubesOS/qubes-issues · GitHub. In a standard way, describe the issue and precise the exact timestamp you used for ISO like e.g. 20210522.
Unpinned for a while in favor of This Category is Now For 4.1 User Support
As you might know, Heads permits to verify ISO when a accompanying ISO detached signature is provided alongside, as long as Heads have the corresponding distro signing public key fused inside of the ROM.
Here, let it be under debian-10 or Heads, the importation of fepitre-bot distro public signing key results in:
user@x230-master:~/heads$ gpg --import initrd/etc/distro/keys/qubes-testing.key
gpg: key 656946BA873DDEC1: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg: w/o user IDs: 1
user@x230-master:~/heads$ gpg --version
gpg (GnuPG) 2.2.12
Consequently, I cannot distribute keys.openpgp.org under Heads to facilitate QubesOS ISO testing.
Not the end of the world. Heads users can still gpg --detach-sign with their own keypair and validate detached signature produce against their public key fused inside of the ROM, but the whole concept of being able to import the public distro key of fepitre-bot to validate detached signatures of ISOs seems to not work correctly here.
Advice? Possibility of renewing that public distro-key with a valid user ID?
That seems to be a common problem, would you by chance be using the openpgp.org keyserver ? You may want to use eg. the Ubuntu keyserver instead (I would be happy to learn that other ones are working as we expect).
As pointed by HW42 here the public key downloaded from here permits to do verify the ISO prior of booting the installer successfully (where downloaded key from keys.openpgp.org is not importable. Might want to document where to download public key in OP here.)
Commit here. (Will cherry-pick and push in new PR once QubesOS 4.1 installer over Heads ISO boot: blivet doesn't find mount attribute on already mounted loopback device for install when installing packages · Issue #6792 · QubesOS/qubes-issues · GitHub is fixed)
@fepitre : Can you look quickly into QubesOS 4.1 installer over Heads ISO boot: blivet doesn't find mount attribute on already mounted loopback device for install when installing packages · Issue #6792 · QubesOS/qubes-issues · GitHub to let me know if I need to add more info there? It was tagged as needing diagnosis by Andew, where all information was already provided. Please tag me there if you need more input.
Is it normal for a download that says it’s 5.1 GB to show up as 5.4 GB after its downloaded? This has me curious. It happens with me frequently. Might be worth looking into, might be paranoia. Anyone wanna take a guess?
You should be sure of the units you use…It 's 5.4GB vs 5.1GiB…In an the cases compare in Bytes
A post was split to a new topic: Qubes 4.1 Does Not Have the Whisker Menu
this can happen because some software counts kilo, mega, gigabytes by multiples of 1000, other 1024, and it can also vary depending on the blocksizes of the filesystem the file is stored on.
either way, it is always good to check via pgp signatures, or at least checksums like sha256 or sha512, e.g.