Re: [qubes-users] HELP! after update dom0 "no bootable device found"

[Ulrich Windl]

You could try to boot the kernel installed using: 
https://www.supergrubdisk.org/super-grub2-disk/


On 1/30/21 11:28 AM, donoban wrote:

Hi,

On 1/30/21 8:43 AM, haa...@web.de wrote:

I am surprised by the sizes -- files seem small. Do the seem correct??
Are there files missing?? Could maybe someone check these md5sums, please?
  
1ff66a646f443da650caca5a71d14dc9  initramfs-5.10.11-1.fc25.qubes.x86_64.img

0ed0b625599395686c950b11ca626659  initramfs-5.10.5-1.qubes.x86_64.img
66ad105adc1bcf8543fde0be5e1cffa9  initramfs-5.10.8-1.qubes.x86_64.img
aa03e2e037aa2a173c4f9a2db6dd9096  initramfs-5.4.91-1.fc25.qubes.x86_64.img
36993c5ea1f93a37c548f8ac32b18baf  vmlinuz-5.10.11-1.fc25.qubes.x86_64
9669c095819240d8117f208748707b4c  vmlinuz-5.10.5-1.qubes.x86_64
3db1a8bdd97a608a5459ac5521052ab8  vmlinuz-5.10.8-1.qubes.x86_64
0834cc9a9bfbacb9cfc420f3b879bca7  vmlinuz-5.4.91-1.fc25.qubes.x86_64
  


[user@dom0 boot]$ sudo md5sum initramfs-5.*
9026c8b1f9d4ba3da856197e6a864f87  initramfs-5.10.11-1.fc25.qubes.x86_64.img
7b37ca7152c6a13d43c8786b309781af  initramfs-5.10.7-1.qubes.x86_64.img
037caef7ad5ffae014c02174f9d32ec8  initramfs-5.10.8-1.qubes.x86_64.img
4ab81d0bd949b982bc1d4c8624e6ed97  initramfs-5.4.83-1.qubes.x86_64.img
0167631c01c4a8e48f231e93adbc30dc  initramfs-5.4.88-1.qubes.x86_64.img
ad56a62721d0953e9b7547b6e0f34c8e  initramfs-5.4.91-1.fc25.qubes.x86_64.img

[user@dom0 boot]$ md5sum vmlinuz-5.*
36993c5ea1f93a37c548f8ac32b18baf  vmlinuz-5.10.11-1.fc25.qubes.x86_64
55e0df9ec8fa8e5b812a2e0bf9794094  vmlinuz-5.10.7-1.qubes.x86_64
3db1a8bdd97a608a5459ac5521052ab8  vmlinuz-5.10.8-1.qubes.x86_64
0834cc9a9bfbacb9cfc420f3b879bca7  vmlinuz-5.4.91-1.fc25.qubes.x86_64


Probably the initramfs differ due different hardware or configuration.
vmlinuz image seems fine.


(3) I could try the " efibootmgr " commands mentioned in UEFI

troubleshooting, but I do not understand them, and I am afraid to f*ck
it up even worse. If my harddrive-boot partition is mounted on /BOOT
instead of /boot  , how would the command read, please??

It seems it ignores your mountpoint, you pass directly the hard disk and
EFI partition number (which should be the first) so in:
efibootmgr -v -c -u -L Qubes -l /EFI/qubes/xen.efi -d /dev/sda -p 1
"placeholder /mapbs /noexitboot"

You only have to worry about /dev/sda

You only need to worry about /dev/sda, if you are afraid about breaking
it more try using a different label like "-L TryingQubesRescue".



--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/10416cfb-c4f7-4842-51af-b1f6c822dd2c%40rz.uni-regensburg.de.

Re: [EXT] Re: [qubes-users] Q: Installing additional software

[Sven Semmler]

On 2/1/21 3:58 PM, Ulrich Windl wrote:

Couldn't there be conflicts between the updates in the AppVM and the
template? If not, wouldn't that waste space by keeping some updates
more than once?

If the AppVM is not a disposable one, the updates are still lost? 
Wouldn't that mean any (e.g.) update for GIMP would be lost as well?


Hi Ulrich,

I think all your questions get answered here:

https://www.qubes-os.org/doc/templates/#inheritance-and-persistence

/Sven

--
 public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2eac91d8-9f85-ec98-abf3-094f95bf1890%40SvenSemmler.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [EXT] Re: [qubes-users] Q: Installing additional software

[Sven Semmler]

So you don't base AppVMs on the minimal template, but have multiple 
"adjusted" almost-minimal templates?


Unman is the actual maintainer of the debian templates
(https://www.qubes-os.org/team/#unman)

My understanding of what he wrote is that he bases "almost *all*" of his
"working qubes" on "adapted minimal templates". Meaning on
debian-minimal plus specific packets for the specific purpose.

He might have also other qubes based on other distributions (e.g. kali,
parrot etc).

I guess you have a special update cache also, as otherwise you spend 
hours with updating. Can you explain a bit more?


You might find his notes on apt-cacher-ng helpful:
https://github.com/unman/notes/blob/master/apt-cacher-ng

I am sure unman will answer himself, but thought I might already give 
you a little preview as far as I can.


/Sven

--
 public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/19b69014-0aa0-4d3e-93ae-e7b3ed8427b9%40SvenSemmler.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [EXT] [qubes-users] Updating a new installation

[Ulrich Windl]

On 1/27/21 7:44 AM, Shawn Creighton wrote:
What is the quickest and most secure way to update the entire system 
including Dom0 on the first boot of a new install? I've noticed that it 
takes awhile for the updates to populate to the qubes updater when first 
connected to the net even though there are obviously updates available. 
Is there a way to expedite the process?


I think you can always run the dom0 updater to get the updates, and for 
the VMs it seems that starting one reduces the time until updates for 
the corresponding template are found.

Still I'd like an explicit "check for updates"...



--
You received this message because you are subscribed to the Google 
Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to qubes-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABF_mq1OTL78t%3DHfeOGkGrdyCogJPWOQ1sLW-qf5WgLa6n7TiQ%40mail.gmail.com 
.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f6f28ed0-9743-4ffb-f892-711e93a0d2ed%40rz.uni-regensburg.de.

Re: [EXT] [qubes-users] Can't access flash drive

[Ulrich Windl]

On 1/16/21 4:40 PM, Shawn Creighton wrote:


I have a Sandisk Cruzer 8GB flash drive I've had for a few years, when I 
plug it in to Qubes it shows up in the available devices but when I 
connect it to any appvm it's not rshowing up in the file manager. Other 
newer flash drives work fine. Any ideas?


What's the output of (Dom0):
* blkid /dev/your-stick
* fdisk -l /dev/yopur-stick

?



--
You received this message because you are subscribed to the Google 
Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to qubes-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7f458ab4-ce5f-4efa-afd8-6aeb6e5fe410n%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d7f184dd-d41b-43ba-dbe1-ccd90be052f7%40rz.uni-regensburg.de.

Re: [EXT] Re: [qubes-users] Q: Installing additional software

[Ulrich Windl]

On 1/16/21 2:39 AM, unman wrote:

On Fri, Jan 15, 2021 at 06:35:13PM -0600, Sven Semmler wrote:

On 1/15/21 6:10 PM, unman wrote:

at the expense of security, since all AppVMs based on that template
will have a large number of applications/libraries which may be ripe
for exploit.


Could you please elaborate? I am not sure I understand.


Many attacks rely on chaining exploits and loopholes in an assortment of
applications and libraries.
You see this very often in "capture the flag" contests, and in real
world attacks.
If you use a single template and load it with software (and therefore
associated libraries) you have significantly broadened the attack
surface: this is particularly so if you install "recommended and
suggested" packages.
By contrast, if you use a minimal template and install a single
application, the attack surface is smaller.
If you have a template loaded with file viewers, office applications and
drawing software, it will undoubtedly be extremely useful. But the
attack surface is large. If you use that template as the basis for your
mail reader, for example, then there is scope for an attack using a crafted
email attachment.
But if you use a minimal template with a good mail reader like mutt,
and open all the attachments in an offline disposable VM based on that
extensive template, the risk to your mail reader, and by extension
your Qubes system, is reduced. (Note, reduced but nor removed.)

In my system, almost *all* my working qubes are based on adapted minimal
templates, and most of them, including my mail qubes, are offline.
This may be why I have an unholy number of templates.


So you don't base AppVMs on the minimal template, but have multiple 
"adjusted" almost-minimal templates? And you make AppVMs from those or 
disposable VMs?
I guess you have a special update cache also, as otherwise you spend 
hours with updating.

Can you explain a bit more?


File storage qubes are exactly that - they store files. If I want to
view, or edit, I do it in an offline qube: I *have* to do it in another
qube, because the storage qubes don't have the capacity for anything
except plain text editing (and imagemagick, and some python and).
Are there risks? Of course.




I'm not altogether clear on what you mean here.


I understood

1) AppVM based on debian-10 and install gimp in AmpVM. The OP might or might
not be aware of binds/persistence.


I didnt hear this in what OP wrote.



--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3a17165f-479b-0d19-6810-c961755e124a%40rz.uni-regensburg.de.

Re: [EXT] Re: [qubes-users] Q: Installing additional software

[Ulrich Windl]

On 1/16/21 1:10 AM, unman wrote:

On Sat, Jan 16, 2021 at 12:41:04AM +0100, Ulrich Windl wrote:

Hi!

I have a question about installing additional software (e.g. GIMP in
debian-10):
The options I see are:
1) Install it in some AppVM based on debian-10
2) Clone debian-10 template and install software there. Create some AppVM
based on that template

I'd guess 1) needs less space, but for 2) I'm not sure what happens when
updates are applied to both, the template and the AppVM.

Regards,
Ulrich



1. needs less space, but at the expense of security, since all AppVMs
based on that template will have a large number of
applications/libraries which may be ripe for exploit.

I'm not altogether clear on what you mean here. You then have two


Sorry for the late response: I mean if I install e.g. GIMP in an AppVM 
based on debian 10, what happens if I update the AppVM first (updating 
some parts of debian 10 and GIMP) and later I update the debian10 
template: Couldn't there be conflicts between the updates in the AppVM 
and the template? If not, wouldn't that waste space by keeping some 
updates more than once?



templates which will need updating - unless you are using a caching
proxy instead of the standard tinyproxy, this is going to take time and
suck up bandwidth.
You can, naturally, update the AppVM separately from the template, as
usual, but updates will be lost on reboot. (I do this sometimes when I am
checking on updates/installs or configuration changes: one of the great
things about Qubes.)


If the AppVM is not a disposable one, the updates are still lost? 
Wouldn't that mean any (e.g.) update for GIMP would be lost as well?


Regards,
Ulrich





--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7936589e-7197-400f-afa3-7fc3c69fa6d0%40rz.uni-regensburg.de.

[qubes-users] 4K videos on external monitor lagging like hell

['Kevin Smith' via qubes-users]

I have a Lenovo Yoga 720-15IKB laptop. If I connect an external monitor and try 
to play a 4K video from lets say Youtube, the video is lagging like hell. I 
imagine this to be due to insufficient VRAM?

I tried to increase the VRAM by using this command in Dom0 terminal
"qvm-features dom0 gui-videoram-min 64000". I increased it a little bit extra 
to see if it works. but it did not change the matter.

Thanks in advance
Kevin

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/gxdLke0G3faciNjL6lkNM9GBT_8vZc2XkD6vpwCPQFVLF2L61wRnuQ3Hk-Axabo6ptmk29gueMLBDdoyQY2-GFPU-I2NPA6kjVXlKGXJac8%3D%40protonmail.com.

Re: [qubes-users] Re: VT-d on XPS 9310

[donoban]

On 2/1/21 1:07 AM, Fabrizio Romano Genovese wrote:
> Ok, my BIOS wasn't updated. That solved the VT-d problem.
> 
> Everything seems to work aside of wifi. I have a Killer AX500, which is
> currently supported only in kernel 5.10+. For what I understand, in
> Qubes Fedora comes with Kernel 5.4.something at the moment. I've found
> some tutorials to update a generic Fedora kernel to 5.10, but I suppose
> the kernel I'm running now is customized to be ran within a qubes
> environment. If I try to compile and update sys-net to kernel 5.10 how
> likely it is that I'll make a mess?

Great!

Take a look in https://www.qubes-os.org/doc/managing-vm-kernel/
specially in 'Using kernel installed in the VM' section. Last time I've
tried it with Centos template it failed and finally I installed a HVM,
(could work using a HVM as sys-net?).

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2fa1fffb-bade-c275-469a-52f3dd83962d%40riseup.net.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Re: [PATCH v5.10] drm/i915/userptr: detect un-GUP-able pages early

[donoban]

On 2/1/21 2:56 AM, Jinoh Kang wrote:>> Here is the concatenation of all
files (probably in reverse or wrong order):
>> blob:https://share.riseup.net/3360675c-292f-4114-a109-c410e2518295
> 
> That's a wrong URL (blob:).  Maybe copy it again?


Ouch, I felt that it was more readable in raw format (if you click on
'View in Browser'). But it seems that the blob url points to something
local in memory after decrypting conent from the main url.

Here I pasted again: https://share.riseup.net/#FsOrmx0lsWG4vZdcZi8ROg

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2c985be5-51ae-e8e4-2cb9-c8174bd495d6%40riseup.net.


OpenPGP_signature
Description: OpenPGP digital signature