[qubes-users] Dual booting different Qubes versions on same machine

2021-06-22 Thread River~~
Hi all,

I noticed the new "alpha" level isos in the downloads and feel
motivated to help testing it.

I obviously do not want to go over to alpha for my normal work, but
would be interested if I can install it alongside my existing current
release. That way I would be testing that it works on the exact
hardware that I would eventually be running it on when it reaches
production quality.

Do I proceed as for the instructions for installing Qubes as a second
boot option to Linux? If not, what would be different?

What additional risks might I introduce by running a development
version of Qubes on the same physical machine as the production
version?

Obviously I would not have any files/partitions shared apart from the
EFI partition.

Would it make sense to install it onto an EFI partition on a different
internal disk? Would it be better for any reason to install it onto a
USB drive? (my guess to both of these is no, because when the test
system is running the production system would be on the host even if
not mounted)

My current production version is R4.0.3 and I will shortly be
replacing it with R4.0.4. At the time of writing the current alpha is
R4.1.0 but that my (or may not) change by the time I get around to
installing it.

I thought I would dual boot the new R4.0.4 with the existing R4.0.3,
then once R4.0.4 is verified as working for me I would transfer the
user level files and then overwrite the older production version with
the alpha test version. Anyone who can think why that might be a bad
idea please speak now or forever hold your peace (as they say in
English weddings)

I did a google search for "dual boot qubes versions site:qubes-os.org"
but it only pointed me to info about dual booting with non-Qubes
systems.

Once successful, would ppl welcome my spending time adding a section
to the dual boot online documentation? I would be happy to do so if
just one person thinks it might be useful

WArmly
River~~

-- 
9831*2^1441403+1 is prime, >400k digits

-- 
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/CAK3jUKovJGHW1m45D8_5c%2BJmLWV8RoDTQyzCdFRjQ%3DixRg_XRA%40mail.gmail.com.


[qubes-users] Recover from bootloop after failed kernel install

2020-11-27 Thread River~~
Hi all,

I did something stupid and now don't know how to recover gracefully.

I intended to install a new kernel for use in a vm, but actually
installed the one for dom0 because I installed the wrong packagename.
The result is that Qubes does not boot but sends the machine into an
endless boot -> panic -> reboot ... loop.

The error message that flashes past says "tried to kill init" followed
by a dump of some kind that flicks past too fast to read

The docs tell me how to edit what file in order to correct the failure
to boot, at

https://www.qubes-os.org/doc/software-update-dom0/#changing-default-kernel

but they do not tell me how to boot in order to issue the nano
command. I have also discovered that until Qubes 5 there is no plan to
bring in a boot menu with recovery options, as is provided for systems
still booting with grub2.

Am I right in assuming that until Qubes 5 there is no solution within
the Qubes system? Meaning that I will need to boot with Knoppix or
some other live distro ??

Or is there a more elegant route back to a working Qubes system?

If it is in the docs somewhere else, then please post a link to it
because I couldn't find it despite searching.

I think there should be slightly more in the docs than I could find
and am prepared to do the edit, but before I do that I want to know I
am making the most elegant suggestion.

I intend to update the docs in the section linked above sometime after
0500 UTC on 30th November and would welcome a heads-up by then if your
idea is more elegant that using Knoppix.

In the meantime, I am going to use Knoppix right now because a
solution I know beats an elegant one I didn't think of...

Warmly
River~~

-- 
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/CAK3jUKpC%2BM4J4q-P%2ByW-6YhuhKiYnQ_K91JQx30Y20GYPhGPsA%40mail.gmail.com.


Re: [qubes-users] Are "smart" monitors/TVs a security issue?

2020-11-27 Thread River~~
hi Steve

Steve:
> Without a Nation State being involved, the most likely threat would come
> from a permiscuous WiFi in the TV auto-connecting to any open networks in
> your area.

Good point. Which links to my thought if you wanted to keep a Qubes
box secure it would be a really BAD idea to plug it into someone
else's TV (like in a motel for example) or a conference room
projector.

My mitigation at home is to use the oldest flat panel TV I can find;
however that has its own difficulties (not security-related but to do
with the picture overscanning the screen).

> If you are sure that is not the case then it should be 'safe
> enough' for most people.
> Side channel attacks take tools, skills, and physical location that isn’t
> going to happen without you already being a target of some kind. It you are
> a target then no monitor is going to help and its time to unplug your
> computer.

There are degrees of Nation State interest ahd more than one level of
being a target; it is not all or nothing.

Presumably the top three tiers of interest are other Nation States
(especially those perceived as hostile), suspected terrorists, and
suspected paedophiles. Below that (I hope) in a fourth level would
come people with a non-violent agenda for significant political
change.

We know that many well known states put effort in to infiltrating such
groups in this fourth level -- to the extent where (for example) State
Infiltrators have been known to have long term, child procreating,
relationships with female activists while popping home to see their
real wives when they can -- so it is reasonable to suppose that there
is also some cyber-infiltration to their computers as well. Equally it
would be paranoid to imagine that any Nation State throws the full
range of their surveillance capability at every individual identified
with such groups.

> I once saw one demo years ago where the target machine with no
> known public vulnerabilities at the time was rooted in less than 15s. They
> don't play around.

Agreed -- in fact it is worse than that.

Those who know how to access to the Intel ICE processor or the AMD
equivalent (whose name I forget) have millisecond access whenever they
want it whenever an Intel or AMD machine is directly net-connected or
connected via routers that are themselves compromised in other ways.
That is after all the hidden-in-plain-sight message on the sticker:
Intel Inside ;) and why Qubes certify so few recent machines.

Apart from avoiding TV's that connect to random unknown Wifi or that
are owned by someone else, I think that I would have to stop using a
recent AMD box other risks of entry via the TV became the biggest
security issue.

Warmly,
R~~

-- 
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/CAK3jUKoeZTXOFrCEjza3zg%2Bd89qYiB8aZyO29bTYrun0ZFH3rQ%40mail.gmail.com.


Re: [qubes-users] Re: Getting wifi working on a new machine in qubes 4.0.3 and 4.0.4-rc1

2020-11-27 Thread River~~
Rusty Bird wrote:

> > 00.08.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
>
> https://github.com/QubesOS/qubes-issues/issues/5615#issuecomment-702032377

Thanks for the signpost Rusty :)

-- 
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/CAK3jUKp95ah7-ZqkDL5O%2BQ_G7vUtD_d%2BR%3DSPsx7kFYKoTRj6xw%40mail.gmail.com.


[qubes-users] Re: Getting wifi working on a new machine in qubes 4.0.3 and 4.0.4-rc1

2020-11-25 Thread River~~
PS

I just checked lspci from terminal in sys-net - it is definitely
showing the device, which it lists as follows

00.08.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)


-- 
9831*2^1441403+1 is prime, >400k digits

-- 
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/CAK3jUKqnDsjOZAARt3swF-iK2BYDSWJoD_HmP%2BkiWKaotuQFKA%40mail.gmail.com.


[qubes-users] Getting wifi working on a new machine in qubes 4.0.3 and 4.0.4-rc1

2020-11-25 Thread River~~
Hi,

I am having difficulty getting my wifi working, and have tried in both
r 4.0.3 and 4.0.4-rc1.

I also tried in the live disks of Fedora versions 25 and 32. It does
not work in 25, but is fine in 32.

I checked the devices of sys-net, and the Intel network controllwer is
being passed across OK. It must be the right device because everything
else on the motherboard is AMD ;)

Am I confused or what? I had imagined that if the device is being
passed through to sys-net, then the drivers would have to be in
sys-net? And I also thought that if the standard Fedora 32 contained
the drivers for this wifi device then the qubes template would?

Am I making too many assumptions there? Any ideas what I need to try
to do next to get this working?

Warmly
R~~

-- 
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/CAK3jUKqMy2JO25JFvTuaYHCB4cij2h%3D-zm_%3DaZdKaxF%3D5Q5YZw%40mail.gmail.com.


[qubes-users] installing non-free graphics drivers in dom0 (?)

2020-11-25 Thread River~~
I need to use xrandr to make the edges of my Qubes screen visible in
the TV I am using as an HDMI monitor, and this works fine on Knoppix
and LinuxMint.

I have not been able to get xrandr to set --output at all on Qubes 4,
Fedora 25, and Fedora 32. Research on other forums shows this is
likely because Knoppix and LinuxMint both include nonfree graphics
drivers, and apparently Fedora does not (at least not by default)

I do recall seeing a note some time ago to the effect that AMDGPU can
be problematic but I had hoped that that was no longer so much the
case.

On a Debian like system the command would be apt install firmware-linux-nonfree

What would the equivalent be on dom0?

Providing that the firmware from the manufacturer is not malicious,
are there any other risks that I should be aware of?

Or is this something that is not possible to do and I should therefore
buy a more suitable monitor?

The graphics is provided by a very recent AMD Radeon enabled combined
CPU/GPU, but the drivers included in the late 2019 Knoppix work so
they clearly do not need to any more recent than that.

Background:

I am using an early flat-panel TV as a monitor. Like many TV's of its
time when used as a monitor the edges of the picture are hidden.
Sufficient of the edges are missing that a top or bottom bar (top like
on qubes, bottom like on Mint) are not very usable. I have to guess
where the button I want is.

The commands I use to fix the picture size use xrandr and work on the
Debian-based distros but not on Fedora, including the most recent
qubes versions.

Glad for any tips
R~~

-- 
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/CAK3jUKph4Muj2BCRhKn_X6SBZAqUdGE3Yac2ECf6A8W5a8V_yw%40mail.gmail.com.


[qubes-users] Are "smart" monitors/TVs a security issue?

2020-11-25 Thread River~~
Hi all

In the days of CRT monitors one way the security of a computer system
could be compromised non-intrusively (ie without amending the
installed code) was by picking up the radio-frequency leakage from the
tube in the monitor. This could only be done from near by, but where
possible it enabled the spy to see what was on the screen -- almost
everything that you typed (aprt from passwords that were blanked or
starred out). This was a remote form of shoulder surfing, where
someone looks over your shoulder in an environent like an internet
cafe.

Nowadays we do not have to worry about CRT monitors. But TVs are
increasingly delivered with their own internet connection, making it
easy to watch You-Tube (etc) without needing a separate computer or
phone. Clearly there is a computer inside which can be hacked, and if
so a remote shoulder surfing attack would be very possible.

Is the same true of monitors and of TVs that do not have an apparent
internet link? The digital tech to draw a picture from the input is
unlikely to be done by traditional electronics, but being all digital
is likely done by a miniporcessor of some kind in all digital
displays.

To put my question in the most provocative way on this forum: if there
much point securing the OS when the monitor might be an easier target
for those out to (umm) monitor our reading and our keystrokes?

This thught has only just come to me, and I wonder if there is already
some available mitigation? Any ideas?

Or am I being overly cautious?

R~~

Any ideas?

-- 
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/CAK3jUKoDK8kX2jhx3J-m%3D-%3DrRdVxpX7uaJCa5emwpXdSm-CWxg%40mail.gmail.com.


[qubes-users] Re: overscan issue & using xrandr in dom0

2020-11-25 Thread River~~
On 22/11/2020, River~~  wrote:
> hi all
>
> I have recently migrated my Qubes to an new desktop computer from my
> laptop. Because I have not yet bought a suitable monitor I am using a
> TV as an HDMI monitor, and am having the common difficulty that the
> picture is bigger than the display area. This is called overscan.
>
> The HDMI TV is old enough that it does not have a setting for use with
> PCs, nor a "normal" or "just scan" option. That means I need to adjust
> the issue from the computer end.
>
> On LinuxMint I can sort this using xrandr, and I had imagined this
> would be easy on Qubes, but no such luck :(
>
> The command that works on Mint fails on Qubes, because I have been
> unable to guess what the --output name is for my display, and the
> xrandr -properties command simply refers to the plugged in monitor as
> 'default', or as 'Screen 0', but neither of those works as a name.
>
> I have tried
>
> HDMI-A-0  (as that is what it is on LinuxMint)
> HDMI
> HDMI0
> HDMI-0
> HDMI-0-0
> HDMI1
> HDMI-1
> HDMI-1-0
> HDMI-1-1
>
> and a similar list (grasping at straws here)
>
> VGA
> VGA0
> VGA-0
> ...etc
>
> The computer has an AMD CPU with a built in GPU, and on LinuxMint is
> was easy to ask xrandr to list the three display connectors. I cannot
> find the relevant command on dom0. I can't find any docs on the Fedora
> site, though I can't say I really know my way around that.
>
> Is it Qubes, somehow hiding the display connector names? Is it that I
> just need to invoke some different magic command in dom0 to get xrandr
> to divulge the list of relevant names?
>
> Or is it that dom0 is already running wayland and I need a different
> command entirely?
>
> I had assumed that it would be straightforward, as I understand that
> Fedora in general has better graphics hardware compatibility than
> Mint/Ubuntu/Debian (though I may be out of date on that).
>
> I am not sure what other info I can give to help you to help me.
>
> Should I post the output from lspci? and if so, as produced on
> LinuxMint or as produced from Qubes?
>
> Be grateful for any suggestions.
>
> Final comments:
>
> If I can't fix this then Qubes is not really usable till I can afford
> a newer monitor -- but that involves spending the money I had
> earmarked to upgrade the new machine's memory to 32Gb from 8Gb.
>
> I am glad I still have the laptop installation, which works but it is
> a bit laborious as it only has 8Gb memory and is not upgradeable.
>
> --
> 9831*2^1441403+1 is prime, >400k digits
>


-- 
9831*2^1441403+1 is prime, >400k digits

-- 
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/CAK3jUKpxxhA3YjsBm8aFecg4a26uoCKnqtnJcwYCTOC1vgHBJw%40mail.gmail.com.


[qubes-users] Re: HCA reports - some advice please

2020-11-25 Thread River~~
On 22/11/2020, River~~  wrote:
> hi I have got a new computer working, and it is a model new to Qubes
> not just. (Guess who got it cheap on an early bird reduction on
> kickstarter then :)
>
> So, I am going to send in the HCA report. I have produced the .yml
> file. It contains some FIXME items. I am unclear: is it up to e to fix
> them, or are they a note to whoever processes the report before
> posting to the HCA page?
>
> If I have to edit them, what do I use for the "short" items? Am I
> reasonably free to abbreviate?
>
> I am thinking of including the cpio files, but do not want to share a
> serial number that they contain. WOuld those files be useful to others
> if I edited them so that the serial number reads "Redacted"?
>
> Finally, the manufacturer's name shown in the .yml is different from
> the name they used on kickstarter. Would it help, or would it cause
> confusion, if I added at the end of their name "t/a MinisForum"?
>
> WArmly
> R~~
>


-- 
9831*2^1441403+1 is prime, >400k digits

-- 
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/CAK3jUKqWAU%3D%2B0qVK%2BzEpM7zB17XzuYCAFkttqmB%2B9hZW1sg8cg%40mail.gmail.com.


[qubes-users] HCA reports - some advice please

2020-11-22 Thread River~~
hi I have got a new computer working, and it is a model new to Qubes
not just. (Guess who got it cheap on an early bird reduction on
kickstarter then :)

So, I am going to send in the HCA report. I have produced the .yml
file. It contains some FIXME items. I am unclear: is it up to e to fix
them, or are they a note to whoever processes the report before
posting to the HCA page?

If I have to edit them, what do I use for the "short" items? Am I
reasonably free to abbreviate?

I am thinking of including the cpio files, but do not want to share a
serial number that they contain. WOuld those files be useful to others
if I edited them so that the serial number reads "Redacted"?

Finally, the manufacturer's name shown in the .yml is different from
the name they used on kickstarter. Would it help, or would it cause
confusion, if I added at the end of their name "t/a MinisForum"?

WArmly
R~~

-- 
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/CAK3jUKpXxnhhKDH7MYh9Ghj9wmmd%3DQUm98SAT6AgD2vmyHRtBg%40mail.gmail.com.


[qubes-users] overscan issue & using xrandr in dom0

2020-11-22 Thread River~~
hi all

I have recently migrated my Qubes to an new desktop computer from my
laptop. Because I have not yet bought a suitable monitor I am using a
TV as an HDMI monitor, and am having the common difficulty that the
picture is bigger than the display area. This is called overscan.

The HDMI TV is old enough that it does not have a setting for use with
PCs, nor a "normal" or "just scan" option. That means I need to adjust
the issue from the computer end.

On LinuxMint I can sort this using xrandr, and I had imagined this
would be easy on Qubes, but no such luck :(

The command that works on Mint fails on Qubes, because I have been
unable to guess what the --output name is for my display, and the
xrandr -properties command simply refers to the plugged in monitor as
'default', or as 'Screen 0', but neither of those works as a name.

I have tried

HDMI-A-0  (as that is what it is on LinuxMint)
HDMI
HDMI0
HDMI-0
HDMI-0-0
HDMI1
HDMI-1
HDMI-1-0
HDMI-1-1

and a similar list (grasping at straws here)

VGA
VGA0
VGA-0
...etc

The computer has an AMD CPU with a built in GPU, and on LinuxMint is
was easy to ask xrandr to list the three display connectors. I cannot
find the relevant command on dom0. I can't find any docs on the Fedora
site, though I can't say I really know my way around that.

Is it Qubes, somehow hiding the display connector names? Is it that I
just need to invoke some different magic command in dom0 to get xrandr
to divulge the list of relevant names?

Or is it that dom0 is already running wayland and I need a different
command entirely?

I had assumed that it would be straightforward, as I understand that
Fedora in general has better graphics hardware compatibility than
Mint/Ubuntu/Debian (though I may be out of date on that).

I am not sure what other info I can give to help you to help me.

Should I post the output from lspci? and if so, as produced on
LinuxMint or as produced from Qubes?

Be grateful for any suggestions.

Final comments:

If I can't fix this then Qubes is not really usable till I can afford
a newer monitor -- but that involves spending the money I had
earmarked to upgrade the new machine's memory to 32Gb from 8Gb.

I am glad I still have the laptop installation, which works but it is
a bit laborious as it only has 8Gb memory and is not upgradeable.

-- 
9831*2^1441403+1 is prime, >400k digits

-- 
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/CAK3jUKpq15kmMLmF4MxB1WHRcZ6t%3DUCnnyE2pWkN1T_m1xJbtQ%40mail.gmail.com.


[qubes-users] Re: Happy Father’s Day

2020-06-23 Thread River~~
y to are Edinburgh, Glasgow, Aberdeen and Dundee. I have
>> emailed cambridge but they do not accept access courses at all for
>> engineering degrees so I would have to do A levels.
>>
>> I want to stay in scotland so to do A levels would mean studying the text
>> books and past papers independently and booking the exams directly with a
>> test centre that accepts independent students. I would have to study maths,
>> further maths and physics and get A*A*A. I am confident in my ability
>> academically to do it but I worry about my stability to do it without the
>> support of a college. I also worry I might not be happy at cambridge in
>> terms of it being a good fit for me as a person, it is the course I am
>> attracted to. I also want to stay in scotland long term, and of course the
>> financial situation would be much better as I am ordinarly resident in
>> scotland so I would be treated as a scottish student here for fees etc. Of
>> course there is nothing stopping me returning to scotland later if I study
>> elsewhere and I don't want to prioritise the financial cost over the right
>> course.
>>
>> The edinburgh access course has given me an undonditional offer and sent
>> me an application form for a bursary and fees, but they want a month by
>> month account of my employment for 5 years nd I have had dozens of
>> employers often for 1 week contracts and wouldnt know where to begin.
>>
>> If I figure out how to give a month by month account of my last 5 years
>> employment I could do the access course here but I would not be able to
>> apply to cambridge and in fact any english university i did apply to I
>> would have to check with because the scottish access system is different to
>> the english one.
>>
>> Do you have any thoughts on any or all of this.
>>
>> Incidentally, I am currently renting my friends spare room cheaply while
>> she is doing up her house but when I leave here in september I will be
>> moving into a van as rent is so high in edinburgh. For the price of a years
>> rent I can get a 1 company owner van with full service history that should
>> last me longer than a year. I managed winter at faslane so I think I am
>> able to do it I will just put in a shower and toilet as god knows when
>> public toilets will be open again.
>>
>> Love you lots hope you are well please tell me whats going on with you
>> sorry I am even more robyn focussed today than normal.
>>
>> Robyn
>>
>> On Mon, 22 Jun 2020 at 04:48, River~~  wrote:
>>
>>> Thanks!
>>> Have a great time in Ed
>>> Talk sometime
>>> Love you
>>> R~~
>>>
>>> On 21:39, Sun, 21 Jun 2020 Robyn Woof >>
>>>> Happy Father’s Day! I have been in Edinburgh for a few weeks I think
>>>> I’m going to stay here for a bit hope everything is good with you love you
>>>> lots
>>>>
>>>

-- 
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/CAK3jUKo_-km275ObBgsPNBNxzjDaFDOku2WM2tTR%2Be970iWbyw%40mail.gmail.com.


Re: [qubes-users] Re: qvm-create-windows-qube 2.0

2020-01-22 Thread River~~
No unman, please get off my case on this.

You misrepresent my intention totally, and ate responding without showing
signs of having read the material I pointed you to.

My *original* original post on this subject, which I pointed you to, asked
whether that expectation was reasonable, and awokd said that it usually
does work.

In that thread, xao pointed me to a list of packages relevant to minimal
templates, and suggested I used that to guide me.

My first post in this thread tried to pass that information on to other
people, as it seemed relevant.  That earlier thread also pointed to issue
#5123, which if you read the first post of that issue, starts from the
assertion that it seems I'm not the only Qubes user to come with that
expectation.

You say:

> I think your expectation is misplaced - ...

Then please explain exactly why issue #5123, which I also pointed you to
and which you also do not seem to have read, has adjusted the contents of
the Debian template to meet the fact that (according to the first post in
that issue) seems to be a common expectation.

> ... they are different distros, ...

They are actually both parts of the Qubes distro here, installed by either
the Qubes installer or from the Qubes repo -- their history from other
distros is irrelevant. And yes, when you install a real Debian you get
promoted for firmware. When you install the Qubes template you get no such
prompt.

Indeed, you install the Debian template using DNF not apt, because the
Qubes system regards it as software for Dom0.

>
> Your original post seemed to suggest that the Debian template didn't come
> with packages required to act as sys-XXX - this isn't true.

This is true.

Please stop denying that fact. It doesn't work before I followed xao's
advice, it does work after. Therefore at least one of those packages was
essential. And every one of the other packages added by #5123 will be
essential for some other users: that's why they are there.

Clearly a sys net Qube needs a working firmware *for* *the* *computer*
*it's* *on*, not just for some other hardware. End of.

That's why #5123 was accepted, because it fixed exactly this problem (or
certainly attempted to).

> It *may* lack
> packages required for some hardware -

 May 

It does lack them. Please stop undermining the facts. I told you that
installing them made it work. Do you not believe me

> just install them.

Exactly so.

That's exactly why it is helpful that xao pointed me to a list in the docs.
That's exactly why it's helpful for me to pass that advice on to others,
until such time as the "fully firmwared" Debian template becomes the norm
(as Chris pointed out in the earlier thread). That's exactly why it is
profoundly unhelpful for you to undermine that sounds advice.

> (The same is
> true for the Fedora templates)

Er no.

If a Fedora template didn't work it would be reported as a bug as soon as
the first user found they couldn't update through sys-net. And would be
acknowledged as a bug without all this prevarication, and it would not get
out of the rc1 stage, if it even got that far.

The reason the Debian one slips through the net is that it is not critical
in that sense. People can (and according to #5123 actually have) given up
on the Debian templates for sys-net due to this issue.

Whatever you think, the ppl who maintain the Qubes system accepted that as
an issue and believe it to be fixed by adding those firmware files. I'm
simply reporting that back.

But believe what you like.

This exchange is now closed as far as I am concerned.

-- 
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/CAK3jUKruysb66%3DitPNeO02qCZzTz-1r17q5PdgSf%2Bqg-q6vz_A%40mail.gmail.com.


Re: [qubes-users] Re: qvm-create-windows-qube 2.0

2020-01-20 Thread River~~
On 17:33, Mon, 20 Jan 2020 unman 
>
> So what you mean is that *your* Debian-9 template (updated) does not
> work as a template for sys-XXX qubes on *your* hardware.
> That's different.

I think you are missing my point here. The Fedora templates do work on both
my laptops, the (older) Debian templates didn't.

My expectation, which seems reasonable to me, was that the so called "full"
Debian template would be a drop in replacement for the full Fedora one, and
in fact that expectation turns out to be false: further work is needed to
make it work in some cases, including mine.

The fact that it happens to work on some other hardware does not alter the
fact that (at the time those Debian templates were issued) they were not
drop in replacements.

The fact that other ppl have hardware that fortuitously avoids that
difference is good luck for you but does not negate my point.

-- 
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/CAK3jUKqAjyrq8MD27Q96c%2Bs6HPqmCqs-w%2BLnkre%3DstojF%2BHBDw%40mail.gmail.com.


Re: [qubes-users] Re: qvm-create-windows-qube 2.0

2020-01-20 Thread River~~
Hi unman

I said:

> > In version 4 of Qubes, the Debian templates need a little extra
software to run as templates for the sys-XXX Qubes. Best to is to pieced
[typo: proceed] as if for the minimal Debian template, and apt-install
what's needed for the three sys-XXX Qubes. Some of those packages are
already installed but apt will just tell you so, and install the missing
ones
> >

> The Debian template should be usable for sys-** qubes - it is for me,
> and I dont think I installed anything on the default template. (although
> I do build my own.)
> Please detail which software you think is missing.

I'm sorry that i can't be as helpful as you hope: or not right away anyway.

In particular, my Debian 9 template was installed sometime early in 2019
and therefore I cannot either confirm or counter whether issue #5123 would
have fixed this for me: in theory it looks like it might have done. I plan
to test this when I have time.

In more detail:

It failed to work on two different laptops. On one neither sys-net nor -usb
work with the Debian 9 template out of the box as installed by R4.0, fully
updated; on the other sys-net refused to work and -usb was absent. In both
cases reverting to the fedora template made the VMs work again.

See my previous query about this

https://groups.google.com/d/msgid/qubes-users/dcec0b0d-2f61-85c4-5d15-77071f89f00e%40danwin1210.me

I resolved the issue by going to the doc page suggested by xao in that
thread and on the first machine I used apt install to install all the
packages needed to be added to a minimal template to make sys-net and
sys-usb work (just to be clear, I confirm that I had the +full+ template:
but figured that if any of these were missing that would be relevant).

On the other machine,  installed the relevant packages to make sys-net work

On both machines apt told me that several of these packages were already
installed, but did install some packages on each machine. After that all
three sys-XXX VMs worked with the full templates.

My to do list includes an intention to try again with a new install to find
out if #5123 did indeed fix it.

The docs need to be updated either way, because an "old" Debian template,
even if updated, will not have acquired the relevant extra software. When I
know either way, I also plan to update the docs and, if need be, reopen
#5123, but no promises when that will reach the "next task" in my queue...

R~~

-- 
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/CAK3jUKqoDRRHZS7rCPM8TCy35J1%3DvqAg3-czNuZ_sGQZ4pwuyA%40mail.gmail.com.


[qubes-users] fedora template rpm refuses to go away?

2020-01-05 Thread River~~
Hi all,

Just did a new install of the shiny new R 4.0.2 (not the rc!).

((Judging by the date on some of the rpm packages some of the Qubes team
spent Christmas day building packages - a nice present to the community,
thank you and seasons greetings))

I saved all the VMs from rc3 to restore to the new system and so installed
with no extra software, no Debian no Whonix from anaconda. Later on the
first boot I selected the bottom checkbox to not configure anything.

During the install I noticed that anaconda spends quite a long time
installing the fedora template package (the progress bar stools for a
while). This is mildly irritating as I base everything on Debian, apart
from Dom0 of course, bit that does not use a template (or at least not
visibly so)

So, as expected, no fedora template shown in Qube manager. It's still
listed by

dnf list installed

Attempts to remove it with

dnf remove qubes-template-fedora-30

initially claim that one package will be removed (so no dependencies,
right?) saving 5G space. However it goes on to fail as the pre-uninstall
triggers fail. The error message appears twice.

If most of that package is not being used in my use case, it would be nice
to be able to save most of that 5G of space -- so my question is whether
all, most, a little, or none of the package is used by a Qubes system
that's not using fedora templates?

I'm wondering whether to raise an issue to request refactoring of the
template rpm into the parts needed only by the template as a template and
the parts needed by Dom0 or other parts of Qubes.

I'm also wondering if it's actually a bug in the pre un triggers, and they
are being over protective; in which case that's a different issue.

But before raising either as an issue I'd like to understand which (if any)
of these apply. So my questions are:

1. does Dom0 actually depend internally the fedora template somehow, even
though it is not using it as a template in the normal Qubes way?

2. And what approximate proportion of the software in that package is
unused when there is no fedora template?

Happy New Year to all the Qubes devs, and all the unofficial experts who
share their time on this list

R~~

-- 
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/CAK3jUKpOQfPjtgMo3X5HyTVVabtbF7Z-KU2iimpOrxYXNbD-QA%40mail.gmail.com.


Re: [qubes-users] Re: How do I attach a hard drive to a VM on boot?

2020-01-01 Thread River~~
On 16:36, Sun, 22 Dec 2019 <244clarendo...@gmail.com wrote:
>
>
>> The only remaining problem here might be that /dev/sda3 doesn't
>> reference the same drive on each dom0 boot process...
>>
>> So you'd have to write ... Alternatively  you could  ...
>
>
> Another option is to label the filesystem, say with
>
> tune2fs -L foo /dev/sda3
>
> Then, instead of the /dev/xxx entry in fstab, use LABEL=foo like this
>
>
> LABEL=foo   /mnt/tmpauto user,rw 0 0
>
> That way it will find the relevant partition, even if it moves around in
the partition table on the real disk, or if it appears on a different
virtual disk.(not yet tested on Qubes, but this is my normal way of making
fstab entries persist)

That success the problem of the disk moving around in the VM. It doesn't
solve the issue that it might be on a different unit in Dom0.

To get ground that, you might like to label the filesystem as before, and
refer to it in Dom0 as

/dev/disk/by-label/foo

Happy new year !

-- 
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/CAK3jUKr2Ks4WVsXwJLRZMWM8sEACAwnyVOY63haDReDgKqiawQ%40mail.gmail.com.


Re: [qubes-users] Re: Lenovo G505S Coreboot

2018-04-20 Thread River~~
correction where I said

>
> My assumption is that the time is explained by the fact that it is not
> only booting the physical machine but also the various CMs that are tagged
> to be started at bootup.
>

I meant VMs, not CMs

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAK3jUKoxR9ct5FE4U1UqsZsCWtNVBSw0aubo6wSTNZ2KFQcKEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Lenovo G505S Coreboot

2018-04-20 Thread River~~
 wrote:

> On Tuesday, April 10, 2018 at ...


 One question I have is regarding boot time for 4.0.  Is it several minutes
> long for you on coreboot/Qubes 4.0?


It is what I am seeing. Is this significantly longer than for Qubes 3.2? (I
am new here and  never used 3.2)

My assumption is that the time is explained by the fact that it is not only
booting the physical machine but also the various CMs that are tagged to be
started at bootup.

I also get a Failed to Load Kernel Modules message early on


Yes, I see this as the first line after the four Tuxes appear.

I think the message is slightly different - from memory it is

Failed to Start Load Kernel Modules



>

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAK3jUKorcGAefCFefr%2B4bvpgKqrwfZgEkoxByEzPxrYcVMXfCw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Cannot pass USB drive to Windows HVM

2018-04-18 Thread River~~
>
> @Qubes Team:
> Is this something that will be solved in the near future? [Reliable
> throughput from sys-USB to Win7 HVM ??]
>

Windows Support is very important to run corporate apps and also when you
> work in customer environments.
>
> Maybe opening asking for funding would motivate someone to look for a
> solution.
> 
>

I wonder how much funding would be involved?

My thought is that if Qubes devs could estimate time involved, then

Either

they could ask for crowdfunding to support that

Or

any other group of devs could do so - obvs they would have to post their
backgrounds with the proposal.

The standard crowdfunding where people pledge support but only pay when the
pledges meet the target seems ideal for this kind of project

R~~

>

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAK3jUKpZ8HUB0GXeR9okn-m4OyzKySqj%2BqVp4F_uSejU%3Di-jGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.