Build ISO from official uploaded packages?
Rusty Bird
Hash: SHA512
Hi,
Is there a way to build an up-to-date R4.0 installer ISO from the
latest pre-built official packages in current(-testing)?
I'd rather not rebuild all of them - just the few for which I have
extra patches.
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJbpLEoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfhowP/0uNWXJdcKlSNi18AgJVTJTD
sRdcrbVbazJwXV8nclrD/Es68XYili4ie6oyfoxwn7sxB1DTN7CXXo3fk9C30M4Y
EoGPAt3KdZ8Aen58JXRF9XPRrShiihDi41gttkpCXuYKYQLLqXrrCxd8chrbz1Wg
K7zJv1vDfgzZzo7xFInTWfQJhfdjhF4NihB+55PXb0DQcJEbsddm8LCC4kCDtaNh
fvY85Ks9XB0xxRvnaT4DLNDDmug2cX2Vdpmq3E8vUwz1qVaodCjzhcW/ofh9s/AF
18ZBttZjLmrOvnk/EV0mNqJOKotWevmIXKVr1TDxBiJHu/7NwJrZP3LvVVmDgD8K
KBILj5BcaWcxmAyeIi5Pc7fxyv7FIc8FjWFiZTb5AqEgUg69sf7K4NAB+J60iKY5
xVAMPGUf2uA3AmqMNAriHD/UD4duOFJ5mu2VIza9vFmawzgyueb6yMLK7WZFNpbV
rxNMZ3rXExCW5vhvhQqAS9GQLMaKNkKbzA0kOMWowlA2K+rJfJ0ctpmQOT7ysx8R
4Cibvn7AZvcz3KyA0unYVYbkj/2Btm5s3SCISpizmItLiXcA0/MlLFAFY7oAoz1i
Ms7I9WA4ksIh2qZTNXeazss6TOnnQ7yp6Ve67ZClHt55NTPhNVfF458T1FC8fBOa
AHsxEDKOCBVOzZ7OkFoc
=63bt
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Hash: SHA256
On Fri, Sep 21, 2018 at 08:51:52AM +0000, Rusty Bird wrote:
> Hi,
>
> Is there a way to build an up-to-date R4.0 installer ISO from the
> latest pre-built official packages in current(-testing)?
>
> I'd rather not rebuild all of them - just the few for which I have
> extra patches.
- clear COMPONENTS (for the build time at least)
- clear DISTS_VM (unless you want to use local template builds)
- set USE_QUBES_REPO_VERSION=4.0
- optionally set USE_QUBES_REPO_TESTING=1
- set INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks
(file is in qubes-src/installer-qubes-os/conf/, but it's in that path inside build chroot)
This will use current-testing repository. If you want "current", edit
travis-iso-full.ks.
As for COMPONENTS - you still need to download at least
installer-qubes-os and probably builder-rpm (but I'm not sure if still
needed). For that, you need to include them in COMPONENTS for `make
get-sources` call.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlukv8YACgkQ24/THMrX
1yxjdgf/b7xPYjiHq8IPwibzjzhKng/sxwzh+aHkNaPORzaFXPaTdQ0F59/5BomN
BcibWuYWoWjIWWP3QIm1/+r5DiHZRlkbFsqXWu6Q9gXhHTCXY8zFCkT6QGtA8A/W
2QmxMM8jNWYtu1mCPwVQODPS+YOFBAj19fwkcpgdzKFPE4SPLqee2cdgkbf+7lgl
Yrct5GMpVhw6E2qgJ3R1RorcqFERCT6Tlt4LbytfvKSUIYF+/01p4UtH1nVmmQ2B
E/fmJcW+XdKYSCHh138w3ipzC5yK/YqTvUagsy8zDisvfBF75HkCwh3rG4D11Rhp
SLPQ9tssQF0A+OwvLlRtuSfkfuaz1Q==
=QiT8
-----END PGP SIGNATURE-----
Rusty Bird
Hash: SHA512
Marek Marczykowski-Górecki:
> > Is there a way to build an up-to-date R4.0 installer ISO from the
> > latest pre-built official packages in current(-testing)?
> >
> > I'd rather not rebuild all of them - just the few for which I have
> > extra patches.
>
> Yes, and it's quite easy. In your builder.conf:
> - clear COMPONENTS (for the build time at least)
> - clear DISTS_VM (unless you want to use local template builds)
> - set USE_QUBES_REPO_VERSION=4.0
> - optionally set USE_QUBES_REPO_TESTING=1
> - set INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks
> (file is in qubes-src/installer-qubes-os/conf/, but it's in that path inside build chroot)
>
> This will use current-testing repository. If you want "current", edit
> travis-iso-full.ks.
>
> As for COMPONENTS - you still need to download at least
> installer-qubes-os and probably builder-rpm (but I'm not sure if still
> needed). For that, you need to include them in COMPONENTS for `make
> get-sources` call.
inserted
COMPONENTS =
DISTS_VM =
USE_QUBES_REPO_VERSION = 4.0
USE_QUBES_REPO_TESTING = 1
INSTALLER_KICKSTART = /tmp/qubes-installer/conf/travis-iso-full.ks
after the big COMPONENTS block, ran
$ make COMPONENTS=installer-qubes-os get-sources
and then
$ make COMPONENTS=builder-rpm get-sources
$ make COMPONENTS=intel-microcode get-sources qubes
because builder complained that I need to build at least one fc25
package to prepare the chroot. (Is there a way to do that without
building a package?) Now, if I run
$ make iso
it fails with:
-> Installing installer-qubes-os build dependencies in fc25 environment
chroot: failed to run command ‘yum’: No such file or directory
make: *** [Makefile:519: iso] Error 1
I tried
$ make COMPONENTS=linux-yum get-sources qubes
but it didn't help. Looks like I'm missing some step?
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJbpNqBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfJZ8P/A+g8eViQv7Gz39nzRDjYA6c
e9YpuAiRqYX1H1y+bjyfbFzH2qt4TjHxFToACbZrQ1k0fcOTa0Bj4Kb3r6w86LJI
Rh8+GkOlKq7XxJeootTAn16S434SzjZCKeeIvn5FjxLHSeIOw/pQ5WVk8qW37oDi
fh99LI6FEXLvWsckzCwJCNbuFmEPMiyvtf0fKcjVKnm0UERQ7QNBe1TzqWDG6Ii3
eRua30dm1G7x9tqDmzAMmbgE4DAaOe2wFCosFpcdwHqhb9w+Y2j0Al33ppDge+Dg
8Mk5bFO2xF/pH+OxAEjpf+Uz06ORll+tjXdKKUSKfDDtYS+VuhZgryZtz0/sRGip
NLINsJt6aOJ0VHKIEY2pBkUnaiinI5GMhPm8NxAuWQ5cznuMuq6GTj8DAFH7nqGo
gUc78pvDeZCgIvCPuILkBJS5HuquGU2Q4n7Ga8hyT3kwyJtzF009CuJe7WpGah/8
nCJFpvPZvsm1b5ouNdIqyDb++HB2nRTfCRS9CT5gRyBE2RP+fmYr3Hgv6myL1r2P
MZc2sBVfI36AfqBEv4acKZJ4eXeoTbXaPQ8iaNAtcC/NZoKzh74SLwwo3etjhasQ
nT6RYDDDHsCy2XDwMJtH2dRr8HUgz9eyMNIoYEzw4FwbPl9aXTlP9AFKzHHeibFd
RGdxATKGmpdV+mUZQBsR
=4nYj
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Hash: SHA256
sudo chroot chroot-fc25 dnf install dnf-yum
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1ywOjQf9EpiFDI3tLPMe/9xpfJh+N3eCacxt5q7Ryo4PfPvU5banMELye1hhUJKu
m4JSTuFGpbF3BF2niON3rAiFE9TfNZTKOqOYVnJoCTuDd8V4+9urHXdPovbxFVhp
jVE0+iRapIEvPlXur9LB3a1xCv9YDruPAb2vCsVjZpH2BBaf7doooM5jdwh/Cjyv
xBaBbmHYOO9XxhEu9D0hilIVX3pFaqCF9cKkcSDy02hZWWFpOtp1pNiPsf3rIvrj
/PfhDro7GtDM9FNrUqOJhSjeoGjibjp7PrLczujkLca858mtpMA4xg9Ity52IG4t
5p9YAKtSepGtDzeVvezUtXDrdW91LQ==
=fpll
-----END PGP SIGNATURE-----
Rusty Bird
Hash: SHA512
Marek Marczykowski-Górecki:
> On Fri, Sep 21, 2018 at 11:48:17AM +0000, Rusty Bird wrote:
> > Now, if I run
> >
> > $ make iso
> >
> > it fails with:
> >
> > -> Installing installer-qubes-os build dependencies in fc25 environment
> > chroot: failed to run command ‘yum’: No such file or directory
> > make: *** [Makefile:519: iso] Error 1
>
> sudo chroot chroot-fc25 dnf install dnf-yum
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJbpVQsXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfjZEP/jPxy6nsSmC6Y8cJoOaWfwYl
xNtAensAbI+0um6pMPlmvJc1q5zDY9AgZGo8kWAzEUMA88CvJyC1xuW23zZtxlwu
13H2dyRALmxFda73s23IKhutxadARYTPv60GyJnXd9DUHM/ppXkiyMlZjcpq0jNo
pR3bqEQpM8D1L8AugjVmHmO7LkZQ892WoSswYJDVC0jvHIydaIYzNhkx83IpbQ8o
MnDHI6mlDzUm7C+UQCN7uX8DbrQZA+UpYJkzXBFVTGM/nhzVR7k44m1V6NbFMLI1
MaX+37EarkQCHGtCJZXGxlqGk9RZQMjmRxqUROW8mKvAOlDWvPXY0lHzspCblA4A
zJHfSmYlyRnK3GApeBtwrROA5btzf1oWiOci3TT2VFctEz1KjlV3lua/8/b13RX+
fqa49Fyr2f8uiJvmZEnaEz84SLjJwomclBRPblnW33HKAZM0v6V8LAyAgImESmut
g/TY4fGh8hVrSuOahvoXk61FGXYTrMeo7qKFGnVaUAbFKUfF9bbbATRSiDtO7QPx
/x8hVe4cST6EQ/3kp4LNmOY85czkJlTnPqJoSWbucvB5k2dRdiDCT8n5j2FsmjE7
xJfZYJEM3eItZXO/1Orme4sczb/TrlYji1U1MjbuhilN7TlNhubXZtlE92g5o1GM
uD2dZrjHVlXOD1yweUOY
=0WqO
-----END PGP SIGNATURE-----
Marcus Linsner
I'd be very interested into building(and testing) an iso with all of this:
"Rusty Bird have done excellent work and contributed file-reflink storage
driver[20], making use of copy-on-write feature of btrfs, instead of
building device-mapper layer on plain files.
- From now on (including Qubes OS 4.0.1) if you choose btrfs partitioning
layout, by default file-reflink driver will be used. Existing
storage pools are not affected by this change. "
^ from: https://groups.google.com/d/msg/qubes-devel/MakHbJKbfwk/1PMvmjf3CQAJ
I wonder if that means what I think it means: no more lvm/thin pools and instead only btrfs? That'd be crazy good :D (tbh, I'm not even sure if it makes sense)
Rusty Bird
Hash: SHA512
> based on a fedora-28 template for example.
$ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-developers-keys.asc
$ git clone https://github.com/QubesOS/qubes-builder.git
$ cd qubes-builder
$ git verify-commit HEAD || echo DANGER DANGER HIGH VOLTAGE
$ cp example-configs/qubes-os-r4.0.conf builder.conf
$ variables='DISTS_VM= USE_QUBES_REPO_VERSION=4.0 USE_QUBES_REPO_TESTING=1 INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks'
$ make $variables COMPONENTS='installer-qubes-os builder-rpm' get-sources
$ make $variables COMPONENTS=intel-microcode get-sources qubes clean-rpms
$ sudo chroot chroot-fc25 dnf -y install dnf-yum
$ make $variables COMPONENTS= iso
If any step fails due to a download error, just rerun it. Unless I
made a mistake putting everything together (in which case, please say
so), it should spit out an installer image file in the iso/ directory.
> I'd be very interested into building(and testing) an iso with all of this:
> "Rusty Bird have done excellent work and contributed file-reflink storage
> driver[20], making use of copy-on-write feature of btrfs, instead of
> building device-mapper layer on plain files.
> - From now on (including Qubes OS 4.0.1) if you choose btrfs partitioning
> layout, by default file-reflink driver will be used. Existing
> storage pools are not affected by this change. "
> ^ from: https://groups.google.com/d/msg/qubes-devel/MakHbJKbfwk/1PMvmjf3CQAJ
>
> I wonder if that means what I think it means: no more lvm/thin pools
> and instead only btrfs? That'd be crazy good :D (tbh, I'm not even
> sure if it makes sense)
layout in your shiny new installer:
- On the "Installation Destination" screen, select "I will configure
partitioning." and press "Done".
- Enter and confirm your desired passphrase.
- Switch the drop-down menu from "LVM Thin Provisioning" to "Btrfs".
- Press "Click here to create them automatically." and "Done".
- Confirm your passphrase again for some reason.
- Accept the inscrutable "Summary of Changes".
This assumes that the destination hard drive is completely empty. If
not, try the "I would like to make additonal space available" option
on the "Installation Destination" screen.
Let me know if everything works. You'd probably be the second regular
user of the file-reflink driver in this particular universe.
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJbprgDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfGPoQAI8KG/sPJQSy2vvFi4p33Pxv
qQQ4uTKC6nQCdqFKBDJkv1AWvATVr6WxE4s2NyU10tfAJ3lS/v/xFtZ5wM6LyrT0
6N5aq932HDmBV4qwa18y2mOXxFuzrUEYJuEgObBhMQC1D6We/gIBgyRLYZ85ekpn
R0Zgst+haFyU5qI9KEEYrvLl+MzaNAJcGY3NyLetkKbqaW5e7eUhJTo59pN1HMHs
4MXAEMy6NInoDETK31UKavbMzRNA0kx6h9KPE8kLwEwhJtOiCJBFRmFDwvuAp3yL
GlTPct3MWFRB7g63VMXel2/YxFhUeZlWXd9M0bA7quBdJq79c/pDvwujZONHtw6Z
sbDDLpuataPevTn+j9+RkGTaDXdnpS+vd9oopiJEywbvk8bWvDP/MIESwVLedmMx
T17Qu+OjvUV+pkQre3KRTO7L2eDvUdfGp7Bm2iIwdiwK+ymbBFfBprXAGxv3ojHs
nXinNwAy1FJp/wfifB4IQ4E/UGZxOSVHSe+sgZjf8l/ctRhxGT7e8vnKsGML8W/0
ewHOYmfq/rRJChVi5cX7AhldAQlrZMzdlrxiAe57Dl8DrEj0R6h6Q3paLD5/ewiJ
GQ4rttSWoZlhl+6Gvrwgp0aTzQ4m19xAbxgdKM5/sljka2x7JcPoBlGE4ygP60yI
8DaX8A4yfu7q32IyCNOS
=VsyN
-----END PGP SIGNATURE-----
Marcus Linsner
> $ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-developers-keys.asc
> $ git clone https://github.com/QubesOS/qubes-builder.git
> $ cd qubes-builder
> $ git verify-commit HEAD || echo DANGER DANGER HIGH VOLTAGE
> $ cp example-configs/qubes-os-r4.0.conf builder.conf
> $ variables='DISTS_VM= USE_QUBES_REPO_VERSION=4.0 USE_QUBES_REPO_TESTING=1 INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks'
> $ make $variables COMPONENTS='installer-qubes-os builder-rpm' get-sources
> $ make $variables COMPONENTS=intel-microcode get-sources qubes clean-rpms
> $ sudo chroot chroot-fc25 dnf -y install dnf-yum
> $ make $variables COMPONENTS= iso
>
> If any step fails due to a download error, just rerun it. Unless I
> made a mistake putting everything together (in which case, please say
> so), it should spit out an installer image file in the iso/ directory.
>
This is amazing! Thanks so much!
I can't wait to run this in production. (ie. as my main system) So cool!
I got an error at this step: `time make $variables COMPONENTS= iso`
Took me a long time to figure out it was because `audit=0` was present in kernelopts.
...
Complete!
-> Building installer-qubes-os iso for fc25 (logfile: build-logs/installer-qubes-os-iso-fc25.log)...
--> build failed!
return execWithRedirect(cmd[0], cmd[1:], **kwargs)
File "/usr/lib/python3.5/site-packages/pylorax/executils.py", line 228, in execWithRedirect
env_add=env_add, reset_handlers=reset_handlers, reset_lang=reset_lang)[0]
File "/usr/lib/python3.5/site-packages/pylorax/executils.py", line 201, in _run_program
raise subprocess.CalledProcessError(proc.returncode, argv, output)
subprocess.CalledProcessError: Command '['setfiles', '-e', '/proc', '-e', '/sys', '-e', '/dev', '-e', '/install', '/etc/selinux/targeted/contexts/files/file_contexts', '/']' returned non-zero exit status 255
Makefile:58: recipe for target 'iso-installer' failed
make[1]: *** [iso-installer] Error 1
make[1]: Leaving directory '/home/user/qubes-src/installer-qubes-os'
make: *** [Makefile:519: iso] Error 1
real 12m31.230s
user 4m20.275s
sys 0m51.076s
In `build-logs/installer-qubes-os-iso-fc25.log` it shows:
...
2018-09-23 06:15:41,475: verifying the installroot
verifying the installroot
2018-09-23 06:15:43,721: creating the runtime image
creating the runtime image
Traceback (most recent call last):
File "/usr/sbin/lorax", line 283, in <module>
main()
File "/usr/sbin/lorax", line 133, in main
remove_temp=True, verify=opts.verify)
File "/usr/lib/python3.5/site-packages/pylorax/__init__.py", line 327, in run
size=size)
File "/usr/lib/python3.5/site-packages/pylorax/treebuilder.py", line 197, in create_runtime
"Anaconda", size=size)
File "/usr/lib/python3.5/site-packages/pylorax/imgutils.py", line 120, in mkrootfsimg
runcmd(cmd, root=root)
File "/usr/lib/python3.5/site-packages/pylorax/executils.py", line 341, in runcmd
return execWithRedirect(cmd[0], cmd[1:], **kwargs)
File "/usr/lib/python3.5/site-packages/pylorax/executils.py", line 228, in execWithRedirect
env_add=env_add, reset_handlers=reset_handlers, reset_lang=reset_lang)[0]
File "/usr/lib/python3.5/site-packages/pylorax/executils.py", line 201, in _run_program
raise subprocess.CalledProcessError(proc.returncode, argv, output)
subprocess.CalledProcessError: Command '['setfiles', '-e', '/proc', '-e', '/sys', '-e', '/dev', '-e', '/install', '/etc/selinux/targeted/contexts/files/file_contexts', '/']' returned non-zero exit status 255
Makefile:58: recipe for target 'iso-installer' failed
make[1]: *** [iso-installer] Error 1
make[1]: Leaving directory '/home/user/qubes-src/installer-qubes-os'
Here's the space usage in /rw:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvdb 20140648 10474736 9649528 53% /rw
This qube has:
Initial memory: 1400 MB
Max memory: 4000 MB
VCPUs no.: 2
[v] Include in memory balancing
Kernel: 4.18.9-1 (from [1])
[ctor@dom0 ~]$ qvm-prefs --get dev02 kernelopts
nopat sysrq_always_enabled audit=0 ipv6.disable=1 rd.luks.options=discard root_trim=yes rd.luks.allow-discards loglevel=15 log_buf_len=16M printk.always_kmsg_dump=y printk.time=y printk.devkmsg=on mminit_loglevel=0 memory_corruption_check=1 pax_sanitize_slab=full systemd.log_target=kmsg systemd.journald.forward_to_console=1 udev.children-max=1256 rd.udev.children-max=1256
it has no swap(disabled in kernel) and this isn't otherwise a clean fedora-28 template (I don't even remember what else I've changed in /etc and packages installed)
So either of these doesn't cause the above `setfiles` error:
[ctor@dom0 ~]$ qvm-prefs --get dev02 kernelopts
nopat
[ctor@dom0 ~]$ qvm-prefs --get dev02 kernelopts
nopat rd.luks.options=discard root_trim=yes rd.luks.allow-discards loglevel=15 log_buf_len=16M printk.always_kmsg_dump=y printk.time=y printk.devkmsg=on mminit_loglevel=0 memory_corruption_check=1
[ctor@dom0 ~]$ qvm-prefs --get dev02 kernelopts
nopat sysrq_always_enabled ipv6.disable=1 rd.luks.options=discard root_trim=yes rd.luks.allow-discards loglevel=15 log_buf_len=16M printk.always_kmsg_dump=y printk.time=y printk.devkmsg=on mminit_loglevel=0 memory_corruption_check=1 pax_sanitize_slab=full systemd.log_target=kmsg systemd.journald.forward_to_console=1 udev.children-max=1256 rd.udev.children-max=1256
But either of these do cause that `setfiles` error:
[ctor@dom0 ~]$ qvm-prefs --get dev02 kernelopts
nopat audit=0
[ctor@dom0 ~]$ qvm-prefs --get dev02 kernelopts
nopat sysrq_always_enabled audit=0 ipv6.disable=1 rd.luks.options=discard root_trim=yes rd.luks.allow-discards loglevel=15 log_buf_len=16M printk.always_kmsg_dump=y printk.time=y printk.devkmsg=on mminit_loglevel=0 memory_corruption_check=1 pax_sanitize_slab=full systemd.log_target=kmsg systemd.journald.forward_to_console=1 udev.children-max=1256 rd.udev.children-max=1256
Conclusion: audit is necessary(for whatever reason, who wants to guess?) so I've to make sure audit=0 doesn't exist in /proc/cmdline :)
Can I maybe still use audit=0 ? ie. another way to fix the above error? because I don't want to see the audit spam on dmesg (mainly due to journal being sync-ed to disk, seemingly every time).
So disk space required is about 12.5G, unless you rerun the `iso` command after success, then it could go as high as 17.2G or even more for subsequent runs. Not sure what to clean so it doesn't re-download everything again (like 393+1069 packages).
(Note: I've also changed max memory to 14000 MB, after the first time I got the `setfiles` error)
I don't suppose there's some way to cache all downloaded rpms in some intermediate qube, or is there? (sort of like sys-firewall is doing for dom0) but I mean strictly for these iso building steps, so it would work even after a clean-chroot or rm -rf qubes-builder.
For now I'm just copying the ./chroot-fc25/var/cache/ dir (it's 5.3G according to `du`).
The mirror is ukfast and found within these 2 files(which are identical):
./qubes-src/installer-qubes-os/conf/travis-iso-full.ks
./chroot-fc25/home/user/qubes-src/installer-qubes-os/conf/travis-iso-full.ks
Is there another mirror that can be chosen? (sometimes it's limited to max 2MBit/sec and it takes like 4G of downloads after a `make clean-chroot`)
Is there some way to avoid downloading some templates like whonix(which I don't plan on using ever) ?
More questions :)
Why is this nonexistent file used:
/tmp/qubes-installer/conf/travis-iso-full.ks
instead of any of these existing ones:
./qubes-src/installer-qubes-os/conf/travis-iso-full.ks
./chroot-fc25/home/user/qubes-src/installer-qubes-os/conf/travis-iso-full.ks
context:
/bin/sh: line 1: 1370 Killed pungi --name=Qubes --nosource --nodebuginfo --nogreedy --all-stages --ver="20180923" -c /tmp/qubes-installer/conf/travis-iso-full.ks
and
$ variables='DISTS_VM= USE_QUBES_REPO_VERSION=4.0 USE_QUBES_REPO_TESTING=1 INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks'
(I used `find` and it's nonexistent in chroot either, or in real /tmp)
Another question:
if I have my own kernel[1], do I compile it after this step `$ make $variables COMPONENTS=intel-microcode get-sources qubes clean-rpms` ?
and then I execute `$ make $variables COMPONENTS= iso` ? or do I somehow meld it into this `iso` step maybe like `time make $variables linux-kernel iso` ?
I'm compiling kernel by [2] and then [3] and the .conf is [4]
As an aside, Rusty Bird, do you know Rust (language) ? 'cause that'd be cool :)
[1] https://github.com/constantoverride/qubes-linux-kernel/tree/devel-4.18
[2] https://github.com/constantoverride/qubes-builder/blob/master_mod/build-init
[3] https://github.com/constantoverride/qubes-builder/blob/cd1b0c3e7425e0d7acf1bbde2c5a17960fffa2a8/build-restart#L1
[4] https://github.com/constantoverride/qubes-builder/blob/cd1b0c3e7425e0d7acf1bbde2c5a17960fffa2a8/kernel_builder.conf#L158
Marek Marczykowski-Górecki
Hash: SHA256
On Sun, Sep 23, 2018 at 07:10:02AM -0700, Marcus Linsner wrote:
> On Saturday, September 22, 2018 at 11:55:48 PM UTC+2, Rusty Bird wrote:
> > $ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-developers-keys.asc
> > $ git clone https://github.com/QubesOS/qubes-builder.git
> > $ cd qubes-builder
> > $ git verify-commit HEAD || echo DANGER DANGER HIGH VOLTAGE
> > $ cp example-configs/qubes-os-r4.0.conf builder.conf
> > $ variables='DISTS_VM= USE_QUBES_REPO_VERSION=4.0 USE_QUBES_REPO_TESTING=1 INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks'
> > $ make $variables COMPONENTS='installer-qubes-os builder-rpm' get-sources
> > $ make $variables COMPONENTS=intel-microcode get-sources qubes clean-rpms
> > $ sudo chroot chroot-fc25 dnf -y install dnf-yum
> > $ make $variables COMPONENTS= iso
> >
> > If any step fails due to a download error, just rerun it. Unless I
> > made a mistake putting everything together (in which case, please say
> > so), it should spit out an installer image file in the iso/ directory.
> >
>
> This is amazing! Thanks so much!
>
> I can't wait to run this in production. (ie. as my main system) So cool!
>
>
> I got an error at this step: `time make $variables COMPONENTS= iso`
> Took me a long time to figure out it was because `audit=0` was present in kernelopts.
> subprocess.CalledProcessError: Command '['setfiles', '-e', '/proc', '-e', '/sys', '-e', '/dev', '-e', '/install', '/etc/selinux/targeted/contexts/files/file_contexts', '/']' returned non-zero exit status 255
> Conclusion: audit is necessary(for whatever reason, who wants to guess?) so I've to make sure audit=0 doesn't exist in /proc/cmdline :)
cmdline change anything in the build process...
> Can I maybe still use audit=0 ? ie. another way to fix the above error? because I don't want to see the audit spam on dmesg (mainly due to journal being sync-ed to disk, seemingly every time).
>
> So disk space required is about 12.5G, unless you rerun the `iso` command after success, then it could go as high as 17.2G or even more for subsequent runs. Not sure what to clean so it doesn't re-download everything again (like 393+1069 packages).
Most of the cache is in chroot-fc25/var/cache/pungi.
> (Note: I've also changed max memory to 14000 MB, after the first time I got the `setfiles` error)
>
> I don't suppose there's some way to cache all downloaded rpms in some intermediate qube, or is there? (sort of like sys-firewall is doing for dom0) but I mean strictly for these iso building steps, so it would work even after a clean-chroot or rm -rf qubes-builder.
> For now I'm just copying the ./chroot-fc25/var/cache/ dir (it's 5.3G according to `du`).
>
> The mirror is ukfast and found within these 2 files(which are identical):
> ./qubes-src/installer-qubes-os/conf/travis-iso-full.ks
> ./chroot-fc25/home/user/qubes-src/installer-qubes-os/conf/travis-iso-full.ks
> Is there another mirror that can be chosen? (sometimes it's limited to max 2MBit/sec and it takes like 4G of downloads after a `make clean-chroot`)
https://www.qubes-os.org/downloads/#mirrors
This one is there because it works good in travis build env.
> Is there some way to avoid downloading some templates like whonix(which I don't plan on using ever) ?
@whonix. But it may cause build or installation to fail.
> More questions :)
>
> Why is this nonexistent file used:
> /tmp/qubes-installer/conf/travis-iso-full.ks
> instead of any of these existing ones:
> ./qubes-src/installer-qubes-os/conf/travis-iso-full.ks
> ./chroot-fc25/home/user/qubes-src/installer-qubes-os/conf/travis-iso-full.ks
>
> context:
> /bin/sh: line 1: 1370 Killed pungi --name=Qubes --nosource --nodebuginfo --nogreedy --all-stages --ver="20180923" -c /tmp/qubes-installer/conf/travis-iso-full.ks
>
> and
> $ variables='DISTS_VM= USE_QUBES_REPO_VERSION=4.0 USE_QUBES_REPO_TESTING=1 INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks'
>
> (I used `find` and it's nonexistent in chroot either, or in real /tmp)
/home/user/qubes-src/installer-qubes-os/conf/travis-iso-full.ks, if you
look at it from outside it probably will look like a broken link,
because the path is different from the outside.
But you can use
/home/user/qubes-src/installer-qubes-os/conf/travis-iso-full.ks path
directly.
> Another question:
> if I have my own kernel[1], do I compile it after this step `$ make $variables COMPONENTS=intel-microcode get-sources qubes clean-rpms` ?
> and then I execute `$ make $variables COMPONENTS= iso` ? or do I somehow meld it into this `iso` step maybe like `time make $variables linux-kernel iso` ?
include that package on the image. You may also need to either adjust
qubes-src/installer-qubes-os/conf/comps-qubes.xml (kernel ->
kernel-latest), or build the package as "kernel" not "kernel-latest"
(edit "suffix" file in the linux-kernel sources).
> I'm compiling kernel by [2] and then [3] and the .conf is [4]
Better include your key in keyrings/git, like this:
gpg2 --homedir keyrings/git --import path/to/the/key.asc
gpg2 --homedir keyrings/git --edit (KEY ID)
(set owner trust to ultimate)
> [1] https://github.com/constantoverride/qubes-linux-kernel/tree/devel-4.18
> [2] https://github.com/constantoverride/qubes-builder/blob/master_mod/build-init
> [3] https://github.com/constantoverride/qubes-builder/blob/cd1b0c3e7425e0d7acf1bbde2c5a17960fffa2a8/build-restart#L1
> [4] https://github.com/constantoverride/qubes-builder/blob/cd1b0c3e7425e0d7acf1bbde2c5a17960fffa2a8/kernel_builder.conf#L158
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1yyncAgAkol9ZGbzOe0kyaT8DgSQF2JGFT8D7YPKnIlfb/SRwX2qYCvJ34wjd0US
9YDHXfkM2Y953rsI5J1rf1xld48h0xxrPwCmQHldOyIoEGV3Y1TJpHtiEqDNxxQf
1f9JX54X+PY6CIM4NoIRAtQhs1qV0YDjqovXnsGdNW8PC/6HpM6LpY/6p31BCWFm
Q3kRvGepUoS5m0ww5gXxGytgVOgjMkP+IzghKYvhOMlw9is0ub1ZFdSNNNEuqqZp
GRj9HjsQQyPqvb9kq+jVGWuZmONNwboqpKeBn4SaNE/WEPMQRKJ4a+T7aQ5y1+8C
vS2CSOaF9lrVOMZriB5jsWp+wzNYPw==
=rhWg
-----END PGP SIGNATURE-----
Rusty Bird
Hash: SHA512
Marcus Linsner:
> error? because I don't want to see the audit spam on dmesg (mainly
> due to journal being sync-ed to disk, seemingly every time).
CRIT/ALERT/EMERG priority), according to the journald.conf manpage:
| SyncIntervalSec=
| The timeout before synchronizing journal files to disk. After
| syncing, journal files are placed in the OFFLINE state. Note that
| syncing is unconditionally done immediately after a log message of
| priority CRIT, ALERT or EMERG has been logged. This setting hence
| applies only to messages of the levels ERR, WARNING, NOTICE, INFO,
| DEBUG. The default timeout is 5 minutes.
If it does, might be worth filing a systemd bug.
Oh, good, Marek has already answered your other qubes-builder
questions much better than I could.
> As an aside, Rusty Bird, do you know Rust (language) ?
so elegant. But no, still waiting for the right occasion I guess.
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJbqMyRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfk2YQAJA5ILNeFvb6V+nQhI+oMU37
5WQCHZdQJyOmHWyybepLS46ldjBu/yDx99A7jwnjY0cks3qO74FJ175fivcT60vb
RRU14Q5nzOx5+TPWYotqDFS2x3SVuVz/omT10mNyltK0IVTgZSBe7ZO1KBu2JnB9
wsKyPMtUgbCym9KThnoNfUyjPla13ZQwogLiTlfZGqx3FAJ4buw4zDrpEIU3rMgs
S0BK9QCB6QXahd8OeP1d7+43jVguUN5rFsEYsm/sbKYCYmEjriDrXfVow/uNCEx1
1SOxQ36xuf9IwquKJGEzKAUhh4MCVoLsk8qvIO3ttRsae0ESPr2r4YrHzoE6x2lT
3mG7vYM18LdZw0bqkwfJfzsaL6vzhr9oTeCJh4JvLPGCxtJO8E4zfqp9qIMWk5nV
ErRy8iqyl1QK9saaP3bwhJPjjepugjsXo04opbeBSJFpVBLl/egZ+eBLjs5g3rLz
Jx0V/zyj+Xh0LD0imCWiFfbh9WfRXd9FcaaGRUypeNARvXBZVdX09vQSG3Izi6UT
Gmn54lvBu7PtnVVcfEYr5tg0L/KcARgFQcmHYalvScWCEHYdul8KAwmWfA9Stzne
C2YwzH/R6jq7knOjOGAB8JDS8jVXluy9qVHarlSkK3p/eGv3Ku208VNgS7yTMH/o
53ybS2i8WmgVIvsz8ofY
=xPj2
-----END PGP SIGNATURE-----
Marcus Linsner
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Marcus Linsner:
> > Can I maybe still use audit=0 ? ie. another way to fix the above
> > error? because I don't want to see the audit spam on dmesg (mainly
> > due to journal being sync-ed to disk, seemingly every time).
>
> That audit spam shouldn't trigger a disk sync (because it doesn't have
> CRIT/ALERT/EMERG priority), according to the journald.conf manpage:
>
> | SyncIntervalSec=
> | The timeout before synchronizing journal files to disk. After
> | syncing, journal files are placed in the OFFLINE state. Note that
> | syncing is unconditionally done immediately after a log message of
> | priority CRIT, ALERT or EMERG has been logged. This setting hence
> | applies only to messages of the levels ERR, WARNING, NOTICE, INFO,
> | DEBUG. The default timeout is 5 minutes.
>
> If it does, might be worth filing a systemd bug.
Maybe it's a dom0 feature? patch added by qubes? (i doubt it but hey)
It doesn't seem to happen in a Fedora 28 VM, but on dom0 (Fedora 25), I can dupe it with these steps:
1. in a terminal: dmesg --raw -w
2. in another terminal: sudo iotop
3. in a 3rd terminal: logger
every time you press Enter in [3.] you see systemd-journald making a write in [2.] (and you see the loglevel 5 message on [1.], except in Fedora 28 but may be my systemd .conf settings(see below)) (in [2.] "Actual DISK WRITE" is like 15KB)
Practically when audit=0 doesn't exist in xen.cfg for me(*), and I've xfce panel plugin "Sensors plugin" set to refresh every 5 sec, then it spews 3 lines dmesg every 5 seconds and does a disk write(actual disk write, so I assumed sync/flush), 3 lines like these:
<5>[ 521.639294] audit: type=1100 audit(1537814876.977:451): pid=5406 uid=1000 auid=1000 ses=2 msg='op=PAM:authentication grantors=pam_localuser acct="root" exe="/usr/sbin/userhelper" hostname=? addr=? terminal=? res=success'
<5>[ 521.639418] audit: type=1101 audit(1537814876.977:452): pid=5406 uid=1000 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_permit acct="root" exe="/usr/sbin/userhelper" hostname=? addr=? terminal=? res=success'
<15>[ 521.640091] userhelper[5406]: running '/usr/sbin/hddtemp -n -q /dev/sda' with root privileges on behalf of 'ctor'
* it actually syncs to disk even when audit=0 does exist in /proc/cmdline because then I still get to see the level 15 message from above, and the logger reproduction steps still work, obviously. I've to hide the disk temperature in Sensors plugin to actually stop the every 5 sec disk sync due to that log level 15 new dmesg line.
Since it doesn't happen in Fedora 28, and Fedora 25 in dom0's systemd is too old, I can't report a bug. It's possibly fixed anyway.
In /etc/systemd/journald.conf I've the uncommented "#SyncIntervalSec=5m" which means it's at its default value.
I'm not sure what level is 5, but I see these:
/* We show everything that is MORE important than this.. */
#define CONSOLE_LOGLEVEL_SILENT 0 /* Mum's the word */
#define CONSOLE_LOGLEVEL_MIN 1 /* Minimum loglevel we let people use */
#define CONSOLE_LOGLEVEL_QUIET 4 /* Shhh ..., when booted with "quiet" */
#define CONSOLE_LOGLEVEL_DEBUG 10 /* issue debug messages */
#define CONSOLE_LOGLEVEL_MOTORMOUTH 15 /* You can't shut this one up */
in /home/user/qubes-builder/chroot-fc25/home/user/rpmbuild/BUILD/kernel-latest-4.18.9/linux-4.18.9/include/linux/printk.h
Oh wait, it's actually in linux/kern_levels.h
#define KERN_EMERG KERN_SOH "0" /* system is unusable */
#define KERN_ALERT KERN_SOH "1" /* action must be taken immediately */
#define KERN_CRIT KERN_SOH "2" /* critical conditions */
#define KERN_ERR KERN_SOH "3" /* error conditions */
#define KERN_WARNING KERN_SOH "4" /* warning conditions */
#define KERN_NOTICE KERN_SOH "5" /* normal but significant condition */
#define KERN_INFO KERN_SOH "6" /* informational */
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
#define KERN_DEFAULT KERN_SOH "d" /* the default kernel loglevel */
so 5 is Notice.
So you see, for me, it appears (unless I'm wrong about something and I don't know it, but happy to stand corrected) that new dmesg lines are instantly sync-ed to disk in dom0.
Maybe's something else I've changed, however I do remember seeing the HDD led blink every second after a new Qubes 4.0 install just after setting Sensors to refresh every 1 second. (that install was too new to have changed anything else like systemd .conf files or kernel cmdline options)
Here's what I've changed systemd-wise:
[ctor@dom0 ~]$ grep -nHv '^\s*#' /etc/systemd/*.conf
/etc/systemd/coredump.conf:13:
/etc/systemd/coredump.conf:14:[Coredump]
/etc/systemd/journald.conf:13:
/etc/systemd/journald.conf:14:[Journal]
/etc/systemd/journald.conf:21:RateLimitIntervalSec=0
/etc/systemd/journald.conf:23:RateLimitBurst=5000
/etc/systemd/journald.conf:25:
/etc/systemd/journald.conf:37:ForwardToSyslog=yes
/etc/systemd/journald.conf:39:ForwardToKMsg=yes
/etc/systemd/journald.conf:41:ForwardToConsole=yes
/etc/systemd/journald.conf:43:ForwardToWall=yes
/etc/systemd/journald.conf:45:TTYPath=/dev/tty12
/etc/systemd/journald.conf:47:MaxLevelStore=debug
/etc/systemd/journald.conf:49:MaxLevelSyslog=debug
/etc/systemd/journald.conf:51:MaxLevelKMsg=debug
/etc/systemd/journald.conf:53:MaxLevelConsole=debug
/etc/systemd/journald.conf:55:MaxLevelWall=emerg
/etc/systemd/logind.conf:13:
/etc/systemd/logind.conf:14:[Login]
/etc/systemd/resolved.conf:13:
/etc/systemd/resolved.conf:14:[Resolve]
/etc/systemd/resolved.conf:16:DNS=
/etc/systemd/resolved.conf:18:FallbackDNS=
/etc/systemd/resolved.conf:21:LLMNR=no
/etc/systemd/resolved.conf:23:DNSSEC=no
/etc/systemd/resolved.conf:25:Cache=yes
/etc/systemd/resolved.conf:26:
/etc/systemd/resolved.conf:28:MulticastDNS=no
/etc/systemd/resolved.conf:29:
/etc/systemd/system.conf:13:
/etc/systemd/system.conf:14:[Manager]
/etc/systemd/system.conf:22:CrashChangeVT=yes
/etc/systemd/system.conf:24:CrashShell=yes
/etc/systemd/system.conf:26:CrashReboot=no
/etc/systemd/system.conf:27:
/etc/systemd/system.conf:31:
/etc/systemd/system.conf:41:DefaultStandardOutput=journal+console
/etc/systemd/system.conf:43:DefaultStandardError=journal+console
/etc/systemd/system.conf:44:DefaultTimeoutStartSec=90s
/etc/systemd/system.conf:46:DefaultTimeoutStopSec=90s
/etc/systemd/timesyncd.conf:13:
/etc/systemd/timesyncd.conf:14:[Time]
/etc/systemd/user.conf:12:
/etc/systemd/user.conf:13:[Manager]
And xen.cfg -wise
[4.18.9-1.pvops.qubes.x86_64]
options=loglvl=all dom0_mem=min:2048M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off
kernel=vmlinuz-4.18.9-1.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-9ed952b5-2aa8-4564-b700-fb23f5c9e94b rd.lvm.lv=qubes_dom0/root i915.alpha_support=1 rd.luks.options=discard root_trim=yes rd.luks.allow-discards ipv6.disable=1 loglevel=15 log_buf_len=16M printk.always_kmsg_dump=y printk.time=y printk.devkmsg=on mminit_loglevel=0 memory_corruption_check=1 fbcon=scrollback:4096k fbcon=font:ProFont6x11 net.ifnames=1 pax_sanitize_slab=full console=tty1 earlyprintk=vga systemd.log_target=kmsg systemd.journald.forward_to_console=1 udev.children-max=1256 rd.udev.children-max=1256 rhgb sysrq_always_enabled
ramdisk=initramfs-4.18.9-1.pvops.qubes.x86_64.img
(audit=0 is removed from above, currently - I placed it back after this post)
[ctor@dom0 ~]$ sysctl -a 2>/dev/null|grep -i vm.dirty
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 360000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 60000
vm.dirtytime_expire_seconds = 43200
Rusty Bird
Hash: SHA512
Marcus Linsner:
> 3. in a 3rd terminal: logger
>
> 15KB)
I can't reproduce this in my dom0, which has vanilla journald.conf/
sysctl values and kernel/Xen parameters. "Actual DISK WRITE" remains
at zero when I log a line.
> In /etc/systemd/journald.conf I've the uncommented
> "#SyncIntervalSec=5m" which means it's at its default value.
>
"5m" = 5 minutes, i.e. EMERG/ALERT/CRIT level messages are synced to
disk immediately and other messages once every 300 seconds.
> Maybe's something else I've changed, however I do remember seeing
> the HDD led blink every second after a new Qubes 4.0 install just
> after setting Sensors to refresh every 1 second.
temperature command communicates with the disk (even though it's not a
substantial write). You can test this by running 'hddtemp' in a root
shell.
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJbqWESXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfANMQAJm1KoJekqfR59jiN6T+TCKo
nYNYhNF0Ke5CPCrnAEOOOhP0HsZ9jRfIBWAIlgE3xLuoPYwC7Bv+nsPx8IWIe4uK
q567hzEZcHnMTRTHB9Z5mKw5e4y5HtmchgFRBzTUWWQFM+ir2vkE0wcsQA4FhIdN
4RhK/kaOGH1QxNYNNxQyu5vly5fdDKipS3Fc2LDytIjqR8vpvV3KgAQX4mQ1Dswc
E4FalCOqj/DKR7GnkhuDlAWAESD635rsety3/NG6S69HvnoXRPGRnY6L/6u0c1b3
aIdP+6wZv3IEziOZmb4xoqCCmdScqajVnnNOmw4zr/wmV2gXbNzArDD8SZ2k/dx1
OZ9LzAZLUbQt9npx1F3+oWLe/r+zCqWWvOZXSsW5au0jBbMbVTvrxppgbHrpIPLt
tPTi5IUBkI0jacIcTSh69VK1CyBIpiZ6FHd4Arg7/1dEL2LBwR0ZuFYkvAdfKRAy
PVzc7EVgeEgk9JTHvwZp/kqPuuIG+yNoSqlaFfpZPVeoBrbEgq3xK/0C/HvQahoz
HnVzVt4PFnM3jXMWAUANWFARixecNPMmegzMQINX2HzCYcjvmWm1bO/L0bXOIfx+
msg/gDj0a1R2de4EpZ6z5fO4QVqmPQvBysWsw0wqMi9D+/64DEIroIJczgQtJGOH
O+eHHDszWj452vikWbYl
=+gnj
-----END PGP SIGNATURE-----
Rusty Bird
Hash: SHA512
> > 2. in another terminal: sudo iotop
> > 3. in a 3rd terminal: logger
> >
> > every time you press Enter in [3.] [...] "Actual DISK WRITE" is like
> > 15KB)
>
> I can't reproduce this in my dom0, which has vanilla journald.conf/
> sysctl values and kernel/Xen parameters. "Actual DISK WRITE" remains
> at zero when I log a line.
>
> > In /etc/systemd/journald.conf I've the uncommented
> > "#SyncIntervalSec=5m" which means it's at its default value.
> >
> > I'm not sure what level is 5 [...]
>
> "5m" = 5 minutes, i.e. EMERG/ALERT/CRIT level messages are synced to
> disk immediately and other messages once every 300 seconds.
priority, but now I see you were referring to the dmesg lines prefixed
with <5> in your post. Those would be level NOTICE, so they should not
cause an immediate sync.
> > Maybe's something else I've changed, however I do remember seeing
> > the HDD led blink every second after a new Qubes 4.0 install just
> > after setting Sensors to refresh every 1 second.
>
> That's probably just your LED visualizing that the Sensors hard disk
> temperature command communicates with the disk (even though it's not a
> substantial write). You can test this by running 'hddtemp' in a root
> shell.
Rusty
-----BEGIN PGP SIGNATURE-----
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrforUP/3DChOxeOfZFjKqyf+OuW8rF
cMX/yjFzufap7vjX0yikndre9h4Zdynw/5CM1T0t4qUDG1sdbKxxxJo8W0i/+cVm
hfFWf+0XiW9tryOkx6m7Rd544YHfE5c895T46RFKKbkr4Fzr0iadkEknv1soS8N9
MNGL4yufiX9z24s+da8MBdprmN5bdrGmiIxGKKAvVmP18JmD02QrUiXdVem/unsk
so/F2hgEjsNHpjMMetZO2qu53Q7y5h5d7s7yvvzYJ338VrkfqWWjxDQDFXWzymWY
1nvX4SpUM0bWPzpfVW/rjsBxcVxH9wSPzmDMagXvG5IdA8vGvmZlygImlWcssish
jbQ3h5LURxRQh7zwY8L3dia00Ur4L86j+QXAtaGU9+476+ggBXbKgDIcChjXOhjJ
K9DMGp6Q/qPHECYSEXoR+QqV+h60dS91Gsf/mG9i5klDEDobm8XJIz5USTifHwVL
YdR2G3B9t8AqXtdLOL3yfYpLOyzt3MP1SEq1NnJ6/cB1vqo02CNWS8+HwBPq/Lle
f2vHFK6dWDIuUIotIw5AZnEWi+VVJ/rrMwEMQDvjIqzgGxealu2y8RL3F3I4GRly
fC+M7ocjoC9ITiOA0La2xMViNN5pVroEWEiukANadwe6qq11lFC+pHR+Mw21Zsb1
lJrPFWNM0EEIYf8cJsXb
=5nia
-----END PGP SIGNATURE-----
Marcus Linsner
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Rusty Bird:
> > Marcus Linsner:
> > > 2. in another terminal: sudo iotop
> > > 3. in a 3rd terminal: logger
> > >
> > > every time you press Enter in [3.] [...] "Actual DISK WRITE" is like
> > > 15KB)
> >
> > I can't reproduce this in my dom0, which has vanilla journald.conf/
> > sysctl values and kernel/Xen parameters. "Actual DISK WRITE" remains
> > at zero when I log a line.
I switched to using `sudo iotop -d 5` (ie. refresh every 5 sec, not every 1 sec) because it allows me to copy paste the screen.
This is idle time (ie. no change happens for 30 sec):
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd --switched-root --system --deserialize 24
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0]
4 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]
6 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [mm_percpu_wq]
7 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
8 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_sched]
9 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_bh]
10 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/0]
11 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/0]
12 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/0]
13 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/1]
14 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/1]
15 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/1]
16 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/1]
18 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/1:0H]
19 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/2]
20 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/2]
21 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/2]
22 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/2]
3095 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % lightdm [gmain]
24 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/2:0H]
25 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/3]
26 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/3]
27 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/3]
28 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/3]
3101 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % X -core -noreset :0 -seat seat0 -auth /var/run/ligh~t/:0 -nolisten tcp vt1 -novtswitch -background none
30 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/3:0H]
After I press Enter in `logger` (ie. puts one message on `sudo journalctl -f`), this happens first:
Total DISK READ : 0.00 B/s | Total DISK WRITE : 812.71 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
739 be/4 root 0.00 B/s 812.71 B/s 0.00 % 0.00 % systemd-journald
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd --switched-root --system --deserialize 24
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0]
4 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]
6 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [mm_percpu_wq]
7 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
8 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_sched]
9 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_bh]
10 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/0]
11 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/0]
12 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/0]
13 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/1]
14 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/1]
15 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/1]
16 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/1]
18 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/1:0H]
19 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/2]
20 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/2]
21 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/2]
22 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/2]
3095 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % lightdm [gmain]
24 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/2:0H]
25 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/3]
26 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/3]
27 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/3]
28 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/3]
and this second:
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 3.17 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
656 be/3 root 0.00 B/s 0.00 B/s 0.00 % 0.07 % [jbd2/dm-4-8]
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd --switched-root --system --deserialize 24
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0]
4 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]
6 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [mm_percpu_wq]
7 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
8 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_sched]
9 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_bh]
10 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/0]
11 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/0]
12 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/0]
13 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/1]
14 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/1]
15 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/1]
16 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/1]
18 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/1:0H]
19 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/2]
20 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/2]
21 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/2]
22 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/2]
3095 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % lightdm [gmain]
24 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/2:0H]
25 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/3]
26 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/3]
27 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/3]
In other words, `systemd-journald` causes a write as `Total DISK WRITE`, but not a sync/flush to disk, so not `Actual DISK WRITE:` ,
then at at most 5-10 sec later `[jbd2/dm-4-8]` is the one that causes the sync/flush aka `Actual DISK WRITE:` !
For this test(above) I've stopped all running VMs (only dom0 shows in Qubes Manager), switched to vanilla kernel:
[ctor@dom0 ~]$ uname -a
Linux dom0 4.14.67-1.pvops.qubes.x86_64 #1 SMP Sun Sep 2 04:07:29 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Used this /proc/cmdline :
[ctor@dom0 ~]$ cat /proc/cmdline
root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-9ed952b5-2aa8-4564-b700-fb23f5c9e94b rd.lvm.lv=qubes_dom0/root i915.alpha_support=1 rd.luks.options=discard audit=0 root_trim=yes rd.luks.allow-discards ipv6.disable=1 rhgb
This is in /boot/efi/EFI/qubes/xen.cfg :
[global]
default=4.14.67-1.pvops.qubes.x86_64
[4.14.67-1.pvops.qubes.x86_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off
kernel=vmlinuz-4.14.67-1.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-9ed952b5-2aa8-4564-b700-fb23f5c9e94b rd.lvm.lv=qubes_dom0/root i915.alpha_support=1 rd.luks.options=discard audit=0 root_trim=yes rd.luks.allow-discards ipv6.disable=1 rhgb
ramdisk=initramfs-4.14.67-1.pvops.qubes.x86_64.img
systemd .conf files are back to vanilla:
[ctor@dom0 ~]$ grep -nHv '^\s*#' /etc/systemd/*.conf
/etc/systemd/coredump.conf:13:
/etc/systemd/coredump.conf:14:[Coredump]
/etc/systemd/journald.conf:13:
/etc/systemd/journald.conf:14:[Journal]
/etc/systemd/journald.conf:25:
/etc/systemd/logind.conf:13:
/etc/systemd/logind.conf:14:[Login]
/etc/systemd/resolved.conf:13:
/etc/systemd/resolved.conf:14:[Resolve]
/etc/systemd/resolved.conf:26:
/etc/systemd/resolved.conf:29:
/etc/systemd/system.conf:13:
/etc/systemd/system.conf:14:[Manager]
/etc/systemd/system.conf:27:
/etc/systemd/system.conf:31:
/etc/systemd/timesyncd.conf:13:
/etc/systemd/timesyncd.conf:14:[Time]
/etc/systemd/user.conf:12:
/etc/systemd/user.conf:13:[Manager]
sysctl stuff is back to vanilla:
[ctor@dom0 ~]$ ls -la /etc/sysctl.d/
total 16
drwxr-xr-x. 2 root root 4096 Sep 26 18:35 .
drwxr-xr-x. 108 root root 12288 Sep 26 18:35 ..
lrwxrwxrwx. 1 root root 14 Oct 26 2017 99-sysctl.conf -> ../sysctl.conf
[ctor@dom0 ~]$ cat /etc/sysctl.conf
# sysctl settings are defined through files in
# /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.
#
# Vendors settings live in /usr/lib/sysctl.d/.
# To override a whole file, create a new file with the same in
# /etc/sysctl.d/ and put new settings there. To override
# only specific settings, add a file with a lexically later
# name in /etc/sysctl.d/ and put new settings there.
#
# For more information, see sysctl.conf(5) and sysctl.d(5).
[ctor@dom0 ~]$ grep -vE '^\s*(#.*)?$' /etc/lvm/lvm.conf
config {
checks = 1
abort_on_errors = 0
profile_dir = "/etc/lvm/profile"
}
devices {
dir = "/dev"
scan = [ "/dev" ]
obtain_device_list_from_udev = 1
external_device_info_source = "none"
preferred_names = [ "^/dev/mpath/", "^/dev/mapper/mpath", "^/dev/[hs]d" ]
cache_dir = "/etc/lvm/cache"
cache_file_prefix = ""
write_cache_state = 1
sysfs_scan = 1
multipath_component_detection = 1
md_component_detection = 1
fw_raid_component_detection = 0
md_chunk_alignment = 1
data_alignment_detection = 1
data_alignment = 0
data_alignment_offset_detection = 1
ignore_suspended_devices = 0
ignore_lvm_mirrors = 1
disable_after_error_count = 0
require_restorefile_with_uuid = 1
pv_min_size = 2048
issue_discards = 1
allow_changes_with_duplicate_pvs = 0
}
allocation {
maximise_cling = 1
use_blkid_wiping = 1
wipe_signatures_when_zeroing_new_lvs = 1
mirror_logs_require_separate_pvs = 0
cache_pool_metadata_require_separate_pvs = 0
thin_pool_metadata_require_separate_pvs = 0
thin_pool_discards = "passdown"
}
log {
verbose = 0
silent = 0
syslog = 1
overwrite = 0
level = 0
indent = 1
command_names = 0
prefix = " "
activation = 0
debug_classes = [ "memory", "devices", "activation", "allocation", "lvmetad", "metadata", "cache", "locking", "lvmpolld", "dbus" ]
}
backup {
backup = 1
backup_dir = "/etc/lvm/backup"
archive = 1
archive_dir = "/etc/lvm/archive"
retain_min = 10
retain_days = 30
}
shell {
history_size = 100
}
global {
umask = 077
test = 0
units = "h"
si_unit_consistency = 1
suffix = 1
activation = 1
proc = "/proc"
etc = "/etc"
locking_type = 1
wait_for_locks = 1
fallback_to_clustered_locking = 1
fallback_to_local_locking = 1
locking_dir = "/run/lock/lvm"
prioritise_write_locks = 1
abort_on_internal_errors = 0
detect_internal_vg_cache_corruption = 0
metadata_read_only = 0
mirror_segtype_default = "raid1"
raid10_segtype_default = "raid10"
sparse_segtype_default = "thin"
use_lvmetad = 1
use_lvmlockd = 0
system_id_source = "none"
use_lvmpolld = 1
notify_dbus = 1
}
activation {
checks = 0
udev_sync = 1
udev_rules = 1
verify_udev_operations = 0
retry_deactivation = 1
missing_stripe_filler = "error"
use_linear_target = 1
reserved_stack = 64
reserved_memory = 8192
process_priority = -18
raid_region_size = 512
readahead = "auto"
raid_fault_policy = "warn"
mirror_image_fault_policy = "remove"
mirror_log_fault_policy = "allocate"
snapshot_autoextend_threshold = 100
snapshot_autoextend_percent = 20
thin_pool_autoextend_threshold = 100
thin_pool_autoextend_percent = 20
use_mlockall = 0
monitoring = 1
polling_interval = 15
activation_mode = "degraded"
}
dmeventd {
mirror_library = "libdevmapper-event-lvm2mirror.so"
snapshot_library = "libdevmapper-event-lvm2snapshot.so"
thin_library = "libdevmapper-event-lvm2thin.so"
}
I'm also up to date according to `sudo qubes-dom0-update` with these /etc/yum.repos.d/
[ctor@dom0 ~]$ grep -nH . -- /etc/yum.repos.d/*
/etc/yum.repos.d/fedora.repo:1:[fedora]
/etc/yum.repos.d/fedora.repo:2:name=Fedora 25 - x86_64
/etc/yum.repos.d/fedora.repo:3:failovermethod=priority
/etc/yum.repos.d/fedora.repo:4:#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/25/Everything/x86_64/os/
/etc/yum.repos.d/fedora.repo:5:mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-25&arch=x86_64
/etc/yum.repos.d/fedora.repo:6:enabled=1
/etc/yum.repos.d/fedora.repo:7:enablegroups=0
/etc/yum.repos.d/fedora.repo:8:metadata_expire=7d
/etc/yum.repos.d/fedora.repo:9:gpgcheck=1
/etc/yum.repos.d/fedora.repo:10:gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary
/etc/yum.repos.d/fedora.repo:12:[fedora-debuginfo]
/etc/yum.repos.d/fedora.repo:13:name=Fedora 25 - x86_64 - Debug
/etc/yum.repos.d/fedora.repo:14:failovermethod=priority
/etc/yum.repos.d/fedora.repo:15:#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/25/Everything/x86_64/debug/
/etc/yum.repos.d/fedora.repo:16:mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-25&arch=x86_64
/etc/yum.repos.d/fedora.repo:17:enabled=0
/etc/yum.repos.d/fedora.repo:18:enablegroups=0
/etc/yum.repos.d/fedora.repo:19:metadata_expire=7d
/etc/yum.repos.d/fedora.repo:20:gpgcheck=1
/etc/yum.repos.d/fedora.repo:21:gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary
/etc/yum.repos.d/fedora.repo:23:[fedora-source]
/etc/yum.repos.d/fedora.repo:24:name=Fedora 25 - Source
/etc/yum.repos.d/fedora.repo:25:failovermethod=priority
/etc/yum.repos.d/fedora.repo:26:#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/25/Everything/source/SRPMS/
/etc/yum.repos.d/fedora.repo:27:mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-source-25&arch=x86_64
/etc/yum.repos.d/fedora.repo:28:enabled=0
/etc/yum.repos.d/fedora.repo:29:enablegroups=0
/etc/yum.repos.d/fedora.repo:30:metadata_expire=7d
/etc/yum.repos.d/fedora.repo:31:gpgcheck=1
/etc/yum.repos.d/fedora.repo:32:gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary
/etc/yum.repos.d/fedora-updates.repo:1:[updates]
/etc/yum.repos.d/fedora-updates.repo:2:name=Fedora 25 - x86_64 - Updates
/etc/yum.repos.d/fedora-updates.repo:3:failovermethod=priority
/etc/yum.repos.d/fedora-updates.repo:4:#baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/25/x86_64/
/etc/yum.repos.d/fedora-updates.repo:5:mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f25&arch=x86_64
/etc/yum.repos.d/fedora-updates.repo:6:enabled=1
/etc/yum.repos.d/fedora-updates.repo:7:enablegroups=0
/etc/yum.repos.d/fedora-updates.repo:8:gpgcheck=1
/etc/yum.repos.d/fedora-updates.repo:9:gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary
/etc/yum.repos.d/fedora-updates.repo:11:[updates-debuginfo]
/etc/yum.repos.d/fedora-updates.repo:12:name=Fedora 25 - x86_64 - Updates - Debug
/etc/yum.repos.d/fedora-updates.repo:13:failovermethod=priority
/etc/yum.repos.d/fedora-updates.repo:14:#baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/25/x86_64/debug/
/etc/yum.repos.d/fedora-updates.repo:15:mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f25&arch=x86_64
/etc/yum.repos.d/fedora-updates.repo:16:enabled=0
/etc/yum.repos.d/fedora-updates.repo:17:enablegroups=0
/etc/yum.repos.d/fedora-updates.repo:18:gpgcheck=1
/etc/yum.repos.d/fedora-updates.repo:19:gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary
/etc/yum.repos.d/fedora-updates.repo:21:[updates-source]
/etc/yum.repos.d/fedora-updates.repo:22:name=Fedora 25 - Updates Source
/etc/yum.repos.d/fedora-updates.repo:23:failovermethod=priority
/etc/yum.repos.d/fedora-updates.repo:24:#baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/25/SRPMS/
/etc/yum.repos.d/fedora-updates.repo:25:mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-source-f25&arch=x86_64
/etc/yum.repos.d/fedora-updates.repo:26:enabled=0
/etc/yum.repos.d/fedora-updates.repo:27:enablegroups=0
/etc/yum.repos.d/fedora-updates.repo:28:gpgcheck=1
/etc/yum.repos.d/fedora-updates.repo:29:gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary
/etc/yum.repos.d/qubes-dom0.repo:1:[qubes-dom0-current]
/etc/yum.repos.d/qubes-dom0.repo:2:name = Qubes Dom0 Repository (updates)
/etc/yum.repos.d/qubes-dom0.repo:3:#baseurl = https://yum.qubes-os.org/r$releasever/current/dom0/fc25
/etc/yum.repos.d/qubes-dom0.repo:4:metalink = https://yum.qubes-os.org/r$releasever/current/dom0/fc25/repodata/repomd.xml.metalink
/etc/yum.repos.d/qubes-dom0.repo:5:enabled = 1
/etc/yum.repos.d/qubes-dom0.repo:6:metadata_expire = 7d
/etc/yum.repos.d/qubes-dom0.repo:7:gpgcheck = 1
/etc/yum.repos.d/qubes-dom0.repo:8:gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-$releasever-primary
/etc/yum.repos.d/qubes-dom0.repo:10:[qubes-dom0-current-testing]
/etc/yum.repos.d/qubes-dom0.repo:11:name = Qubes Dom0 Repository (updates-testing)
/etc/yum.repos.d/qubes-dom0.repo:12:#baseurl = https://yum.qubes-os.org/r$releasever/current-testing/dom0/fc25
/etc/yum.repos.d/qubes-dom0.repo:13:metalink = https://yum.qubes-os.org/r$releasever/current-testing/dom0/fc25/repodata/repomd.xml.metalink
/etc/yum.repos.d/qubes-dom0.repo:14:enabled = 0
/etc/yum.repos.d/qubes-dom0.repo:15:metadata_expire = 7d
/etc/yum.repos.d/qubes-dom0.repo:16:gpgcheck = 1
/etc/yum.repos.d/qubes-dom0.repo:17:gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-$releasever-primary
/etc/yum.repos.d/qubes-dom0.repo:19:[qubes-dom0-security-testing]
/etc/yum.repos.d/qubes-dom0.repo:20:name = Qubes Dom0 Repository (security-testing)
/etc/yum.repos.d/qubes-dom0.repo:21:#baseurl = https://yum.qubes-os.org/r$releasever/security-testing/dom0/fc25
/etc/yum.repos.d/qubes-dom0.repo:22:metalink = https://yum.qubes-os.org/r$releasever/security-testing/dom0/fc25/repodata/repomd.xml.metalink
/etc/yum.repos.d/qubes-dom0.repo:23:enabled = 1
/etc/yum.repos.d/qubes-dom0.repo:24:metadata_expire = 7d
/etc/yum.repos.d/qubes-dom0.repo:25:gpgcheck = 1
/etc/yum.repos.d/qubes-dom0.repo:26:gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-$releasever-primary
/etc/yum.repos.d/qubes-dom0.repo:28:[qubes-dom0-unstable]
/etc/yum.repos.d/qubes-dom0.repo:29:name = Qubes Dom0 Repository (unstable)
/etc/yum.repos.d/qubes-dom0.repo:30:#baseurl = https://yum.qubes-os.org/r$releasever/unstable/dom0/fc25
/etc/yum.repos.d/qubes-dom0.repo:31:metalink = https://yum.qubes-os.org/r$releasever/unstable/dom0/fc25/repodata/repomd.xml.metalink
/etc/yum.repos.d/qubes-dom0.repo:32:enabled = 0
/etc/yum.repos.d/qubes-dom0.repo:33:metadata_expire = 7d
/etc/yum.repos.d/qubes-dom0.repo:34:gpgcheck = 1
/etc/yum.repos.d/qubes-dom0.repo:35:gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-$releasever-unstable
/etc/yum.repos.d/qubes-templates.repo:1:[qubes-templates-itl]
/etc/yum.repos.d/qubes-templates.repo:2:name = Qubes Templates repository
/etc/yum.repos.d/qubes-templates.repo:3:#baseurl = https://yum.qubes-os.org/r$releasever/templates-itl
/etc/yum.repos.d/qubes-templates.repo:4:metalink = https://yum.qubes-os.org/r$releasever/templates-itl/repodata/repomd.xml.metalink
/etc/yum.repos.d/qubes-templates.repo:5:enabled = 1
/etc/yum.repos.d/qubes-templates.repo:6:fastestmirror = 1
/etc/yum.repos.d/qubes-templates.repo:7:metadata_expire = 7d
/etc/yum.repos.d/qubes-templates.repo:8:gpgcheck = 1
/etc/yum.repos.d/qubes-templates.repo:9:gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-$releasever-primary
/etc/yum.repos.d/qubes-templates.repo:11:[qubes-templates-itl-testing]
/etc/yum.repos.d/qubes-templates.repo:12:name = Qubes Templates repository
/etc/yum.repos.d/qubes-templates.repo:13:#baseurl = https://yum.qubes-os.org/r$releasever/templates-itl-testing
/etc/yum.repos.d/qubes-templates.repo:14:metalink = https://yum.qubes-os.org/r$releasever/templates-itl-testing/repodata/repomd.xml.metalink
/etc/yum.repos.d/qubes-templates.repo:15:enabled = 0
/etc/yum.repos.d/qubes-templates.repo:16:fastestmirror = 1
/etc/yum.repos.d/qubes-templates.repo:17:gpgcheck = 1
/etc/yum.repos.d/qubes-templates.repo:18:gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-$releasever-primary
/etc/yum.repos.d/qubes-templates.repo:20:[qubes-templates-community]
/etc/yum.repos.d/qubes-templates.repo:21:name = Qubes Community Templates repository
/etc/yum.repos.d/qubes-templates.repo:22:#baseurl = https://yum.qubes-os.org/r$releasever/templates-community
/etc/yum.repos.d/qubes-templates.repo:23:metalink = https://yum.qubes-os.org/r$releasever/templates-community/repodata/repomd.xml.metalink
/etc/yum.repos.d/qubes-templates.repo:24:enabled = 0
/etc/yum.repos.d/qubes-templates.repo:25:fastestmirror = 1
/etc/yum.repos.d/qubes-templates.repo:26:metadata_expire = 7d
/etc/yum.repos.d/qubes-templates.repo:27:gpgcheck = 1
/etc/yum.repos.d/qubes-templates.repo:28:gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-$releasever-templates-community
/etc/yum.repos.d/qubes-templates.repo:30:[qubes-templates-community-testing]
/etc/yum.repos.d/qubes-templates.repo:31:name = Qubes Community Templates repository
/etc/yum.repos.d/qubes-templates.repo:32:#baseurl = https://yum.qubes-os.org/r$releasever/templates-community-testing
/etc/yum.repos.d/qubes-templates.repo:33:metalink = https://yum.qubes-os.org/r$releasever/templates-community-testing/repodata/repomd.xml.metalink
/etc/yum.repos.d/qubes-templates.repo:34:enabled = 0
/etc/yum.repos.d/qubes-templates.repo:35:fastestmirror = 1
/etc/yum.repos.d/qubes-templates.repo:36:gpgcheck = 1
/etc/yum.repos.d/qubes-templates.repo:37:gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-$releasever-templates-community
I've also had the `Sensors plugin` removed from the panel, so it wasn't able to interfere.
So, unless I'm missing something else(which is quite possible), then this seems normal behaviour in dom0.
Please recheck with `sudo iotop -d 5` to see if you can see the same behaviour.
Note: if you're running any VMs, you'll sometimes see `[kdmflush]` at the top in iotop, but this should have no bearing on the above, because no VMs were on.
> >
> > > In /etc/systemd/journald.conf I've the uncommented
> > > "#SyncIntervalSec=5m" which means it's at its default value.
> > >
> > > I'm not sure what level is 5 [...]
> >
> > "5m" = 5 minutes, i.e. EMERG/ALERT/CRIT level messages are synced to
> > disk immediately and other messages once every 300 seconds.
>
> Oops, sorry - I thought you had mixed up the log interval and the log
> priority, but now I see you were referring to the dmesg lines prefixed
> with <5> in your post. Those would be level NOTICE, so they should not
> cause an immediate sync.
np
>
> > > Maybe's something else I've changed, however I do remember seeing
> > > the HDD led blink every second after a new Qubes 4.0 install just
> > > after setting Sensors to refresh every 1 second.
> >
> > That's probably just your LED visualizing that the Sensors hard disk
> > temperature command communicates with the disk (even though it's not a
> > substantial write). You can test this by running 'hddtemp' in a root
> > shell.
Great idea! Thanks!
From idle state (see the above iotop idle state), the following is the only thing that changes for only one refresh(5 sec):
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
10979 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:1]
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd --switched-root --system --deserialize 24
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0]
4 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]
6 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [mm_percpu_wq]
7 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
8 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_sched]
9 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_bh]
10 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/0]
11 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/0]
12 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/0]
13 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [cpuhp/1]
14 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/1]
15 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/1]
ie. `[kworker/0:1]` becomes the top for one iotop refresh, with no disk read/writes or IO %.
(tested by running `hddtemp` from inside a `sudo bash`, and it did display the correct temperature of course, with no spam on `dmesg` or in `sudo journalctl -f`)
>
> Rusty
I haven't yet tried installing an .iso because I need to get an empty disk, probably next week, then I'll be back here with report(s) :D and re-read Marek's post/apply it...
Rusty Bird
Hash: SHA512
> > > Marcus Linsner:
> In other words, `systemd-journald` causes a write as `Total DISK
> WRITE`, but not a sync/flush to disk, so not `Actual DISK WRITE:` ,
> then at at most 5-10 sec later `[jbd2/dm-4-8]` is the one that
> causes the sync/flush aka `Actual DISK WRITE:` !
option in the ext4 manpage), so that looks normal to me. OTOH I see
similar timings on btrfs, which supposedly has a 30 second default.
Strange.
> > > > Maybe's something else I've changed, however I do remember seeing
> > > > the HDD led blink every second after a new Qubes 4.0 install just
> > > > after setting Sensors to refresh every 1 second.
> > >
> > > That's probably just your LED visualizing that the Sensors hard disk
> > > temperature command communicates with the disk (even though it's not a
> > > substantial write). You can test this by running 'hddtemp' in a root
> > > shell.
> Great idea! Thanks!
> From idle state (see the above iotop idle state), the following is
> the only thing that changes for only one refresh(5 sec):
> Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
> Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
blink every time you run 'hddtemp', even though no data is written to
disk. Just a false positive.
> I haven't yet tried installing an .iso because I need to get an
> empty disk, probably next week, then I'll be back here with
> report(s) :D and re-read Marek's post/apply it...
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJbrRAAXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfmcsP/0dvfHQWQcRidOlkU9NVpHdg
wsC77rZaMLR/ljm/8sSbfGugTLTznSth18++8f6YtctCv05K9QNb5e3KD2SuIw4j
Viq2iVuYuqUBSHAFEQYWf2OZJeLjBQxCkwO76KKGQcw0AwXCRCWyTlXetPykZYbL
TXuValFPvgdkb59B0IFZpnMw/jZwUmQJx/UZGm5kUyO8H3yWNiIQp3ipwceuKhvf
9L7Pg/+fZ+5j28oLpVwH9gyBvklvPqqJWfzPjnkPQKRN13/SGV9T92zwTE3n5Fl3
XHtZXNNa+vPcaEfViqA511PadD8fwHmHQIuCvr6bySDEhpAdF6lHxmhKB14c/WAO
J/JAwVYzVyGw/ct3buCucKo1436mpzbeUN+ErCKiOOkEpeANQCOqWIMgpQwyRpRb
H0pIhJ4h+N7f+0Y4wi1MGeWeOots+4IoGTdc4DylKdHIaFrBn/AXtwc4pZyXvyFy
IPqOwH+Th1yB5fHUgQHHkQrVsp2iUToND1cajdeCGZ4h9j2gcRK+DoXfnafD73HM
gtnW6sUr3wNCTVGXfOEZk218wxRkx/IbQnHedEnp7CdTUbA7A5WhtDKSG3IYlmDH
iNI4fu+m7Wi0irdnPQE4gFQUOeVpnFjJkJjfw38QUQYJg8wYQs67FtKG8woyuoPA
ibtKw9RbLnFLc9qZlhA/
=lCQE
-----END PGP SIGNATURE-----
Marcus Linsner
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Marcus Linsner:
> > On Tuesday, September 25, 2018 at 3:13:19 PM UTC+2, Rusty Bird wrote:
> > > Rusty Bird:
> > > > Marcus Linsner:
>
> > In other words, `systemd-journald` causes a write as `Total DISK
> > WRITE`, but not a sync/flush to disk, so not `Actual DISK WRITE:` ,
> > then at at most 5-10 sec later `[jbd2/dm-4-8]` is the one that
> > causes the sync/flush aka `Actual DISK WRITE:` !
>
> 5 seconds is the ext4 default commit interval (see commit= mount
> option in the ext4 manpage), so that looks normal to me. OTOH I see
> similar timings on btrfs, which supposedly has a 30 second default.
> Strange.
>
> > > > > Maybe's something else I've changed, however I do remember seeing
> > > > > the HDD led blink every second after a new Qubes 4.0 install just
> > > > > after setting Sensors to refresh every 1 second.
> > > >
> > > > That's probably just your LED visualizing that the Sensors hard disk
> > > > temperature command communicates with the disk (even though it's not a
> > > > substantial write). You can test this by running 'hddtemp' in a root
> > > > shell.
> > Great idea! Thanks!
> > From idle state (see the above iotop idle state), the following is
> > the only thing that changes for only one refresh(5 sec):
> > Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
> > Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
>
> The thing is, if your LED is working like mine, it's still going to
> blink every time you run 'hddtemp', even though no data is written to
> disk. Just a false positive.
Yes, I can confirm this even on the laptop. I guess any "talk" with the drive over the (SATA)wires is reflected by the LED. It makes sense, of course.
So then, it was the 5 sec ext4 commit= that I was actually writing to disk only every 5 sec. The rest was just the led. All that with default systemd settings and all.
The second part of all that was, likely, my modified systemd/sysctl/xen.cfg settings which were causing the Actual Disk Write(reported by iotop) on every dmesg/journald message. (I haven't rechecked though! but it seems to be the case, since this one was immediate, with iotop 1 sec refreshes)
Thanks!
>
> > I haven't yet tried installing an .iso because I need to get an
> > empty disk, probably next week, then I'll be back here with
> > report(s) :D and re-read Marek's post/apply it...
>
> Sure, no rush.
I'm having second thoughts about using btrfs instead of ext4 now that it's the 2nd time that I've lost files on an Arch Linux laptop due to some btrfs-related kernel crash(oops with 4.19-rc5 now, in some zstd code).
In both cases though it happened with -rc kernels, so I guess I had that comming :D
The first time was the entire partition unmountable, so I lost everything. But this time only this: 21k files became 0 bytes, files like /bin/mount(because I've updated/reinstalled util-linux package like 20mins earlier). btrfsck --repair didn't fix it (it did say it fixed some other things though). So, I'm thinking with ext4 I'll at least avoid losing files because it's unlikely to crash in btrfs/ext4 code like that. On the other hand, I do want that compression...(why do I have the feeeling that ext4 has one too, without looking whether it is so or not) I haven't decided yet.
I do have a backup of the whole partition but I've changed stuff since I've made it, stuff which I'd rather not re-create again, but I clearly have to now :)
I've a backup of some text files(like PKGBUILD, *.patch, scripts) that I've changed since the partition backup, but haven't thoroughly checked to see if I did indeed back up all of them.
That commit=300 in fstab made things worse also. Every file that got updated/writtento since the last sync (ie. 5mins ago? though for util-linux, its files got updated like 20mins ago, and they all still:) became 0 bytes.
The bad part is that after that kernel crash(general protection fault I think, in zstd code; I couldn't save the error anywhere, just look at it in dmesg), any file that I tried to save afterwards became 0 bytes (seen this after the recovery-attempt phase ie. booted from usb stick with mounting ro then btrfsck then mounting ro; so /etc/hosts is 0 bytes too now lol).
So now, to avoid the above, I guess I'll have to ensure that panic on oops is set(CONFIG_PANIC_ON_OOPS, and CONFIG_PANIC_TIMEOUT [=-1]), instead of allowing kernel/system to continue, which means I'll have no idea what crashed since dmesg won't be saved anywhere, or journal sync'd(or maybe if I make all the same systemd/sysctl/xen.cfg changes on this Arch Linux laptop that I made in the Qubes computer it will sync on every new dmesg line? hmm, HMM... I should recheck to see what really causes the sync), and worst of all depending on commit= value latest x seconds (or 5mins in my case) of file changes won't be sync'd to disk. (I have panic on oops in Qubes, but not on the Arch Linux laptop; and on Qubes, when it happened, I did lose some firefox state, such as all the config for uMatrix, but not for NoScript, but only in some VMs that crashed due to this bug[1], so there's a reason not to reboot on oops)
Maybe I should just do periodic snapshots, on top of the normal backing up of text/important files changed, or simply just find a way to do full backups more often, maybe using btrfs-specific commands. Or should I just use duplicacy-git to make only file backups?
How do you do your backups?
[1] https://github.com/constantoverride/qubes-linux-kernel/issues/1#issue-364607314
Marcus Linsner
> On Monday, September 24, 2018 at 1:38:00 PM UTC+2, Rusty Bird wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > Marcus Linsner:
> > > Can I maybe still use audit=0 ? ie. another way to fix the above
> > > error? because I don't want to see the audit spam on dmesg (mainly
> > > due to journal being sync-ed to disk, seemingly every time).
> >
> > That audit spam shouldn't trigger a disk sync (because it doesn't have
> > CRIT/ALERT/EMERG priority), according to the journald.conf manpage:
> >
> > | SyncIntervalSec=
> > | The timeout before synchronizing journal files to disk. After
> > | syncing, journal files are placed in the OFFLINE state. Note that
> > | syncing is unconditionally done immediately after a log message of
> > | priority CRIT, ALERT or EMERG has been logged. This setting hence
> > | applies only to messages of the levels ERR, WARNING, NOTICE, INFO,
> > | DEBUG. The default timeout is 5 minutes.
> >
> > If it does, might be worth filing a systemd bug.
>
> Maybe it's a dom0 feature? patch added by qubes? (i doubt it but hey)
>
> It doesn't seem to happen in a Fedora 28 VM, but on dom0 (Fedora 25), I can dupe it with these steps:
> 1. in a terminal: dmesg --raw -w
> 2. in another terminal: sudo iotop
> 3. in a 3rd terminal: logger
I mean, systemd-journal does a Total DISK WRITE but not an Actual DISK WRITE which is only done by jdb2/dm-4-8 every 5 seconds, which makes sense as you said, Rusty, commit= being 5 sec by default for ext4!
So I don't know why I remembered that even the actual disk write was being made in the same 1 second instance. It's definitely not true since it clearly only happens every 5 sec.
Glad to see that I was wrong, else it would've been weird.
And thanks to you Rusty Bird, now I know it's the commit= (man ext4) which causes the sync.
Good stuff!
Rusty Bird
Hash: SHA512
Marcus Linsner:
> On Thursday, September 27, 2018 at 7:15:30 PM UTC+2, Rusty Bird wrote:
> > > empty disk, probably next week, then I'll be back here with
> > > report(s) :D and re-read Marek's post/apply it...
> >
> > Sure, no rush.
> I'm having second thoughts about using btrfs instead of ext4 now
> that it's the 2nd time that I've lost files on an Arch Linux laptop
> due to some btrfs-related kernel crash(oops with 4.19-rc5 now, in
> some zstd code).
you!
> In both cases though it happened with -rc kernels, so I guess I had
> that comming :D
common or aggressive options. FWIW, I've never had serious issues with
the LTS kernels, default mount options + noatime, and plenty of free
space.
> Maybe I should just do periodic snapshots
filesystem snapshots (though it's not necessarily the number, but the
amount of diverging data that seems to be the trigger), sooner or
later the whole system slows down a lot. YMMV.
But even one snapshot is super helpful to recover from minor user
error. And on the rare occasion that I need some older data, I fish it
out of secondary storage with qvm-backup-restore.
> How do you do your backups?
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJbr2zxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf/eMQAIzEoB0KqLQCqpm+iHzrA9tm
k3yckoXPDfMxXUupfXQ7nNZNjOUXHG88Dftd66DZFszMtFIC6Hg58HjcvbgYe23k
NtoJTZOfLwMt6s74U9ZboHK0r8xGCX2x42qCFY2GYep0+V2aWytNHxJfoYgLRXzN
3FplocBnIb5IrNL6jRV0/HotZYakdzLz9JpVthnNkKLuibZ3StXQAZ9gzsVccyYi
gf/yfePf0d6DBlxwE50Sha5+NkXW3/pnKyZsS7NlTp44G2iCbiMgegYiksG11TMn
SzVDuIf3oWUgjxDwD+wtHYAnASaXCAg/tCKVNvlLz0Zk1URMJ/xdwRbC8UzNodLY
SAjUENOzRGLfOCF4r2xW7pU4RXHq55rr4TitZmvvzqFnBcNlcwXpY3I6IOoyGQGa
ud7f9LcREjQBopnUwiwUnFT35l5fu3Ypux7NO1O17FT63eBoryJrgx6l3w5mam4Z
ozYdd5ua02X/a1rI+KY+kdKBCBKgDO8W6/u/yKUxxzfkOsRLjonMXV1k5ZinxRfd
QPSyMkbmQZpV2Mb4hZn7Ui07SGC3K+TrB3sa0+tkGwdi18n27UBNLyXFqSma+ZhZ
rMLBwLQVA9I54S5xjjGQCHxeJQJP/yhXINsij5GdrlY56BX73Yf0dwke7pBIKHDp
8nHiLsEd0Skb0PjJNupB
=uEnf
-----END PGP SIGNATURE-----