disposableVM not really disposable
174 views
Skip to first unread message
cubit
Jul 26, 2016, 1:52:49 PM7/26/16
to Qubes Users
Heyya
I have discovered my disposableVM Firefox is not really disposable as history persists between sessions.
This came to notice as I have recently customized my browser, setting up a new start page and removing the hello and pocket buttons. Though I have noticed similar issues before customization though did not think to check if history was being stored.
Over the last couple of days each time I start Firefox I get the "Well, this is embarrassing." error with a restore session tab for my home page. I also get two other tabs to Mozilla pages => The first run page and a bit ironically a page showing the private browsing mode.
I opened the history tab today to discover I have 3 days worth of history stored in the browser.
I can work around this by doing a qvm-create-defalult-dvm <custom-template> but I would like to know what is the best way to fix this permanently.
I have discovered my disposableVM Firefox is not really disposable as history persists between sessions.
This came to notice as I have recently customized my browser, setting up a new start page and removing the hello and pocket buttons. Though I have noticed similar issues before customization though did not think to check if history was being stored.
Over the last couple of days each time I start Firefox I get the "Well, this is embarrassing." error with a restore session tab for my home page. I also get two other tabs to Mozilla pages => The first run page and a bit ironically a page showing the private browsing mode.
I opened the history tab today to discover I have 3 days worth of history stored in the browser.
I can work around this by doing a qvm-create-defalult-dvm <custom-template> but I would like to know what is the best way to fix this permanently.
Andrew David Wong
Jul 26, 2016, 2:26:37 PM7/26/16
to cubit, Qubes Users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Another user, Alex, previously reported the same phenomenon here:
https://groups.google.com/d/topic/qubes-users/Eipv3eNKzJQ/discussion
I've begun tracking this issue here:
https://github.com/QubesOS/qubes-issues/issues/2200
We currently know very little about this issue, so I'm afraid there is
no solution yet.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXl6tPAAoJENtN07w5UDAwF8MP/joYjmWAHZb71J1mNH01thip
G9vZw7SmlsMCibj5ej2pesPWEJ5QjqPKC2fJh3OaSXapqGG6RNjGR8rH12Eb81/8
5c3e+6jx2VCK87U8VKVQnPbN4x/cligMvyrEES1V4gass0wLfdIc5kOvQVe0qImp
JZCJ6yboBgywq+qYkyO5xuM6LhHnfdNq/QRmPOT6mO3o/+xq5nwN7a9104/jdDzT
np6M+/4mMt71UHYoyX8x2/Wdl7PxjpWskewy6lWYf7LPNw4LZONkDxkNWkVbKjoi
1QWjARyGpWXJSWNCyuA7kSYTx9ePxfqi1fXp7aqGKr89PNNytTOWfgPu3yStMzFQ
FxcWfBBv7sndEKSmUvT086a2dBR1L58r7F9OVgri2D6aPIjHs3V8UKLQ9/ie3csG
uMYsGRRj3Dbl1oFBYlvnuBcI6J5WvCg0a5y0ygf6VPZtu73oiEexV4/MABN52juP
AClcqWYQflMtPuFaCPKJ+qcOfX6qMGhLP9ulYM02nswbA7gRSNQsT+vdJz7Ewn4k
1yoYGQfVNBLdx0seBUxzETn/cIwWmFwf4sbmqHJXjzmWqkCxlerO5F6keH95Vao+
IPJPDqqLmvVyaDRB+V7JWkKyZOTTdj/8n5stSV1WxAVJ75O67O18+AQQom512iL1
MeImhzQiHHf22gbFtRzm
=ftqb
-----END PGP SIGNATURE-----
Hash: SHA512
https://groups.google.com/d/topic/qubes-users/Eipv3eNKzJQ/discussion
I've begun tracking this issue here:
https://github.com/QubesOS/qubes-issues/issues/2200
We currently know very little about this issue, so I'm afraid there is
no solution yet.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXl6tPAAoJENtN07w5UDAwF8MP/joYjmWAHZb71J1mNH01thip
G9vZw7SmlsMCibj5ej2pesPWEJ5QjqPKC2fJh3OaSXapqGG6RNjGR8rH12Eb81/8
5c3e+6jx2VCK87U8VKVQnPbN4x/cligMvyrEES1V4gass0wLfdIc5kOvQVe0qImp
JZCJ6yboBgywq+qYkyO5xuM6LhHnfdNq/QRmPOT6mO3o/+xq5nwN7a9104/jdDzT
np6M+/4mMt71UHYoyX8x2/Wdl7PxjpWskewy6lWYf7LPNw4LZONkDxkNWkVbKjoi
1QWjARyGpWXJSWNCyuA7kSYTx9ePxfqi1fXp7aqGKr89PNNytTOWfgPu3yStMzFQ
FxcWfBBv7sndEKSmUvT086a2dBR1L58r7F9OVgri2D6aPIjHs3V8UKLQ9/ie3csG
uMYsGRRj3Dbl1oFBYlvnuBcI6J5WvCg0a5y0ygf6VPZtu73oiEexV4/MABN52juP
AClcqWYQflMtPuFaCPKJ+qcOfX6qMGhLP9ulYM02nswbA7gRSNQsT+vdJz7Ewn4k
1yoYGQfVNBLdx0seBUxzETn/cIwWmFwf4sbmqHJXjzmWqkCxlerO5F6keH95Vao+
IPJPDqqLmvVyaDRB+V7JWkKyZOTTdj/8n5stSV1WxAVJ75O67O18+AQQom512iL1
MeImhzQiHHf22gbFtRzm
=ftqb
-----END PGP SIGNATURE-----
cubit
Jul 26, 2016, 2:29:16 PM7/26/16
to Andrew David Wong, Qubes Users
26. Jul 2016 18:26 by a...@qubes-os.org:
Another user, Alex, previously reported the same phenomenon here:
https://groups.google.com/d/topic/qubes-users/Eipv3eNKzJQ/discussion
Thank you, my search fu was failing me, I though I remembered something like this already
I've begun tracking this issue here:
https://github.com/QubesOS/qubes-issues/issues/2200
We currently know very little about this issue, so I'm afraid there is
no solution yet.
Is there any information I can gather that might help before I run qvm-create-defalult-dvm?
Marek Marczykowski-Górecki
Jul 26, 2016, 7:14:09 PM7/26/16
to cubit, Andrew David Wong, Qubes Users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Check file list in /var/lib/qubes/appvms/fedora-23-dvm. Especially date
and permissions of volatile.img there.
- --
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-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXl+66AAoJENuP0xzK19csa+4IAIwrFubD3JWRprTv9ZrvbwnT
w0iiOFNig3JQplN5HUsG4MBd+4lkBUmCvjuWPccCTh4nuzJWFJT7VccL/fgs6vUk
Zhj4RQzugFjhn21+aiHvE/dgNJDwrMGx/AxW/kt2oeOJ/ITdOuBRCLs1eVKiKe02
xdyxKgq1paCqQILHb8o7j6hstdhyOwjpicGZz/BYTzG1ZuwCNHZ9rIlsHyUxYWgh
q75YnDK67vbeVQ0cvuhfgcmSkgR2RpbjxI+hZJL2ddJ6USyegr9nuPbUAwKLww+w
RZO8i9amwVtNYWpcUbKWx9RlrUQAgJOZ3+apecqaAHC+V6wU0dFluIBGrGzf+uA=
=DEa+
-----END PGP SIGNATURE-----
Hash: SHA256
and permissions of volatile.img there.
- --
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-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXl+66AAoJENuP0xzK19csa+4IAIwrFubD3JWRprTv9ZrvbwnT
w0iiOFNig3JQplN5HUsG4MBd+4lkBUmCvjuWPccCTh4nuzJWFJT7VccL/fgs6vUk
Zhj4RQzugFjhn21+aiHvE/dgNJDwrMGx/AxW/kt2oeOJ/ITdOuBRCLs1eVKiKe02
xdyxKgq1paCqQILHb8o7j6hstdhyOwjpicGZz/BYTzG1ZuwCNHZ9rIlsHyUxYWgh
q75YnDK67vbeVQ0cvuhfgcmSkgR2RpbjxI+hZJL2ddJ6USyegr9nuPbUAwKLww+w
RZO8i9amwVtNYWpcUbKWx9RlrUQAgJOZ3+apecqaAHC+V6wU0dFluIBGrGzf+uA=
=DEa+
-----END PGP SIGNATURE-----
cubit
Jul 27, 2016, 5:38:56 AM7/27/16
to Marek Marczykowski-Górecki, Andrew David Wong, Qubes Users
26. Jul 2016 23:14 by marm...@invisiblethingslab.com:
Check file list in /var/lib/qubes/appvms/fedora-23-dvm. Especially date
and permissions of volatile.img there.
It's actually fedora-23-stable-dvm based off a copy of the template
Here is the file list, there is one noticeable difference when comparing it to fedora-23-dvm folder. For my template volatile.img is chmod 600 while it is 644 in fedora-23-dvm. Changing the permissions to match 644 does not change anything, the problem still exists
total 503544
-rw-rw-r-- 1 user qubes 1671 Jun 3 11:18 disp10.conf
-rw-rw-r-- 1 user qubes 1671 Jun 3 11:33 disp11.conf
-rw-rw-r-- 1 user qubes 1671 Jun 4 19:58 disp12.conf
-rw-rw-r-- 1 user qubes 1671 Jun 4 19:59 disp13.conf
-rw-rw-r-- 1 user qubes 1671 Jun 4 20:01 disp14.conf
-rw-rw-r-- 1 user qubes 1671 Jul 14 18:25 disp15.conf
-rw-rw-r-- 1 user qubes 1671 Jul 14 18:26 disp16.conf
-rw-rw-r-- 1 user qubes 1671 Jul 14 18:27 disp17.conf
-rw-rw-r-- 1 user qubes 1671 Jul 14 18:28 disp18.conf
-rw-rw-r-- 1 user qubes 1671 Jul 14 18:34 disp19.conf
-rw-rw-r-- 1 user qubes 1669 Jul 26 15:08 disp1.conf
-rw-rw-r-- 1 user qubes 1671 Jul 14 18:53 disp20.conf
-rw-rw-r-- 1 user qubes 1671 Jul 15 12:44 disp21.conf
-rw-rw-r-- 1 user qubes 1671 Jul 17 07:27 disp22.conf
-rw-rw-r-- 1 user qubes 1671 Jul 18 08:55 disp23.conf
-rw-rw-r-- 1 user qubes 1671 Jul 18 09:20 disp24.conf
-rw-rw-r-- 1 user qubes 1671 Jul 18 13:30 disp25.conf
-rw-rw-r-- 1 user qubes 1671 Jul 18 16:25 disp26.conf
-rw-rw-r-- 1 user qubes 1671 Jul 18 20:48 disp27.conf
-rw-rw-r-- 1 user qubes 1671 Jul 18 20:56 disp28.conf
-rw-rw-r-- 1 user qubes 1671 Jul 19 11:47 disp29.conf
-rw-rw-r-- 1 user qubes 1669 Jul 26 15:58 disp2.conf
-rw-rw-r-- 1 user qubes 1671 Jul 19 15:23 disp30.conf
-rw-rw-r-- 1 user qubes 1671 Jul 19 15:31 disp31.conf
-rw-rw-r-- 1 user qubes 1671 Jul 19 15:35 disp32.conf
-rw-rw-r-- 1 user qubes 1671 Jul 19 15:36 disp33.conf
-rw-rw-r-- 1 user qubes 1671 Jul 19 15:44 disp34.conf
-rw-rw-r-- 1 user qubes 1671 Jul 19 15:52 disp35.conf
-rw-rw-r-- 1 user qubes 1671 Jul 19 16:19 disp36.conf
-rw-rw-r-- 1 user qubes 1671 Jul 19 17:02 disp37.conf
-rw-rw-r-- 1 user qubes 1671 Jul 19 17:14 disp38.conf
-rw-rw-r-- 1 user qubes 1671 Jul 19 18:13 disp39.conf
-rw-rw-r-- 1 user qubes 1669 Jul 26 17:25 disp3.conf
-rw-rw-r-- 1 user qubes 1671 Jul 19 20:07 disp40.conf
-rw-rw-r-- 1 user qubes 1671 Jul 20 08:07 disp41.conf
-rw-rw-r-- 1 user qubes 1671 Jul 20 16:30 disp42.conf
-rw-rw-r-- 1 user qubes 1671 Jul 21 09:49 disp43.conf
-rw-rw-r-- 1 user qubes 1671 Jul 21 12:00 disp44.conf
-rw-rw-r-- 1 user qubes 1671 Jul 21 12:01 disp45.conf
-rw-rw-r-- 1 user qubes 1671 Jul 21 12:02 disp46.conf
-rw-rw-r-- 1 user qubes 1671 Jul 21 12:05 disp47.conf
-rw-rw-r-- 1 user qubes 1671 Jul 21 12:05 disp48.conf
-rw-rw-r-- 1 user qubes 1671 Jul 21 12:06 disp49.conf
-rw-rw-r-- 1 user qubes 1669 Jul 26 18:34 disp4.conf
-rw-rw-r-- 1 user qubes 1671 Jul 21 14:15 disp50.conf
-rw-rw-r-- 1 user qubes 1671 Jul 21 15:09 disp51.conf
-rw-rw-r-- 1 user qubes 1671 Jul 22 09:23 disp52.conf
-rw-rw-r-- 1 user qubes 1671 Jul 22 09:24 disp53.conf
-rw-rw-r-- 1 user qubes 1669 Jul 26 18:51 disp5.conf
-rw-rw-r-- 1 user qubes 1669 Jul 26 19:59 disp6.conf
-rw-rw-r-- 1 user qubes 1669 May 30 12:16 disp7.conf
-rw-rw-r-- 1 user qubes 1669 Jun 2 20:15 disp8.conf
-rw-rw-r-- 1 user qubes 1670 Jun 2 20:15 disp9.conf
-rw-rw-r-- 1 user qubes 309223442 Jul 21 09:49 dvm-savefile
-rw-rw-r-- 1 user qubes 1925 Jul 21 09:49 fedora-23-stable-dvm.conf
lrwxrwxrwx 1 user qubes 55 Mar 31 16:15 icon.png -> /usr/share/icons/hicolor/128x128/devices/appvm-gray.png
-rw-rw-r-- 1 user qubes 1 Jul 21 09:49 netvm-id.txt
-rw-rw---- 1 user qubes 2147483648 Jul 21 09:49 private.img
-rw-rw-r-- 1 user qubes 1024 Jul 21 09:49 saved-cows.tar
-rw------- 1 root qubes 12348030976 Jul 26 20:00 volatile.img
-rw-rw-r-- 1 user qubes 70 Mar 31 16:15 whitelisted-appmenus.list
Herbies
Aug 5, 2016, 5:53:07 AM8/5/16
to qubes...@googlegroups.com
Same issue here.
Solved by entering on the template fedora-23-dispvm (or the name you are
using)
I have opened FF for addon updates.
run command touch. qubes-disp.customized as you can find here
https://www.qubes-os.org/doc/dispvm-customization/
Than use the command qvm-create-default-dvm
And you should start with empty tempaltes.
Hope it help you
Solved by entering on the template fedora-23-dispvm (or the name you are
using)
I have opened FF for addon updates.
run command touch. qubes-disp.customized as you can find here
https://www.qubes-os.org/doc/dispvm-customization/
Than use the command qvm-create-default-dvm
And you should start with empty tempaltes.
Hope it help you
Marek Marczykowski-Górecki
Aug 5, 2016, 5:57:46 AM8/5/16
to cubit, Andrew David Wong, Qubes Users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Wed, Jul 27, 2016 at 10:38:52AM +0100, cubit wrote:
> 26. Jul 2016 23:14 by marm...@invisiblethingslab.com:
>
> > Check file list in /var/lib/qubes/appvms/fedora-23-dvm. Especially date
> > and permissions of volatile.img there.
> >
>
>
>
>
> It's actually fedora-23-stable-dvm based off a copy of the template
>
>
>
>
> Here is the file list, there is one noticeable difference when comparing it to fedora-23-dvm folder. For my template volatile.img is chmod 600 while it is 644 in fedora-23-dvm. Changing the permissions to match 644 does not change anything, the problem still exists
Change it to 664 (same as other files there) - so qubes group will have
> 26. Jul 2016 23:14 by marm...@invisiblethingslab.com:
>
> > Check file list in /var/lib/qubes/appvms/fedora-23-dvm. Especially date
> > and permissions of volatile.img there.
> >
>
>
>
>
> It's actually fedora-23-stable-dvm based off a copy of the template
>
>
>
>
> Here is the file list, there is one noticeable difference when comparing it to fedora-23-dvm folder. For my template volatile.img is chmod 600 while it is 644 in fedora-23-dvm. Changing the permissions to match 644 does not change anything, the problem still exists
write access.
(...)
> -rw-rw-r-- 1 user qubes 1669 Jun 2 20:15 disp8.conf
> -rw-rw-r-- 1 user qubes 1670 Jun 2 20:15 disp9.conf
> -rw-rw-r-- 1 user qubes 309223442 Jul 21 09:49 dvm-savefile
> -rw-rw-r-- 1 user qubes 1925 Jul 21 09:49 fedora-23-stable-dvm.conf
> lrwxrwxrwx 1 user qubes 55 Mar 31 16:15 icon.png -> /usr/share/icons/hicolor/128x128/devices/appvm-gray.png
> -rw-rw-r-- 1 user qubes 1 Jul 21 09:49 netvm-id.txt
> -rw-rw---- 1 user qubes 2147483648 Jul 21 09:49 private.img
> -rw-rw-r-- 1 user qubes 1024 Jul 21 09:49 saved-cows.tar
> -rw------- 1 root qubes 12348030976 Jul 26 20:00 volatile.img
> -rw-rw-r-- 1 user qubes 70 Mar 31 16:15 whitelisted-appmenus.list
- --
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-----
Version: GnuPG v2
iQEbBAEBCAAGBQJXpGMTAAoJENuP0xzK19cs3nQH92oO91qw15Sa0f8jTAWbFtGX
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-----
Version: GnuPG v2
pzVsXwH2i5jd9ctMufe6kqzAua32Bhuzyouj89F5XfD2CHUGpIA6W998P46RtxNG
FGDpyT20gKSpdfZlfpwwZGDlDCp4cbfiep15cSnC+yLhr8knTUBTlP+co9rXUyhk
7a/Ut7C8YknTLogkuHl7zfwodpi6ZUS+Iae4/4H2BJKMTeTS+Z0/OgpQUuI8aOXH
oESm6aTqkcrync2kLx8XZBkaBoXWdgj7W/Ram4bKNUO6p+k7oA7DrnpwRNsikt3M
0g0Yx97AN6qeZfsUgjqP219GqM0AqzN55k6nfLDkn12HkJSbLh+a5bvlY9LPuQ==
=pj6H
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Aug 5, 2016, 7:35:46 AM8/5/16
to cubit, Andrew David Wong, Qubes Users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Fri, Aug 05, 2016 at 11:57:38AM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Jul 27, 2016 at 10:38:52AM +0100, cubit wrote:
> > 26. Jul 2016 23:14 by marm...@invisiblethingslab.com:
> >
> > > Check file list in /var/lib/qubes/appvms/fedora-23-dvm. Especially date
> > > and permissions of volatile.img there.
> > >
> >
> >
> >
> >
> > It's actually fedora-23-stable-dvm based off a copy of the template
> >
> >
> >
> >
> > Here is the file list, there is one noticeable difference when comparing it to fedora-23-dvm folder. For my template volatile.img is chmod 600 while it is 644 in fedora-23-dvm. Changing the permissions to match 644 does not change anything, the problem still exists
>
> Change it to 664 (same as other files there) - so qubes group will have
> write access.
What are permissions on the directory itself?
> On Wed, Jul 27, 2016 at 10:38:52AM +0100, cubit wrote:
> > 26. Jul 2016 23:14 by marm...@invisiblethingslab.com:
> >
> > > Check file list in /var/lib/qubes/appvms/fedora-23-dvm. Especially date
> > > and permissions of volatile.img there.
> > >
> >
> >
> >
> >
> > It's actually fedora-23-stable-dvm based off a copy of the template
> >
> >
> >
> >
> > Here is the file list, there is one noticeable difference when comparing it to fedora-23-dvm folder. For my template volatile.img is chmod 600 while it is 644 in fedora-23-dvm. Changing the permissions to match 644 does not change anything, the problem still exists
>
> Change it to 664 (same as other files there) - so qubes group will have
> write access.
>
> (...)
>
> > -rw-rw-r-- 1 user qubes 1669 Jun 2 20:15 disp8.conf
> > -rw-rw-r-- 1 user qubes 1670 Jun 2 20:15 disp9.conf
> > -rw-rw-r-- 1 user qubes 309223442 Jul 21 09:49 dvm-savefile
> > -rw-rw-r-- 1 user qubes 1925 Jul 21 09:49 fedora-23-stable-dvm.conf
> > lrwxrwxrwx 1 user qubes 55 Mar 31 16:15 icon.png -> /usr/share/icons/hicolor/128x128/devices/appvm-gray.png
> > -rw-rw-r-- 1 user qubes 1 Jul 21 09:49 netvm-id.txt
> > -rw-rw---- 1 user qubes 2147483648 Jul 21 09:49 private.img
> > -rw-rw-r-- 1 user qubes 1024 Jul 21 09:49 saved-cows.tar
> > -rw------- 1 root qubes 12348030976 Jul 26 20:00 volatile.img
> > -rw-rw-r-- 1 user qubes 70 Mar 31 16:15 whitelisted-appmenus.list
>
- --
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-----
Version: GnuPG v2
ty7yGvqGxqNkc9DNnfBKux8QCM2ABTmrWLD5o+HpouE72mOGH4NrmjcoKfdZErL8
iGLRKnVtD+1UV7BjMgArAeOEmUZInIWWB+ZD9wxIzx5c7cPnEoGgPiKJ8E6QdluI
+Af5C6pbi6XQxQIXjLq2EeMEfV9EDRKLMj3BuVGoNTrxBMRGt9w4hFCuJegfGvIk
9ag9gIzj7Gqj7eciI5Y2rO1VbJtpc9RfMis9Qxx7C/V3o24HkCirYogUshVnKmz7
49X6Bur22TD1W+9Y1q7hAWce3su9irlDd/3+8MJB4+hKcUfOER/C3zNJPTaz1ws=
=nK5l
-----END PGP SIGNATURE-----
HW42
Aug 5, 2016, 9:49:59 AM8/5/16
to Marek Marczykowski-Górecki, cubit, Andrew David Wong, Qubes Users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Marek Marczykowski-Górecki:
>> Change it to 664 (same as other files there) - so qubes group will have
>> write access.
>
> What are permissions on the directory itself?
>
>
>> (...)
>
>>> -rw-rw-r-- 1 user qubes 1669 Jun 2 20:15 disp8.conf
>>> -rw-rw-r-- 1 user qubes 1670 Jun 2 20:15 disp9.conf
>>> -rw-rw-r-- 1 user qubes 309223442 Jul 21 09:49 dvm-savefile
>>> -rw-rw-r-- 1 user qubes 1925 Jul 21 09:49 fedora-23-stable-dvm.conf
>>> lrwxrwxrwx 1 user qubes 55 Mar 31 16:15 icon.png -> /usr/share/icons/hicolor/128x128/devices/appvm-gray.png
>>> -rw-rw-r-- 1 user qubes 1 Jul 21 09:49 netvm-id.txt
>>> -rw-rw---- 1 user qubes 2147483648 Jul 21 09:49 private.img
>>> -rw-rw-r-- 1 user qubes 1024 Jul 21 09:49 saved-cows.tar
>>> -rw------- 1 root qubes 12348030976 Jul 26 20:00 volatile.img
>>> -rw-rw-r-- 1 user qubes 70 Mar 31 16:15 whitelisted-appmenus.list
One case in which this happens is when the root user has a restrictive
umask. Then prepare-volatile-img.sh creates a file as show above.
qubes-prepare-saved-domain.sh then fails siletly to include volatile.img
into saved-cows.tar.
This can be simply fixed by not running prepare-volatile-img.sh as root
(see attached patch, sudo is no longer necessary there).
But I'm not sure if this is the problem in the reported cases.
Especially this should be rather easily noticed since you can't start
a dispvm when another is still running.
What are the reasons for using bsdtar instead of tar? I tried to make
the script to fail in this case but bsdtar justs prints a warning on
permission errors and still exits with 0 (in contrast to GNU tar).
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXpJl2AAoJEOSsySeKZGgWFFIQALrQQB4n7uGNpsbdlopX166W
8sqACeMwJ5eozMt8uZ0g6IalfCUW58YSKCYPtepUxN1I7S3hxVBHQcx0M3q2yxhJ
LMmsAv7YdzFOxEr1oS+2UsmHJfuhCJjWMYEoIjTgskSVzB1Gd8vENptSPGUZedd9
IOYxfxIzahhx/2jYd5YdilqtW94Nr8iGCGVAqCnibE0oac16y5NTmSa4WP0gv4ou
QBuj5ejm7VrUDbsexdzxOVR33AeGv4kize+PT23WDVM8Fjr3Nt60zUhFRVUY6eSD
eSFmXw/re+KR9wweUiQBhtDk8WFFMkzSEBeh0Qxfs3SN7x2LeRLjIn+n5ns55TFA
wIRMkfGykyAC9k468bkjcE4pUJs8EfTnKc6yNmFVn68Jxpip3R90hb4orgtdLEQc
OeP7XERg/s78QDgjPod3CnroMKy7wTFQxsCgAFHpDiQKVNCSfQvGURMwcz/Mw37t
+FAnCK85BMgKF0CsTHWoF+KXmTI5VqyrbfFElKHxtuJ+yQCJfWj0JyqudQ5Ff7Sd
u9dZY1txUD5NJ3mPHISLRGzPEzdm/O1YDsNMEPu8ofGOK+fKDsQWlQWeXBVhD5pn
7SU/NXUvVjo5jK6Ii22QIch1IVehWdcjYahMpCOdZcR5kDoerksnYkWosUo/giO7
O2o/oh3+rIqIit705cTF
=cWHQ
-----END PGP SIGNATURE-----
Hash: SHA512
Marek Marczykowski-Górecki:
> On Fri, Aug 05, 2016 at 11:57:38AM +0200, Marek Marczykowski-Górecki wrote:
>> On Wed, Jul 27, 2016 at 10:38:52AM +0100, cubit wrote:
>>> 26. Jul 2016 23:14 by marm...@invisiblethingslab.com:
>>>
>>>> Check file list in /var/lib/qubes/appvms/fedora-23-dvm. Especially date
>>>> and permissions of volatile.img there.
>>>>
>>>
>>>
>>>
>>>
>>> It's actually fedora-23-stable-dvm based off a copy of the template
>>>
>>>
>>>
>>>
>>> Here is the file list, there is one noticeable difference when
>>> comparing it to fedora-23-dvm folder. For my template
>>> volatile.img is chmod 600 while it is 644 in fedora-23-dvm.
>>> Changing the permissions to match 644 does not change anything, the
>>> problem still exists
@cubit: What is the output of 'sudo sh -c umask' in dom0?
>> On Wed, Jul 27, 2016 at 10:38:52AM +0100, cubit wrote:
>>> 26. Jul 2016 23:14 by marm...@invisiblethingslab.com:
>>>
>>>> Check file list in /var/lib/qubes/appvms/fedora-23-dvm. Especially date
>>>> and permissions of volatile.img there.
>>>>
>>>
>>>
>>>
>>>
>>> It's actually fedora-23-stable-dvm based off a copy of the template
>>>
>>>
>>>
>>>
>>> Here is the file list, there is one noticeable difference when
>>> comparing it to fedora-23-dvm folder. For my template
>>> volatile.img is chmod 600 while it is 644 in fedora-23-dvm.
>>> Changing the permissions to match 644 does not change anything, the
>>> problem still exists
>> Change it to 664 (same as other files there) - so qubes group will have
>> write access.
>
> What are permissions on the directory itself?
>
>
>> (...)
>
>>> -rw-rw-r-- 1 user qubes 1669 Jun 2 20:15 disp8.conf
>>> -rw-rw-r-- 1 user qubes 1670 Jun 2 20:15 disp9.conf
>>> -rw-rw-r-- 1 user qubes 309223442 Jul 21 09:49 dvm-savefile
>>> -rw-rw-r-- 1 user qubes 1925 Jul 21 09:49 fedora-23-stable-dvm.conf
>>> lrwxrwxrwx 1 user qubes 55 Mar 31 16:15 icon.png -> /usr/share/icons/hicolor/128x128/devices/appvm-gray.png
>>> -rw-rw-r-- 1 user qubes 1 Jul 21 09:49 netvm-id.txt
>>> -rw-rw---- 1 user qubes 2147483648 Jul 21 09:49 private.img
>>> -rw-rw-r-- 1 user qubes 1024 Jul 21 09:49 saved-cows.tar
>>> -rw------- 1 root qubes 12348030976 Jul 26 20:00 volatile.img
>>> -rw-rw-r-- 1 user qubes 70 Mar 31 16:15 whitelisted-appmenus.list
umask. Then prepare-volatile-img.sh creates a file as show above.
qubes-prepare-saved-domain.sh then fails siletly to include volatile.img
into saved-cows.tar.
This can be simply fixed by not running prepare-volatile-img.sh as root
(see attached patch, sudo is no longer necessary there).
But I'm not sure if this is the problem in the reported cases.
Especially this should be rather easily noticed since you can't start
a dispvm when another is still running.
What are the reasons for using bsdtar instead of tar? I tried to make
the script to fail in this case but bsdtar justs prints a warning on
permission errors and still exits with 0 (in contrast to GNU tar).
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXpJl2AAoJEOSsySeKZGgWFFIQALrQQB4n7uGNpsbdlopX166W
8sqACeMwJ5eozMt8uZ0g6IalfCUW58YSKCYPtepUxN1I7S3hxVBHQcx0M3q2yxhJ
LMmsAv7YdzFOxEr1oS+2UsmHJfuhCJjWMYEoIjTgskSVzB1Gd8vENptSPGUZedd9
IOYxfxIzahhx/2jYd5YdilqtW94Nr8iGCGVAqCnibE0oac16y5NTmSa4WP0gv4ou
QBuj5ejm7VrUDbsexdzxOVR33AeGv4kize+PT23WDVM8Fjr3Nt60zUhFRVUY6eSD
eSFmXw/re+KR9wweUiQBhtDk8WFFMkzSEBeh0Qxfs3SN7x2LeRLjIn+n5ns55TFA
wIRMkfGykyAC9k468bkjcE4pUJs8EfTnKc6yNmFVn68Jxpip3R90hb4orgtdLEQc
OeP7XERg/s78QDgjPod3CnroMKy7wTFQxsCgAFHpDiQKVNCSfQvGURMwcz/Mw37t
+FAnCK85BMgKF0CsTHWoF+KXmTI5VqyrbfFElKHxtuJ+yQCJfWj0JyqudQ5Ff7Sd
u9dZY1txUD5NJ3mPHISLRGzPEzdm/O1YDsNMEPu8ofGOK+fKDsQWlQWeXBVhD5pn
7SU/NXUvVjo5jK6Ii22QIch1IVehWdcjYahMpCOdZcR5kDoerksnYkWosUo/giO7
O2o/oh3+rIqIit705cTF
=cWHQ
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Aug 5, 2016, 10:18:50 AM8/5/16
to HW42, cubit, Andrew David Wong, Qubes Users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Good catch!
> This can be simply fixed by not running prepare-volatile-img.sh as root
> (see attached patch, sudo is no longer necessary there).
>
> But I'm not sure if this is the problem in the reported cases.
> Especially this should be rather easily noticed since you can't start
> a dispvm when another is still running.
>
> What are the reasons for using bsdtar instead of tar?
Much better handling of sparse files:
[user@testvm tmp]$ echo test > test.img
[user@testvm tmp]$ truncate -s 1G test.img
[user@testvm tmp]$ time tar cSf test.img.tar test.img
real 0m5.372s
user 0m1.684s
sys 0m3.682s
[user@testvm tmp]$ time bsdtar cSf test.img.bsdtar test.img
real 0m0.069s
user 0m0.001s
sys 0m0.031s
It's because bsdtar uses FS_IOC_FIEMAP ioctl to get file map, while GNU
tar simply reads the file and treats zeroed blocks as holes. AFAIR it
was design decision.
> I tried to make
> the script to fail in this case but bsdtar justs prints a warning on
> permission errors and still exits with 0 (in contrast to GNU tar).
Maybe add a [ -r volatie.img ] check instead? Or better: expect empty
stderr?
- --
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-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXpKA8AAoJENuP0xzK19csnSoH/jNf6Wyl6cD0QlJeXL3g5vmX
1y6h3zu1ORovDQ7kKsQSovYWr8hKfDfxwz1jaD4Vt3TcqYntaexD2TBQOWJ6Z4aX
ezFSeqj2drekZ0nH4yk2fKw2PQ7CyT3co+8aLsoyTYQynkmPSeH9ZH5kwMazapdL
SZuKsKqM5y5PqbJqkC9uutPezAK5UN5XRloLNhLswOvSc2CcRakW1c0F29oxo9AD
sG3ceTeYTt5ChlRbWwHQBl96gA5+f40U8yKVsdxLJ9Hch+p9fk2CD3vPn1C4RgMh
uHmfVV0UB/XQ7e/a80Qyrz46RidM+NpS0oJ6bPFrW8KwKCJ7YOQLgXyo97Gdo24=
=VJNH
-----END PGP SIGNATURE-----
Hash: SHA256
> This can be simply fixed by not running prepare-volatile-img.sh as root
> (see attached patch, sudo is no longer necessary there).
>
> But I'm not sure if this is the problem in the reported cases.
> Especially this should be rather easily noticed since you can't start
> a dispvm when another is still running.
>
> What are the reasons for using bsdtar instead of tar?
[user@testvm tmp]$ echo test > test.img
[user@testvm tmp]$ truncate -s 1G test.img
[user@testvm tmp]$ time tar cSf test.img.tar test.img
real 0m5.372s
user 0m1.684s
sys 0m3.682s
[user@testvm tmp]$ time bsdtar cSf test.img.bsdtar test.img
real 0m0.069s
user 0m0.001s
sys 0m0.031s
It's because bsdtar uses FS_IOC_FIEMAP ioctl to get file map, while GNU
tar simply reads the file and treats zeroed blocks as holes. AFAIR it
was design decision.
> I tried to make
> the script to fail in this case but bsdtar justs prints a warning on
> permission errors and still exits with 0 (in contrast to GNU tar).
stderr?
- --
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-----
Version: GnuPG v2
1y6h3zu1ORovDQ7kKsQSovYWr8hKfDfxwz1jaD4Vt3TcqYntaexD2TBQOWJ6Z4aX
ezFSeqj2drekZ0nH4yk2fKw2PQ7CyT3co+8aLsoyTYQynkmPSeH9ZH5kwMazapdL
SZuKsKqM5y5PqbJqkC9uutPezAK5UN5XRloLNhLswOvSc2CcRakW1c0F29oxo9AD
sG3ceTeYTt5ChlRbWwHQBl96gA5+f40U8yKVsdxLJ9Hch+p9fk2CD3vPn1C4RgMh
uHmfVV0UB/XQ7e/a80Qyrz46RidM+NpS0oJ6bPFrW8KwKCJ7YOQLgXyo97Gdo24=
=VJNH
-----END PGP SIGNATURE-----
Jimmy Axenhus
Aug 6, 2016, 2:22:15 PM8/6/16
to HW42, Marek Marczykowski-Górecki, cubit, Andrew David Wong, Qubes Users
and discovered that there was some history left from another one I had
running earlier. I tried starting another disposable VM again without
closing the buggy one, but it won't start. I know that behavior is
another bug, but perhaps they are related somehow? I should note that
the current uptime is 6-7 hours, yet I've had longer uptimes than that
and not run into this bug before.
I know the workarounds are to regenerate the disposable VM file and to
reboot the computer to solve the VMs not being created.
I've collected some information, but I don't know if it will help. If
it's relevant the last disposable VM that started successfully was the
one with the leftover history and it has the name disp6. Anything else
that might be interesting before I reboot?
[user@dom0 ~]$ file /var/lib/qubes/appvms/fedora-23-dvm/
/var/lib/qubes/appvms/fedora-23-dvm/: setgid, directory
[user@dom0 ~]$ ls /var/lib/qubes/appvms/fedora-23-dvm/
disp10.conf disp2.conf disp4.conf disp6.conf disp8.conf
dvm-savefile icon.png private.img whitelisted-appmenus.list
disp1.conf disp3.conf disp5.conf disp7.conf disp9.conf
fedora-23-dvm.conf netvm-id.txt saved-cows.tar volatile.img
[user@dom0 ~]$ ls -lh /var/lib/qubes/appvms/fedora-23-dvm/
/var/lib/qubes/appvms/fedora-23-dvm/:
totalt 436M
-rw-rw-r-- 1 user qubes 1,7K 5 aug 19.30 disp10.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 13.56 disp1.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 14.14 disp2.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 15.21 disp3.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 15.32 disp4.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 15.40 disp5.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 19.51 disp6.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 19.56 disp7.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 19.57 disp8.conf
-rw-rw-r-- 1 user qubes 1,7K 5 aug 18.54 disp9.conf
-rw-rw---- 1 user qubes 295M 6 aug 12.12 dvm-savefile
-rw-rw-r-- 1 user qubes 1,9K 6 aug 12.12 fedora-23-dvm.conf
lrwxrwxrwx 1 user qubes 55 28 jul 16.42 icon.png ->
/usr/share/icons/hicolor/128x128/devices/appvm-gray.png
-rw-rw---- 1 user qubes 1 6 aug 12.12 netvm-id.txt
-rw-rw---- 1 user qubes 2,0G 6 aug 12.12 private.img
-rw-rw---- 1 user qubes 1,0K 6 aug 12.12 saved-cows.tar
-rw-rw-r-- 1 user qubes 70 28 jul 16.42 whitelisted-appmenus.list
-rw------- 1 root qubes 12G 6 aug 20.02 volatile.img
[user@dom0 ~]$ date
lör aug 6 20:02:50 CEST 2016
#### I paused here for a while before checking again ####
[user@dom0 ~]$ ls -lh /var/lib/qubes/appvms/fedora-23-dvm/
totalt 436M
-rw-rw-r-- 1 user qubes 1,7K 5 aug 19.30 disp10.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 13.56 disp1.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 14.14 disp2.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 15.21 disp3.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 15.32 disp4.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 15.40 disp5.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 19.51 disp6.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 19.56 disp7.conf
-rw-rw-r-- 1 user qubes 1,7K 6 aug 19.57 disp8.conf
-rw-rw-r-- 1 user qubes 1,7K 5 aug 18.54 disp9.conf
-rw-rw---- 1 user qubes 295M 6 aug 12.12 dvm-savefile
-rw-rw-r-- 1 user qubes 1,9K 6 aug 12.12 fedora-23-dvm.conf
lrwxrwxrwx 1 user qubes 55 28 jul 16.42 icon.png ->
/usr/share/icons/hicolor/128x128/devices/appvm-gray.png
-rw-rw---- 1 user qubes 1 6 aug 12.12 netvm-id.txt
-rw-rw---- 1 user qubes 2,0G 6 aug 12.12 private.img
-rw-rw---- 1 user qubes 1,0K 6 aug 12.12 saved-cows.tar
-rw-rw-r-- 1 user qubes 70 28 jul 16.42 whitelisted-appmenus.list
-rw------- 1 root qubes 12G 6 aug 20.03 volatile.img
[user@dom0 ~]$ date
lör aug 6 20:03:50 CEST 2016
[user@dom0 ~]$ ls -lh /var/lib/qubes/appvms/ | grep fedora-23-dvm
drwxrwsr-x 1 user qubes 426 6 aug 19.57 fedora-23-dvm
[user@dom0 ~]$ sudo sh -c umask
0022
[user@dom0 ~]$
Reply all
Reply to author
Forward
0 new messages