Re: [qubes-users] KERNEL PANIC on booting installation media - Acer TravelMate B116 - Details Inside

['awokd' via qubes-users]

Guest:

> I doubt that. The CPU has virtualization capabilities and I imagine that 
> these are the corresponding interrupts? The info is the same on the debian 
> installation.
> 
>> Try checking /proc/interrupts in a different distro too, like Mint maybe.
> 
> Done. Please check below.

Thanks. Hope I'm not leading you on a wild goose chase.

>  118:   1376  0  0 0   PCI-MSI 32768-edge  
> i915
>  119:  0  0 0  0  chv-gpio   81  80860F14:01 
> cd
>  120:  0  0 0  0  INT0002 Virtual GPIO2  
> ACPI:Event

 117:  27211  0  0  0   PCI-MSI 32768-edge
i915
 118:  0  0  0  0
hdmi_lpe_audio_irqchip -hdmi_lpe_audio_irq_handler  hdmi-lpe-audio
 119:  0  0  0  0  INT0002 Virtual GPIO
   2  ACPI:Event

That odd interrupt changed in Debian. I wonder if it is
https://www.spinics.net/lists/kernel/msg2709360.html. Link is to a
kernel issue that was occurring with i915 HDMI LPE on interrupt
initialization, so it is in a similar place as the Xen events_base.c
interrupt initialization we are seeing.

If there is no way to disable HDMI audio completely, perhaps try the
external monitor or blacklist suggestions in here:
https://github.com/QubesOS/qubes-issues/issues/5247.

-- 
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/28713bd5-2efa-fd16-a5f1-c350bf42c454%40danwin1210.me.

Re: [qubes-users] Re: slightly off-topic: self-resetting OS idea

[panina]

On 8/29/19 8:52 PM, scoobyscra...@gmail.com wrote:
> You may want to take a look at Fedora's Silverblue immutable desktop
> operating system.  I had problems installing the latest version but
> conceptually the OS in time will be a good alternative to Qubes which I
> use as my daily driver.

Flawless, I had forgotten about this. It seems to be exactly what I'm
after. Hope it can handle my hardware.
But if not, I'll just wait for it to mature.

> 
> -- 
> 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/80448924-78cc-42c4-9ec2-c21fbed1d181%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/cf823de5-853f-1f62-ae47-ce8f61b04354%40nonbinary.me.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] KERNEL PANIC on booting installation media - Acer TravelMate B116 - Details Inside

[Guest]

The below info was collected from a debian running on the B116-M. Have added 
/poc/cpuinfo for completeness (see below).

Thanks for your looking into this!

At 19:55 01/09/2019, 'awokd' via qubes-users wrote:
>'awokd' via qubes-users:
>> 'awokd' via qubes-users:
>> 
  HYP:  0  0  0  0   Hypervisor callback 
 interrupts
  HRE:  0  0  0  0   Hyper-V 
 reenlightenment interrupts
  HVS:  0  0  0  0   Hyper-V stimer0 
 interrupts
>>>
  PIN:  0  0  0  0   Posted-interrupt 
 notification event
>> 
>> Meant
>>  NPI:  0  0  0  0   Nested
>> posted-interrupt event
>> 
>> instead of PIN.
>> 
>>> These 4 make it look like you are running in a Hypervisor. Some security
>>> feature or malware?

I doubt that. The CPU has virtualization capabilities and I imagine that these 
are the corresponding interrupts? The info is the same on the debian 
installation.

>Try checking /proc/interrupts in a different distro too, like Mint maybe.

Done. Please check below.

---snip---
CPU0   CPU1   CPU2   CPU3   
   0:  8  0  0 0   IO-APIC2-edge  timer
   1:  0  0   1179  0   IO-APIC1-edge  i8042
   8:  0  0 0  0   IO-APIC8-edge  rtc0
   9:  0  0 0  0   IO-APIC9-fasteoi   acpi, 
INT0002
  12:  0   4154  0  0   IO-APIC   12-edge  i8042
  18:  0  0 0  0   IO-APIC   18-fasteoi   
i801_smbus
  32:  0  0 0  0   IO-APIC   32-fasteoi   
808622C1:00
  43:  0  0 0  0   IO-APIC   43-fasteoi   
dw:dmac-1
  45:  0 52  0  0   IO-APIC   45-fasteoi   mmc0
  47:  0  0 0  0   IO-APIC   47-fasteoi   mmc1
 115:  0  0722  0   PCI-MSI 327680-edge  
xhci_hcd
 116:  0  0 0  11738   PCI-MSI 311296-edge  
ahci[:00:13.0]
 117:  0 327153  0  0   PCI-MSI 1572864-edge  
enp3s0
 118:   1376  0  0 0   PCI-MSI 32768-edge  i915
 119:  0  0 0  0  chv-gpio   81  80860F14:01 cd
 120:  0  0 0  0  INT0002 Virtual GPIO2  
ACPI:Event
 121:  0  0 0  0   PCI-MSI 180224-edge  
proc_thermal
 122:381  0  0 0   PCI-MSI 442368-edge  
snd_hda_intel:card0
 NMI:  3  4  2  2   Non-maskable interrupts
 LOC:  28546  75431  12343  24582   Local timer interrupts
 SPU:  0  0 0  0   Spurious interrupts
 PMI:  3  4  2  2   Performance monitoring 
interrupts
 IWI:  0  0 0  0   IRQ work interrupts
 RTR:  0  0 0  0   APIC ICR read retries
 RES:   4352   4169   1980   1953   Rescheduling interrupts
 CAL:   3911   4248   2151   2040   Function call interrupts
 TLB: 25 16 37 33   TLB shootdowns
 TRM:  0  0 0  0   Thermal event interrupts
 THR:  0  0 0  0   Threshold APIC interrupts
 DFR:  0  0 0  0   Deferred Error APIC 
interrupts
 MCE:  0  0 0  0   Machine check exceptions
 MCP:  8  8 8  8   Machine check polls
 HYP:  0  0 0  0   Hypervisor callback 
interrupts
 HRE:  0  0 0  0   Hyper-V reenlightenment 
interrupts
 HVS:  0  0 0  0   Hyper-V stimer0 interrupts
 ERR:  0
 MIS:  0
 PIN:  0  0 0  0   Posted-interrupt 
notification event
 NPI:  0  0 0  0   Nested posted-interrupt event
 PIW:  0  0 0  0   Posted-interrupt wakeup event
00:00.0 Host bridge: Intel Corporation Atom/Celeron/Pentium Processor 
x5-E8000/J3xxx/N3xxx Series SoC Transaction Register (rev 21)
00:02.0 VGA compatible controller: Intel Corporation Atom/Celeron/Pentium 
Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller (rev 21)
00:0b.0 Signal processing controller: Intel Corporation Atom/Celeron/Pentium 
Processor x5-E8000/J3xxx/N3xxx Series Power Management Controller (rev 21)
00:13.0 SATA controller: Intel Corporation Atom/Celeron/Pentium Processor 
x5-E8000/J3xxx/N3xxx Series SATA Controller (rev 21)
00:14.0 USB controller: Intel Corporation Atom/Celeron/Pentium Processor 
x5-E8000/J3xxx/N3xxx 

[qubes-users] Re: Device showing up in Qubes sys-usb terminal but not devices icon, and attach error in dom0

[rec wins]

On 8/29/19 2:36 AM, Brendan Hoar wrote:
> On Thu, Aug 29, 2019 at 3:02 AM rec wins 
>  wrote:
> 
>>
>> OTP won't ,  if the key does  more than U2F  you may need to  get  a
>> configuration application for the key  and  make sure it's  U2F  only
>> slot 1  , 2  etc
>>
> 
> Yubikey OTP works through a keyboard-like HID, which are blacklisted by
> default in Qubes. In order to directly attach a keyboard-like device to a
> VM you have to override this setting.
> 
> See:
> https://www.qubes-os.org/doc/usb-qubes/#enable-a-usb-keyboard-for-login
> 
> B
> 


I could be wrong but I not sure you can use  1 key for both U2F and OTP
 , as I mentioned,  you may need to  use the  developers software to
disable one of them . If you disable everything but U2F

then follow the  Qubes Docs for U2F


sort of defeats the purpose of an onlykey I imagine,  I  myself  am
using a U2F only yubikey   , not OTP  gave up on that long time ago

-- 
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/489a753d-27eb-1635-4e93-79767bead459%40riseup.net.

Re: [qubes-users] 4.0.2

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/09/2019 9.29 AM, Steven Walker wrote:
> Is there any timeline for the release of 4.0.2 Final?
> 
> Steve
> 

This is a very appropriate question, since we mentioned in our 4.0.2-rc1
announcement that "If no major issues are discovered in 4.0.2-rc1, we
expect the stable release of 4.0.2 to follow in a few weeks." [1]
It's been more than a few weeks since then, so it's a good question.

Unfortunately, two major issues were discovered:

1. An update bug that affects Debian 10 and Whonix. [2] A fix for Debian
   is already available. The fix for Whonix is in development.

2. A pending security issue that the Qubes Security Team is currently
   addressing.

We don't currently have a timeline for how long it will take to address
these issues, but we're currently working on them and will provide an
update as soon as we know more.


[1] 
https://www.qubes-os.org/news/2019/07/09/qubes-4-0-2-rc1/#release-candidate-planning
[2] https://github.com/QubesOS/qubes-issues/issues/5149

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl1tV0kACgkQ203TvDlQ
MDDOuA/8Cp6BdmTcJusxPm3NLrt0MAwlLJbkf4gJkShM/QqsMklzEnnb+DKXM+EY
SaqZzaTsjRFvgMPsVu66CV0b/rfhumDfCNl1IKZrAgwZh+NeI+bL9g7P2/Ikz2DU
KL/7NJhQx6+QiNsZt+IKcfVggpGZAWE7IjUhq41nvkCdDqg4/C+2UbwSDH/yx8YT
trAt7AAZuY1R3Uwzo3K7BuwUuPfsuVIvm2ewBeVfYcj3ND6A1GkYOizyrBKzVTyN
VOg4FtQi+r4YGaCVYA5pyKRM/9IuSEXEu0DlitYwjKqa5R2/9N8yKHlhwLAxzPqR
Sbk0RZpizAz4nSdlCFy27yeHCFGelMIrDkbhhmxRCNUd2zSA3M1v2IgDz9NGXl2l
+wOS9BrrvW2cw6gJMpz8HFBJk3U0p2OLHhyMeFOgmvjDh/6X/fsmrYtBTZa15syx
QoTNqBHGzVK1R9bRzQjcqDwUY4gla8eBgmqM89g2xWpYZejgierIkM2r0pe9a7lN
ZjTKsOADBs6JdNRlGDZZvJQrJ6NtM7umo52lGrc712gXQVTB0Advfpe2x7CXvR1l
1T0X/FibspP434HOjnt+YaOZoypEade7MbWqXQXqagK+T8vALsYleWWHlUzLsRd8
65jnd9c90ZorKWtf5rSXg1J7Ldb0sPxhRzg7+gD9VKHZiUIb+t4=
=+MpM
-END PGP SIGNATURE-

-- 
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/efd3f324-607d-ee52-c647-fd4f98ef8dda%40qubes-os.org.

[qubes-users] Is any special action required when updating to qubes-core-agent-networking (4.0.47-1+deb10u1) in Whonix templates?

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When recently updating to qubes-core-agent-networking
(4.0.47-1+deb10u1) in whonix-gw-15 and whonix-ws-15, I noticed the
following output, which I don't recall ever seeing before:

```
Setting up qubes-core-agent-networking (4.0.47-1+deb10u1) ...
Installing new version of config file /etc/udev/rules.d/99-qubes-network.rules 
...
[qubes-core-agent-linux.conf:1] Line references path below legacy directory 
/var/run/, updating /var/run/tinyproxy-updates → /run/tinyproxy-updates; please 
update the tmpfiles.d/ drop-in file accordingly.
Warning: The unit file, source configuration file or drop-ins of 
qubes-network.service changed on disk. Run 'systemctl daemon-reload' to reload 
units.
```

I'm being instructed to do two things:

(1) "update the tmpfiles.d/ drop-in file accordingly"
(2) "Run 'systemctl daemon-reload' to reload units"

I had no idea what (1) meant, so I searched online and found that it
appears to be an upstream issue. [1][2] However, I still don't know
whether I, as a Qubes user, should take any action here. What, if
anything, should I do?

I also wasn't sure about (2). I knew I could simply execute that
command as instructed, but I'm not sure if I should. After searching
online, (2) appears to be a pretty general mechanism that also isn't
Qubes-specific. [3] In this case, I'm wondering whether simply
restarting the TemplateVM once is enough, or whether any further
action is required (or recommended) on my part here. Any thoughts?


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902413
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1658487
[3] https://unix.stackexchange.com/q/364782

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl1tUtYACgkQ203TvDlQ
MDCOzxAAqrjIybQmRsaCyOz28+xHcVGeO1vC2wv8854dqHM4BNgMAEzODqqdPc/v
zXaYqJyPrG9jTmERLDKBf+/YovcSfPfrMU7hMXK/OwIhVKymp0byKmO+EjQv74GU
SDrE+S0zbGjWYP5Na6RlXvEx8zHMShGdA2hMLDm2X3ZPEYE13N+KKe8RNUc2XLAf
iCaBMVuwdum18/bvX903huX7jZJ1i/wa7rvkVSJ9BMGeJpP+YMLtL22palANym+E
JUeGySX4mZLe7rZXiaiqkHC3jKun3eSpRqrKx2yB/ryLTIZo34oogMwVWJztHNSq
mXppcANUF9UdyCz2X7y6gZGNlX3QS+oQPobTQ0GgLd0R7K9uJhxHnDbDqU50C7vE
QHsSyoKKX0vUA8hOoeIUg1JUSgSeGAtxqbLC7D8eDcQIxv1JLsG7hzfqNWUzcik0
ARxA7aklJgc8wlg/zobN6Q8MZaN7scbHAol7dH8hY+8PjsACi7mzyybhIkbXGSkJ
kBOWNoLP7HJPK9RyVsgmuf6/RnJnTN/7HmLMJBw1GSXecgtSYLRfDeHPkQY+m63A
2t0qi1IFRRlpLeHTjMAsvhKs9GltFtLunH/VHOLUdWLQgCDWR/79nloBYx/5HbOJ
xafZKTZR6A46JsnlTCSZKVkNzff9+xllLSGazh+hUEaRX65+gd4=
=CtX7
-END PGP SIGNATURE-


-- 
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/5bfc9237-3066-f1ca-9b9b-dbb31784f457%40qubes-os.org.

Re: [qubes-users] Custom installation: "You must create a new filesystem"

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/09/2019 12.51 PM, Claudia wrote:
> I don't suppose it's possible to install Qubes in a Qubes VM?

Yes, Qubes OS can be installed inside of itself, with certain
limitations. (IIRC: must be an HVM, must contain only HVMs, and only
nested one level deep. But it's been a long time since I've done this.)

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl1tQQYACgkQ203TvDlQ
MDD7dRAAhG/7LS4k3YFaMaBBF2nTXslPakIiJfE/QeKotiuOZl76gLe+hcQ1xl7l
M5ck4fKp/5CK+EsDoJqe6IK9qkpBwNNyzZtFnY4nJ8q5iv44B2/SPFsQsZzSRZoP
CxO+OrNaVVxUcReczmwbg/Q+2QTKTSWhVQSggChnzFvGDf+FhNMa6ZSE4Vwuj78/
TwvDQnqy8RnURZQ29MTh+vKgICw/H6RQx3dWufLTyuquxnoWizGmYKABSv2dn4Lo
ShMrA/iXWq0GNBVcIYGyaQySGAik270ZgDC97ydCkTN1JHHUpBMMTXP1AQeed7jf
ndDd1culelLs2ISeG3a6Ub1EdLLP2zRMxJ0JVLZAlyUBiiPXFtTQL94lVQ62DKYB
jT/M8yODj7g4EVkhbk8ya1rrFRIw1L6mFsx7a2t/6fQDvWjclCChN2vDNWco3OvB
nXfoSmcj56LBX3+eKHVioc6JnG/93WKGXobqmU2Y6WHIQ8+muRW/lZzaDH9Lm39y
9v8CVkrBUjjH+8mgtkk642pE4q5IWXFD8KJL5Bm6741WhkQ9Hhmq5aIBrzUvUOZV
sZNaiVD6GDTNoUfV+Y7Pmx52Fy2Niq+4YQpRJD9B5zoiOdr9DvFTUit0DQE+ztcP
w30T1sFIpNfaRGMmy41WTiaFEIJE3frfElYMF4RGbG4gFGT+174=
=1f+A
-END PGP SIGNATURE-

-- 
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/1bda57e4-974c-f401-8567-83585140a1e3%40qubes-os.org.

[qubes-users] ANN: Qubes-VM-hardening V0.9.3 released

[Chris Laprise]

Description:


Qubes-VM-hardening

Leverage Qubes template non-persistence to fend off malware at VM 
startup: Lock-down, quarantine and check contents of /rw private storage 
that affect the execution environment.


   * Acts at VM startup before private volume /rw mounts
   * User: Protect /home desktop & shell startup executables
   * Root: Quarantine all /rw configs & scripts, with whitelisting
   * Customize the root or home configuration on each boot
   * Organize configurations with named tags
   * SHA256 hash checking against unwanted changes
   * Provides rescue shell on error or request
   * Works with template-based AppVMs

Version 0.9.3 extends protection to dev nodes and suid files in home, so 
upgrading is recommended.


The new configuration tag feature comes with several examples, including 
the 'ibrowse' tag which can remove everything except browser bookmarks 
whenever the VM starts. Applying these configuration tags to VMs is easy 
and can help keep the number of custom templates low.


Github link - https://github.com/tasket/Qubes-VM-hardening


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/119bc276-fc18-a4b6-be26-4ab33d9379b3%40posteo.net.

Re: [qubes-users] Custom installation: "You must create a new filesystem"

[Claudia]

Andrew David Wong:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/09/2019 8.03 AM, Claudia wrote:

Andrew David Wong:

On 31/08/2019 11.23 AM, Claudia wrote:

The "Custom Installation" doc gives instructions about how to
create a non-default dm-crypt partition, or other custom setup,
and install Qubes to it. But when I follow these instructions
on R4.0.1, and try to assign my dm-crypt device to "/", I get
a message something like

"You must create a new filesystem for the root filesystem."



That's odd. I don't remember getting a message like that when I
installed 4.0 this way

First, thanks for your reply!

BTW, the actual message is "You must create a new file system on
the root device." (I was going from memory.)

Okay, so I think I might have figured it out: The tutorial should
work for any filesystem other than btrfs, provided you check the
"Reformat" option. Upon closer examination, your tutorial covers
creation of dm-crypt and LVM containers, but not any filesystems.
The installer does create the actual filesystem, so that's why the
tutorial doesn't cause the message about creating a new filesystem.
It's just that btrfs isn't one of the options.

When there is an empty dm-crypt partition on the disk, under
"Unknown" category it shows up as "luks-" and asks for a
password. Once unlocked, all options are greyed out, including
Mountpoint, except Label and Reformat. When check Reformat, the
File System drop down is enabled, but btrfs is not an option. So at
this point I could use another filesystem, just not btrfs. The
"Encrypt" checkbox is also enabled and checked by default.

When I manually format that partition with btrfs, it shows up
under "Unknown" as "Encrypted (LUKS)" and asks for a password. Once
unlocked, it shows under "Unknown" as "btrfs" and all options are
greyed out except Mountpoint and Label. But when I enter "/" as
mountpoint I get that message. I would be fine with replacing the
filesystem in the container, but the "Reformat" box is unchecked
and greyed out.

Like I said, I thought I got around it somehow, but I don't
remember for sure. I might have given up and used the default
cryptsetup options.




Well, the Qubes installer is mostly just the upstream Fedora
installer, so you might want to file bug reports with them about
these issues.


I was afraid of that. I may try to look into it some more and
perhaps see if it's a reportable bug. But the more I'm looking at
it, I think they would call it a "feature" of this deranged
installer. (See below.) I really just want to get past it.




I remember running into this before, and I thought I
eventually got around it somehow after playing with it for an
hour or two. But I don't remember. I might have just ended up
using the default dm-crypt parameters.

Idea 1: LUKS allows you to change some, but not all,
parameters after installation. So you can change the iter-time,
for example, but not the key size, cipher, or hash size(?). Not
great, but might work for some situations.

Idea 2: In my case I want to use btrfs, so I'm thinking I can
create a small standard partition at the end of the disk,
install to that, then once installed, `btrfs device add` my
custom dm-crypt root partition and `btrfs device remove` the
original, and optionally delete the temporary partition and
grow the real one. I don't yet know what changes will have to
be made to the bootloader/dracut config, but I'm assuming the
UUID at the very least.

Aside from dm-crypt and btrfs, there are also plenty of
situations where someone might want to install to an existing
device or filesystem.

Some of this has been talked about in #2294, but it's not quite
the same thing.

So I guess this is mostly just a rant. But I was also wondering
1) Am I doing something wrong? Should I not be seeing this
message? Is it a bug?


Could be. As mentioned above, I don't remember seeing this when I
went through it myself.


2) Why isn't this addressed in the custom installation
tutorial? Why do we have a tutorial that cannot be followed?


I wrote this version of the tutorial because I couldn't find any
information about how to do this sort of thing on R4 anywhere. I
went through the trial-and-error and documented my findings for
the benefit of others (and my future self). But I'm certainly not
an expert in all the underlying technologies. It worked for me
when I wrote it, and no one else has contributed to it since
then. I'm honestly sorry to hear that it didn't work for you, but
I don't know why it didn't. I can simply remove it from the
documentation if it's no longer working.


Did you happen to do any testing with btrfs when you wrote the
tutorial? At this point I don't think the tutorial is faulty, I
think it just cannot be used with btrfs.



I'm afraid not. I don't have any experience with btrfs.


Like I said, though, bug #2294 talks about this very problem. So
I'm at least not imagining things. Although it doesn't mention the
exact error message (I could have sworn it 

Re: [qubes-users] Doc updates to NTP best practices

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/09/2019 4.33 AM, Martin Thygesen wrote:
> Is there a particular approval process required to augment the
> existing documentation structure.
> 
> I want to augment the existing Time update documentation with
> relevant details on using NTP correctly
> 
> Per https://www.qubes-os.org/doc/change-time-zone/
> 
> I want to update this documentation with the information located
> here https://github.com/QubesOS/qubes-issues/issues/
> 
> The how to on changing timezone is ok but it does not provide
> guidance on the intent behind the use of NTP and which VM to use
> for that purpose.
> 
> I'm capable of expanding this doc, but just want to make sure the
> devels' are ok with this strategy
> 
> - Martin
> 

Thank you for your willingness to contribute to the documentation!

General information about updating the docs is here:

https://www.qubes-os.org/doc/doc-guidelines/

To answer your specific question, if it's a relatively small PR, you
can simply submit the PR, and we'll hash it out in that PR. Worst
case, it gets closed rather than merged, but no big loss, since it was
relatively small.

On the other hand, if it would be a lot of work that you
(understandably) don't want going to waste, then it would better to
open an issue that describes your proposed documentation enhancement,
and we can hash it out there before you submit a PR.

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl1s5R8ACgkQ203TvDlQ
MDCzyg/8CR2D2Icj/4FRmyI5+9/43GvdjAlqUYsTiOKpu1KZLmBhITLfpXkmlU+S
GweO44QfRTq5oyHfyCyXEc91aTHNSyqJcRD/Vs8a6AeJW6tPByDVxx7ydXdfMwsv
X/OOWowSRMt/kV2xUx26LG5egRpJzrgktYpON6FMUHaKwGqhFssW74pi9tNaeRKH
zvOjiW8rOAtcjufMJR5dgK5dmQbKhivfB5VhprhA5qhS5RyK01bu+gAxmsGBZN4k
2gyhj5Tt5DqbwovwZ/gqyso4XSYXHg9oE0cZ+bdsfXauUBWnAIFR8WRniXm741iE
Nwt4pAa1niuCL380XO6KZTCg1D18fsRnU1TXmSifMVUQ5qdk54K0oRkFDPq3a42T
iiJZaU1DTMU7fY5oV7yRHGNhgZSxeo4U6OH2VUJBEHxmeMqBySX1zsDjfRwuPar1
HZFaAY2ql7JnF/m5Bl4AJktOngsrLNc94DIL7haaHjXACHXGXASukbeMBLoZsKUG
cKT2oSzfRjav9s0Hmz7zVJOkmYbVHtUM+z2JwTUeAJVHontaZ0bBTUkzB8yDh4s/
vxwBDJbA/MzV8vtxCcXGUV96Hd4gGj7vAGwgciuH/wMLc8vdQ21l9MRHvhJx+fCH
xR5sn34GNA2Ak7KUqiiz5hBUpKtprf6HqD9lzvjQWQ9lMQ+1lEY=
=m3bI
-END PGP SIGNATURE-

-- 
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/5bb318a4-529a-c8ae-c20d-9d1478aa2e7c%40qubes-os.org.

[qubes-users] Doc updates to NTP best practices

[Martin Thygesen]

Is there a particular approval process required to augment the existing 
documentation structure.

I want to augment the existing Time update documentation with relevant 
details on using NTP correctly

Per
https://www.qubes-os.org/doc/change-time-zone/

I want to update this documentation with the information located here
https://github.com/QubesOS/qubes-issues/issues/

The how to on changing timezone is ok but it does not provide guidance on 
the intent behind the use of NTP and which VM to use for that purpose.

I'm capable of expanding this doc, but just want to make sure the devels' 
are ok with this strategy

- Martin

-- 
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/ff35199f-0793-4a5e-8b57-dccae7eee83b%40googlegroups.com.