Re: [qubes-users] Issue verifying media
'src11' via qubes-users:
> Trying to install the most recent version of Qubes from USB on a Purism
> Librem 15 laptop. When I click verify media I get two of these errors:
>
> dracut-pre-udev[463]: rpc.idmapd: conf_reinit: open ("(null)", 0_RDONLY)
> failed
>
> What does that refer to and is it ok to proceed?
>
Don't know if I've seen that, but seems harmless enough. Try ignoring
and proceeding.
--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots
--
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/506c1df8-bcdd-0493-465e-9f35e0fbdb41%40danwin1210.me.
Re: [qubes-users] Adding a new SSD causes Qubes to go into dracut emergency shell
Hi everyone, I got around to swapping the two SSDs, and now it properly boots to the login screen! The only issue is that all the PCI numbers seem to have incremented by 1, so I'll have to readjust my setup. The whole thing was a really strange issue, but at least now I don't have think about a full reinstall. Thanks to everyone for their input. -- 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/8271faeb-cbfe-454f-8abf-0fd781e6778co%40googlegroups.com.
Re: [qubes-users] Adding a new SSD causes Qubes to go into dracut emergency shell
In the BIOS (it's an ASUS x570 one), it says that the first drive in the boot priority is set to my older SSD. Under storage information, it labels my new SSD as "M.2_1" and my old SSD as "M.2_2". Can't find any options to disable an M.2 port. -- 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/ee68a8f1-dd33-40bc-b935-b76f164908efo%40googlegroups.com.
Re: [qubes-users] Multi Media update fails Qubes 4
On Fri, Sep 11, 2020 at 04:40:08AM -0700, William Fisher wrote: > I have the Multi Media VM installed including Chrome, Spotify, Musique, VLC > player, etc. Qubes Updater keeps saying it needs updates but the updates > always fail. It always comes back with 1 changed 2 failed. > > Error on updating t-multimedia: Command '['sudo', 'qubesctl', > '--skip-dom0', '--targets=t-multimedia', '-show-output', 'state.sls', > 'update.qubes-vm']' returned non-zero exit status 20 > >ID: dsa-4371-update > Function: cmd.script > Result: True > Comment: Nothing to do > > >ID: update > Function: pkg.uptodate > Result: False > Comment: w:target Packages (main/binary-amd64/Packages) is configured > multiple times in /etc/apt/sources.list.d/google-chrome.list:3 > and/etc/apt/sources.list.d/google.list:1 > > I have numerous other packages listed multiple times but I can't figure out > how to copy the text displayed in dom0 Updater to this VM. > > Any ideas? > Is this a common problem? > How can I get updates on multi-media, especially Chrome and VLC Media > Player? > I see no reason to copy the text to the VM. I would try opening the template you are using and removing the duplicate entries: the files to review are clear, and it shouldnt be difficult for you to delete as necessary. (You'll need to do this as root.) I would then try an update in the template. Then try the Qube Updater. I'm not sure what you mean by "numerous other packages listed multiple times" or why you would want to do this. -- 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/20200911124821.GB12791%40thirdeyesecurity.org.
Re: [qubes-users] Adding a new SSD causes Qubes to go into dracut emergency shell
On 9/11/20 11:23 AM, 'ktono' via qubes-users wrote: Hi, I haven't tried switching. One of the slots is under some CPU cooler fans, and I don't have the stuff to remove/deal with that at the moment. I believe I'm using direct EFI. The first SSD, where I have all my original data, under `fdisk -l` shows one of the devices having the "EFI System" type. My old drive has name nvme1n1, and it has a UUID with "c04b", which matches what is under "rd.luks.uuid" in xen.cfg under EFI/qubes when I mount the "EFI System" device. The newer drive has name nvme0n1, and it has UUID with "fe3d". This newer disk shows up in the dracut shell when I do `blkid`, but the older one is missing On Friday, 11 September 2020 at 01:43:02 UTC-7 donoban wrote: On 2020-09-11 07:26, ktono via qubes-users wrote: > I have a Qubes 4.0.3 setup that uses an NVMe SSD for storage and boots using UEFI. My motherboard has 2 NVMe slots, so I still had one free slot. Everything worked fine on Qubes. > > Then, I decided to install a second NVMe SSD (the same model). After doing that, booting Qubes only puts me into Dracut Emergency Shell. > > The error messages I get: > > ``` > So I think Qubes is trying to boot with the new, empty SSD or something like that. > Hi, Have you tried switching the hard disks slots? Are you using direct EFI or GRUB? > When I use a Qubes USB installer to get a shell, I can still find my old SSD. When I do `cryptsetup open /dev/nvme<...>` on my old SSD, I can then `fdisk -l` to find the names of all my AppVMs, etc., so it's not like the space was wiped. What numbers has your old disk assigned? Theorically the boot hard disk uuid is passed as kernel argument: "rd.luks.uuid=.." So a change with major/minor numbers should not affect. If you are using EFI to boot the system, check in the bios which disk that efi is defaulting to. It is odd that your original disk has the "1n1" numbering and the new disk is "0n1". That may have confused the efi boot ordering. Mike. -- 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/90fd36e5-21dc-b034-5405-a400ea351c0c%40keehan.net.
[qubes-users] Multi Media update fails Qubes 4
I have the Multi Media VM installed including Chrome, Spotify, Musique, VLC player, etc. Qubes Updater keeps saying it needs updates but the updates always fail. It always comes back with 1 changed 2 failed. Error on updating t-multimedia: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=t-multimedia', '-show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20 ID: dsa-4371-update Function: cmd.script Result: True Comment: Nothing to do ID: update Function: pkg.uptodate Result: False Comment: w:target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/google-chrome.list:3 and/etc/apt/sources.list.d/google.list:1 I have numerous other packages listed multiple times but I can't figure out how to copy the text displayed in dom0 Updater to this VM. Any ideas? Is this a common problem? How can I get updates on multi-media, especially Chrome and VLC Media Player? -- 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/80675b32-050e-465e-8b40-601662fd2246o%40googlegroups.com.
Re: [qubes-users] Has anyone had a qube compromised?
unman: > On Tue, Sep 08, 2020 at 09:13:47PM +0200, Qubes wrote: >> On 9/7/20 2:12 AM, unman wrote: >>> On Sun, Sep 06, 2020 at 06:55:01PM +0200, Qubes wrote: On 9/6/20 5:32 PM, unman wrote: > On Sun, Sep 06, 2020 at 11:12:31AM -0400, Demi M. Obenour wrote: >> In all of my time using QubesOS, I have never had reason to believe >> that a qube was compromised. Has anyone here had a qube compromised? >> >> Sincerely, >> >> Demi >> > > I have had occasion to set a honeypot and use Qubes as a classic > Internet-inna-box - ideal for such use, and very instructive. But I > guess that wasn't what you were interested in. > In normal use, both myself and colleagues have seen compromised qubes. > Hi Unman How did you know you're qube was compromised, can you give some details? >>> >>> snort and tripwire. >>> >>> Other IDS are available. >>> >> Hi Unman >> >> What I mean is what made you suspicious to use a tripwire and snort? > > I run them on most of my Qubes installs, almost out of habit. > Because I salt my qubes, its relatively easy to run tripwire against > network connected qubes > But the way in which Qubes allows one to separate out activities really > does minimise risk. Example: read email in mutt in offline qube with > minimal template - any attachments are opened in offline disposableVM. > Anything I want to keep is transferred to an offline storage qube , > again with no significant programs installed. In this sense, it doesn't > matter if attachments have malware because the infection risk is > minimised. > This is interesting. Can you be more specific in regards of settings you use? How do you set the tripwire for to run against network connected qubes? You also mentioned using mutt in an offline qube. Can you elaborate more on this too please? Is the mutt PGP friendly and more safer option than Thunderbird? -- 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/ba27d2bc-2660-6308-d5d6-754fca5fda6d%40mailbox.org. 0xA664B90BD3BE59B3.asc Description: application/pgp-keys
Re: [qubes-users] Adding a new SSD causes Qubes to go into dracut emergency shell
Hi, I haven't tried switching. One of the slots is under some CPU cooler fans, and I don't have the stuff to remove/deal with that at the moment. I believe I'm using direct EFI. The first SSD, where I have all my original data, under `fdisk -l` shows one of the devices having the "EFI System" type. My old drive has name nvme1n1, and it has a UUID with "c04b", which matches what is under "rd.luks.uuid" in xen.cfg under EFI/qubes when I mount the "EFI System" device. The newer drive has name nvme0n1, and it has UUID with "fe3d". This newer disk shows up in the dracut shell when I do `blkid`, but the older one is missing On Friday, 11 September 2020 at 01:43:02 UTC-7 donoban wrote: > On 2020-09-11 07:26, ktono via qubes-users wrote: > > I have a Qubes 4.0.3 setup that uses an NVMe SSD for storage and boots > using UEFI. My motherboard has 2 NVMe slots, so I still had one free slot. > Everything worked fine on Qubes. > > > > Then, I decided to install a second NVMe SSD (the same model). After > doing that, booting Qubes only puts me into Dracut Emergency Shell. > > > > The error messages I get: > > > > ``` > > So I think Qubes is trying to boot with the new, empty SSD or something > like that. > > > Hi, > > Have you tried switching the hard disks slots? Are you using direct EFI > or GRUB? > > > > When I use a Qubes USB installer to get a shell, I can still find my > old SSD. When I do `cryptsetup open /dev/nvme<...>` on my old SSD, I can > then `fdisk -l` to find the names of all my AppVMs, etc., so it's not > like the space was wiped. > > > What numbers has your old disk assigned? Theorically the boot hard disk > uuid is passed as kernel argument: "rd.luks.uuid=.." So a change > with major/minor numbers should not affect. > -- 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/c79bb344-5967-4db5-a402-2e71744a3a1bn%40googlegroups.com.
Re: [qubes-users] Adding a new SSD causes Qubes to go into dracut emergency shell
On 2020-09-11 07:26, ktono via qubes-users wrote: > I have a Qubes 4.0.3 setup that uses an NVMe SSD for storage and boots using > UEFI. My motherboard has 2 NVMe slots, so I still had one free slot. > Everything worked fine on Qubes. > > Then, I decided to install a second NVMe SSD (the same model). After doing > that, booting Qubes only puts me into Dracut Emergency Shell. > > The error messages I get: > > ``` > So I think Qubes is trying to boot with the new, empty SSD or something like > that. > Hi, Have you tried switching the hard disks slots? Are you using direct EFI or GRUB? > When I use a Qubes USB installer to get a shell, I can still find my old SSD. When I do `cryptsetup open /dev/nvme<...>` on my old SSD, I can then `fdisk -l` to find the names of all my AppVMs, etc., so it's not like the space was wiped. What numbers has your old disk assigned? Theorically the boot hard disk uuid is passed as kernel argument: "rd.luks.uuid=.." So a change with major/minor numbers should not affect. -- 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/8610fd70-df72-a0a8-3cad-30360f08a81a%40riseup.net.
