Here are instructions on how to update Fedora 20 templates to 21

[nrgaway]

I created some instructions on how to update a Fedora 20 template to Fedora 21 based on the existing wiki instructions.  I hope someone finds it useful :)

One thing to note is that updates through qubes-manager GUI do not currently work.  They will have to be done manually within a gnome-terminal or xterm session.

Upgrading Fedora 20 to Fedora 21

Commands to run in dom0 console (you can do the same from Qubes Manager):

qvm-clone fedora-20-x64 fedora-21
qvm-run -a fedora-21 gnome-terminal

Update instructions if fedora-21 template has at least 3GB free space.

Commands to run in new fedora-21 template:

sudo yum erase nautilus-actions
sudo yum clean all

# For release 2 of Qubes
sudo yum --enablerepo=qubes-vm-r2-current-testing --releasever=21 distro-sync

# For release 3 of Qubes
sudo yum --enablerepo=qubes-vm-r3.0-current-testing --releasever=21 distro-sync

sudo cp /usr/lib/qubes/init/ip* /etc/syconfig/

# poweroff via qubes-manager; may need to be killed


Update instructions if fedora-21 template DOES NOT have at least 3GB free space

If you have installed a lot of software in your template, it may happen that you don’t have enough disk space for upgrade. Yum will tell you this just after confirming the operation (before it change anything to your system). In that case you need to provide some “external” place for yum cache (uses about 3GB during upgrade). After being notified by yum that you need more disk space to perform the upgrade, leave the fedora-21 template running and proceed to create and attach additional storage.

Prepare the file in dom0 (Be sure the new fedora-21 TemplateVM is still running gnome-terminal):

truncate -s 5GB /var/tmp/template-upgrade-cache.img
qvm-block -A fedora-21 dom0:/var/tmp/template-upgrade-cache.img

Then use it in template:

sudo mkfs.ext4 /dev/xvdi
sudo mount /dev/xvdi /mnt/removable

sudo cp -p /etc/sysconfig/ip* /home/user
sudo yum erase nautilus-actions
sudo yum clean all

# For release 2 of Qubes
sudo yum --enablerepo=qubes-vm-r2-current-testing --releasever=21 --setopt=cachedir=/mnt/removable distro-sync

# For release 3 of Qubes
sudo yum --enablerepo=qubes-vm-r3.0-current-testing --releasever=21 --setopt=cachedir=/mnt/removable distro-sync

sudo cp /usr/lib/qubes/init/ip* /etc/syconfig/

# poweroff via qubes-manager; may need to be killed

After upgrade is finished, you can remove /var/tmp/template-upgrade-cache.img file.

If yum complains that there is not enough free space in /usr/lib/modules, try this:

sudo mkdir /mnt/removable/modules
sudo cp -rp /usr/lib/modules /mnt/removable/modules/
sudo mount --bind /mnt/removable/modules /usr/lib/modules

Starting the newly created fedora-21 TemplateVM for the first time
Either start the new template via qubes-manager or in dom0:

qvm-run -a fedora-21 gnome-terminal

Once started, within gnome-terminal, we need to make sure everything is up-to-date. Most likely some more packages will be installed to satisfy the upgrade dependencies

sudo yum upgrade

Compacting templates root.img

fstrim, nor “discard” mount option do not work on template root fs, so when some file is removed in the template, space isn’t freed in dom0. This means that template will use about twice a space that is really need after upgrade.

In dom0 console (broken in Qubes R3-RC1):

qvm-trim-template fedora-21

You can compact root.img in the “old way” instead of using qvm-trim-template. You’ll need about 15GB (template’s max size + really used space there) in dom0 for this operation: Start the template, fill all the free space with zeros, for example with:

dd if=/dev/zero of=/zero
(wait for "No space left on device" error)
rm -f /zero

# Note: wiki states to use of=/var/tmp/zero. I wasn't sure if it was mapped to memory so changed it to /zero

Then shutdown template and all VMs based on it. Go into template directory in dom0 (/var/lib/qubes/vm-templates/fedora-21 or so) and issue:

cp --sparse=always root.img root.img.new
mv root.img.new root.img

[Franz]

On Fri, Jun 12, 2015 at 11:00 PM, nrgaway <nrg...@gmail.com> wrote:

I created some instructions on how to update a Fedora 20 template to Fedora 21 based on the existing wiki instructions.  I hope someone finds it useful :)

One thing to note is that updates through qubes-manager GUI do not currently work.  They will have to be done manually within a gnome-terminal or xterm session.

Upgrading Fedora 20 to Fedora 21

Commands to run in dom0 console (you can do the same from Qubes Manager):

qvm-clone fedora-20-x64 fedora-21
qvm-run -a fedora-21 gnome-terminal

Update instructions if fedora-21 template has at least 3GB free space.

Commands to run in new fedora-21 template:

sudo yum erase nautilus-actions
sudo yum clean all

# For release 2 of Qubes
sudo yum --enablerepo=qubes-vm-r2-current-testing --releasever=21 distro-sync

# For release 3 of Qubes
sudo yum --enablerepo=qubes-vm-r3.0-current-testing --releasever=21 distro-sync

sudo cp /usr/lib/qubes/init/ip* /etc/syconfig/

# poweroff via qubes-manager; may need to be killed


This one worked for the smaller template, with the addition of

"If yum complains that there is not enough free space in /usr/lib/modules, try this:"

 Thanks
 

Update instructions if fedora-21 template DOES NOT have at least 3GB free space

If you have installed a lot of software in your template, it may happen that you don’t have enough disk space for upgrade. Yum will tell you this just after confirming the operation (before it change anything to your system). In that case you need to provide some “external” place for yum cache (uses about 3GB during upgrade). After being notified by yum that you need more disk space to perform the upgrade, leave the fedora-21 template running and proceed to create and attach additional storage.

Prepare the file in dom0 (Be sure the new fedora-21 TemplateVM is still running gnome-terminal):

truncate -s 5GB /var/tmp/template-upgrade-cache.img
qvm-block -A fedora-21 dom0:/var/tmp/template-upgrade-cache.img

Then use it in template:

sudo mkfs.ext4 /dev/xvdi
sudo mount /dev/xvdi /mnt/removable

sudo cp -p /etc/sysconfig/ip* /home/user
sudo yum erase nautilus-actions
sudo yum clean all

# For release 2 of Qubes
sudo yum --enablerepo=qubes-vm-r2-current-testing --releasever=21 --setopt=cachedir=/mnt/removable distro-sync

# For release 3 of Qubes
sudo yum --enablerepo=qubes-vm-r3.0-current-testing --releasever=21 --setopt=cachedir=/mnt/removable distro-sync

sudo cp /usr/lib/qubes/init/ip* /etc/syconfig/

# poweroff via qubes-manager; may need to be killed

This one is NOT working for the larger template. I spent the whole saturday trying a retrying. I also tried to increase the space for truncate to 7GB, but the final result, after a couple of hours crunching is always the same, only the numbers change. I paste here only the final piece, but the list of non installed packages is much longer:

  installing package libasyncns-0.8-8.fc21.i686 needs 359MB on the / filesystem
  installing package pulseaudio-libs-6.0-2.fc21.1.i686 needs 360MB on the / filesystem
  installing package qt-mobility-multimediakit-1.2.2-0.17.20140317git169da60c.fc21.i686 needs 362MB on the / filesystem
  installing package qt-mobility-feedback-1.2.2-0.17.20140317git169da60c.fc21.i686 needs 360MB on the / filesystem
  installing package wine-pulseaudio-1.7.44-1.fc21.i686 needs 360MB on the / filesystem
  installing package wine-1.7.44-1.fc21.x86_64 needs 360MB on the / filesystem
  installing package qt-mobility-1.2.2-0.17.20140317git169da60c.fc21.i686 needs 360MB on the / filesystem
  installing package upower-0.99.2-4.fc21.i686 needs 361MB on the / filesystem
  installing package polkit-0.112-7.fc21.1.i686 needs 361MB on the / filesystem
  installing package qtwebkit-2.3.4-6.fc21.i686 needs 434MB on the / filesystem
  installing package libXmu-1.1.2-2.fc21.i686 needs 365MB on the / filesystem
  installing package libXScrnSaver-1.2.2-8.fc21.i686 needs 365MB on the / filesystem
  installing package lcms-libs-1.19-13.fc21.i686 needs 365MB on the / filesystem

Error Summary
-------------
Disk Requirements:
  At least 505MB more space needed on the / filesystem.

After upgrade is finished, you can remove /var/tmp/template-upgrade-cache.img file.

If yum complains that there is not enough free space in /usr/lib/modules, try this:

sudo mkdir /mnt/removable/modules
sudo cp -rp /usr/lib/modules /mnt/removable/modules/
sudo mount --bind /mnt/removable/modules /usr/lib/modules

Starting the newly created fedora-21 TemplateVM for the first time
Either start the new template via qubes-manager or in dom0:

qvm-run -a fedora-21 gnome-terminal

Once started, within gnome-terminal, we need to make sure everything is up-to-date. Most likely some more packages will be installed to satisfy the upgrade dependencies

sudo yum upgrade

Compacting templates root.img

fstrim, nor “discard” mount option do not work on template root fs, so when some file is removed in the template, space isn’t freed in dom0. This means that template will use about twice a space that is really need after upgrade.

In dom0 console (broken in Qubes R3-RC1):

qvm-trim-template fedora-21

If the above simple line achieves the same result as the more complex procedure below,  up to the end of your instructions, why should one bother considering the complex procedure? Only in the case the single line gives errors?

You can compact root.img in the “old way” instead of using qvm-trim-template. You’ll need about 15GB (template’s max size + really used space there) in dom0 for this operation: Start the template, fill all the free space with zeros, for example with:

dd if=/dev/zero of=/zero
(wait for "No space left on device" error)
rm -f /zero

# Note: wiki states to use of=/var/tmp/zero. I wasn't sure if it was mapped to memory so changed it to /zero

Then shutdown template and all VMs based on it. Go into template directory in dom0 (/var/lib/qubes/vm-templates/fedora-21 or so) and issue:

cp --sparse=always root.img root.img.new
mv root.img.new root.img

Is  the last paragraph above part of the more complex procedure, or should it be performed also using qvm-trim-template?

Best

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAMWEgd%3DPB5T9SOUymJxjTU4rO-R6QHHY%3D0scwdvt8VyS8WVXUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[nrgaway]

How much free space do you have on the larger template before attempting the yum upgrade?  Fedora 21 may take up more space than Fefora 20 so you may need to increase the size of the root template itself or free up additional space.

After upgrade is finished, you can remove /var/tmp/template-upgrade-cache.img file.

If yum complains that there is not enough free space in /usr/lib/modules, try this:

sudo mkdir /mnt/removable/modules
sudo cp -rp /usr/lib/modules /mnt/removable/modules/
sudo mount --bind /mnt/removable/modules /usr/lib/modules

Starting the newly created fedora-21 TemplateVM for the first time
Either start the new template via qubes-manager or in dom0:

qvm-run -a fedora-21 gnome-terminal

Once started, within gnome-terminal, we need to make sure everything is up-to-date. Most likely some more packages will be installed to satisfy the upgrade dependencies

sudo yum upgrade

Compacting templates root.img

fstrim, nor “discard” mount option do not work on template root fs, so when some file is removed in the template, space isn’t freed in dom0. This means that template will use about twice a space that is really need after upgrade.

In dom0 console (broken in Qubes R3-RC1):

qvm-trim-template fedora-21

If the above simple line achieves the same result as the more complex procedure below,  up to the end of your instructions, why should one bother considering the complex procedure? Only in the case the single line gives errors?

If you look closely I state (highlighted in yellow above) the simple procedure is broken in Release 3. So in Qubes release 3 you will need to follow the procedure below, otherwise the one-line is all you need.
 

[nrgaway]

To increase the size of the new Fedora 21 template, I think you can use the command qvm-grow-root (I have never used it, so this is a guess):

qvm-grow-root fedora-21 15GB

The last paragraph is part of the more complet procedure.  If the one-liner works out for you, then you are done!
 

[Franz]

this is space  on Fedora 20
[user@fedora-20-x64-multimedia ~]$ df -h
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/dmroot  9.8G  7.9G  1.4G  86% /
devtmpfs                    150M     0  150M   0% /dev
tmpfs                          160M   68K  160M   1% /dev/shm
tmpfs                          160M  520K  160M   1% /run
tmpfs                          160M     0  160M   0% /sys/fs/cgroup
/dev/xvdd                   388M  166M  202M  46% /usr/lib/modules
tmpfs                         160M   12K  160M   1% /tmp
/dev/xvdb                  2.0G  380M  1.6G  20% /rw

this is space on Fedora 21 cloned template after the failed update
[user@fedora-21-multimedia ~]$ df -h
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/dmroot  9.8G  7.9G  1.4G  85% /
devtmpfs                    150M     0  150M   0% /dev
tmpfs                          160M   68K  160M   1% /dev/shm
tmpfs                          160M  528K  160M   1% /run
tmpfs                          160M     0  160M   0% /sys/fs/cgroup
tmpfs                          160M  4.5M  156M   3% /tmp
/dev/xvdb                    2.0G  380M  1.6G  20% /rw
/dev/xvdi                     6.3G  2.0G  4.0G  33% /mnt/removable

 

To increase the size of the new Fedora 21 template, I think you can use the command qvm-grow-root (I have never used it, so this is a guess):

qvm-grow-root fedora-21 15GB

Do you know how much is default template size?

 

After upgrade is finished, you can remove /var/tmp/template-upgrade-cache.img file.

If yum complains that there is not enough free space in /usr/lib/modules, try this:

sudo mkdir /mnt/removable/modules
sudo cp -rp /usr/lib/modules /mnt/removable/modules/
sudo mount --bind /mnt/removable/modules /usr/lib/modules

Starting the newly created fedora-21 TemplateVM for the first time
Either start the new template via qubes-manager or in dom0:

qvm-run -a fedora-21 gnome-terminal

Once started, within gnome-terminal, we need to make sure everything is up-to-date. Most likely some more packages will be installed to satisfy the upgrade dependencies

sudo yum upgrade

Compacting templates root.img

fstrim, nor “discard” mount option do not work on template root fs, so when some file is removed in the template, space isn’t freed in dom0. This means that template will use about twice a space that is really need after upgrade.

In dom0 console (broken in Qubes R3-RC1):

qvm-trim-template fedora-21

If the above simple line achieves the same result as the more complex procedure below,  up to the end of your instructions, why should one bother considering the complex procedure? Only in the case the single line gives errors?

If you look closely I state (highlighted in yellow above) the simple procedure is broken in Release 3. So in Qubes release 3 you will need to follow the procedure below, otherwise the one-line is all you need.

Perfect, now it is very clear
 

 

You can compact root.img in the “old way” instead of using qvm-trim-template. You’ll need about 15GB (template’s max size + really used space there) in dom0 for this operation: Start the template, fill all the free space with zeros, for example with:

dd if=/dev/zero of=/zero
(wait for "No space left on device" error)
rm -f /zero

# Note: wiki states to use of=/var/tmp/zero. I wasn't sure if it was mapped to memory so changed it to /zero

Then shutdown template and all VMs based on it. Go into template directory in dom0 (/var/lib/qubes/vm-templates/fedora-21 or so) and issue:

cp --sparse=always root.img root.img.new
mv root.img.new root.img

Is  the last paragraph above part of the more complex procedure, or should it be performed also using qvm-trim-template?

The last paragraph is part of the more complet procedure.  If the one-liner works out for you, then you are done!
 

Perfect

Anyway, many thanks for this tutorial Nrgaway. Without it I would never have  been able to do anything. But even with the tutorial this procedure is not for everyone. If the developers want to extend the use of Qubes beyond computer professionals and enthusiasts this sort of things should be greatly simplified.

Best

[Derek Fawcus]

Thanks for the instructions, I tried following them, but got a complaint
(not disk space) from yum:

--> Finished Dependency Resolution
Error: Package: 2:libcacard-2.1.3-7.fc21.x86_64 (updates)
Requires: libxenctrl.so.4.4()(64bit)
Available: xen-libs-4.4.1-6.fc21.x86_64 (fedora)
libxenctrl.so.4.4()(64bit)
Available: xen-libs-4.4.2-4.fc21.x86_64 (updates)
libxenctrl.so.4.4()(64bit)
Error: Package: 2:libcacard-2.1.3-7.fc21.x86_64 (updates)
Requires: libxenguest.so.4.4()(64bit)
Available: xen-libs-4.4.1-6.fc21.x86_64 (fedora)
libxenguest.so.4.4()(64bit)
Available: xen-libs-4.4.2-4.fc21.x86_64 (updates)
libxenguest.so.4.4()(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

There was an earlier complaint, but yum seemed to managed despite that:

updates | 4.9 kB 00:00
fedora/21/x86_64/primary_db FAILED
ftp://ftp.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/releases/21/Everything/x86_64/os/repodata/4c0ea0d0ca8fd81fd3a96cacabfbcf9e02c33125670505fcf20aacefab48df02-primary.sqlite.xz: [Errno 14] FTP Error 503 - The requested URL returned error: 503 Could not retrieve all the headers
Trying other mirror.
(1/7): fedora/21/x86_64/group_gz | 232 kB 00:00

So - is there something obvious, other than trying the commands above which yum suggested?

DF

[Derek Fawcus]

On Sun, Jun 14, 2015 at 08:42:31PM +0100, Derek Fawcus wrote:
> Thanks for the instructions, I tried following them, but got a complaint
> (not disk space) from yum:
>
> --> Finished Dependency Resolution
> Error: Package: 2:libcacard-2.1.3-7.fc21.x86_64 (updates)
> Requires: libxenctrl.so.4.4()(64bit)
> Available: xen-libs-4.4.1-6.fc21.x86_64 (fedora)
> libxenctrl.so.4.4()(64bit)
> Available: xen-libs-4.4.2-4.fc21.x86_64 (updates)
> libxenctrl.so.4.4()(64bit)
> Error: Package: 2:libcacard-2.1.3-7.fc21.x86_64 (updates)
> Requires: libxenguest.so.4.4()(64bit)
> Available: xen-libs-4.4.1-6.fc21.x86_64 (fedora)
> libxenguest.so.4.4()(64bit)
> Available: xen-libs-4.4.2-4.fc21.x86_64 (updates)
> libxenguest.so.4.4()(64bit)
> You could try using --skip-broken to work around the problem
> You could try running: rpm -Va --nofiles --nodigest

and I've just now found the earlier messages for the same issue,
where it was stated one should remove libcacard...

DF

[Franz]

what I get here is: "operation  not supported for this VM type"

[Jason M]

Wow, that sucks!

See if you can get about 2GB free on fedora-template clone before updating.  Remove files, move some to /home/user, until you have ~2GB free and try again. 

We will need to get @Marek to look at that "operation  not supported for this VM type" error you experienced trying to use qvm-grow-root, unless that command needs to be run with sudo?
 

sudo qvm-grow-root fedora-21 15GB

[Jason M]

I would try removing it then and copy/paste anything that gets removed into a special file in /home/user so you can attempt to re-install some of those packages if needed after the upgrade. 

[Franz]

sudo does not change the result.

But I managed to delete /var/log/journal/6aa*  also identified the larger packages using:

rpm -qa --queryformat '%10{size} -%-25{name} \t %{version}\n' | sort -n

 then removed the larger less customized packages and finally

sudo yum clean all

and it worked even if it took almost 3 days trying.

Best

 and finally it worked.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cfc153a6-b40a-486e-86fd-335b930315fc%40googlegroups.com.

[Franz]

Qubes R2. After a little testing it seems everything is working, except  netvm and firewallvm. If they are based on fedora-21 template all VMs loose network connection, even if I can ping google.com from netvm terminal. So had to base both of them again  on fedora -20 template.

Any idea to solve this?

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/16/2015 01:11 AM, Franz wrote:
> Qubes R2. After a little testing it seems everything is working,
> except netvm and firewallvm. If they are based on fedora-21
> template all VMs loose network connection, even if I can ping

> google.com <http://google.com> from netvm terminal. So had to base

> both of them again on fedora -20 template.
>
> Any idea to solve this?

Try this in the template:

sudo cp /usr/lib/qubes/init/ip* /etc/syconfig/



- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVf77nAAoJEACyhZsQIQUVzEUP/j4LngajIrjz2tJybd6//5PB
IgARfo4NSOF0qYyo+OfPJ7MgAWiuqFwyIBwr6WJY7AC/NASG3/SdlB/5y92qn/DF
o1GsGn/g4q3RXJf443gDywoaSu6mG+091SJMIEU39r32GKYeSVd9Ym3cgXuXYxwG
47RMh/+My/mmfMiQ8pDYpkHPlf76jrKgOoB5meTUAEtH4ylC165P3QQDSfOsmKrZ
SIPISWzqarSDnkHQdSfbFLytunCCp0u4rnV4stZTc0jMTBsJTV0kBU5NmcY9p+i5
bM2vIaaqkjZnKTUTvag/cQKbOIfatus7hVKTSXbfNErUGZI0LXzjNZNKH8HXFpPU
txtincTkrAyhYJ9A44fp21xkldUi5kzrai706pxsPJQxVHybSNup7m6osITGpqPD
djMVlfUnYXln48AQWc78H3G5J4K8cPKkpdtAz+prgcC2uGSNqlahDid9tfDum0nF
6vRMfoEcY/ZrmB3VW8p2SQIDuI0cLWVfudqtAe3ZSLvsMH9XHIeuaPtdQKukA9Qd
3+JOW4GOifGSFAQq28nsdYP1CuwLgXRAsnh5Wk7/eDNKE8aicG5G8tEp7tWjhc78
tyPCRZdJ6hCVbJ6z2Uvmjf3XZ5YI8M3bQH6BecYZIhgFx4cli9kGdM8/dgQu3yEV
XD0hnHCRmou7re2iTFsv
=Dkb+
-----END PGP SIGNATURE-----

[Franz]

On Tue, Jun 16, 2015 at 3:15 AM, Zrubi <ma...@zrubi.hu> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/16/2015 01:11 AM, Franz wrote:
> Qubes R2. After a little testing it seems everything is working,
> except netvm and firewallvm. If they are based on fedora-21
> template all VMs loose network connection, even if I can ping
> google.com <http://google.com> from netvm terminal. So had to base
> both of them again  on fedora -20 template.
>
> Any idea to solve this?

Try this in the template:

sudo cp /usr/lib/qubes/init/ip* /etc/syconfig/

Many thanks Zrubi, network is back now, but it is "sysconfig"

Best

Fran

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

nrgaway wrote:
> I created some instructions on how to update a Fedora 20 template
> to Fedora 21 based on the existing wiki instructions. I hope
> someone finds it useful :)
>
> One thing to note is that updates through qubes-manager GUI do not
> currently work. They will have to be done manually within a
> gnome-terminal or xterm session.
>

> *Upgrading Fedora 20 to Fedora 21*

>
> Commands to run in dom0 console (you can do the same from Qubes
> Manager): qvm-clone fedora-20-x64 fedora-21 qvm-run -a fedora-21
> gnome-terminal
>

I tried testing these instructions on fedora-20-x64-minimal:

> *Update instructions if fedora-21 template has at least 3GB free
> space.*

>
> Commands to run in new fedora-21 template: sudo yum erase
> nautilus-actions sudo yum clean all
>

This resulted in an error (I'm guessing because the minimal template
doesn't contain nautilus-actions), so I started over and tried again
without this step.

> # For release 2 of Qubes sudo yum
> --enablerepo=qubes-vm-r2-current-testing --releasever=21 distro-
> sync
>

This results in downloading 300-400 packages. I'm not sure if this is
right. It seems like a lot for the minimal template.

No other problems encountered.

Is this correct, or should a different procedure be used to upgrade
minimal templates?
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVhTR+AAoJEJh4Btx1RPV8DgwQALL2u+E/euZDC4loI0JIMo2g
GXNCFEArKyqZvnhkeTEmW0cHTSJZH4Ioxbh8zqcZnhSc8qSEKjhM3O+VN5kTxZcB
gqPWbwJuNOu6lLm20KnC1aSaRdFZ2NvePN/IwSJI3T0seRhdO2vtr45i2aWdAmzW
Rts6IYnfBdMo+7+3or3mrna3FEy9jQUSsLUSWsDPKVUlIUpMkIqEns/qO5eDoMGd
YlfREQQ58W7cD0eWjS6IPZ2lK6WOo5S2iPdXxUlL+3UdA5L2isF8KkLm8SMJlMsy
ag6DsPFWfCOLEcrgZGTnXGftOeRgur/PRyTisSsQ22QvaVmxBY5/yBNJJCoJ5Oy2
KmSBttVfiqQGIrr906F/6PSCBPtEXe6fNAljXPKLFEH+VMv7YvOvIa4354637ATQ
vwU2UnVgYTdb3+nmL3nGqGu/+qogDyVB/umZDbpJjJECURZ8eIFT0QWaOiFzBVIm
ohU01112gGerGvNi81Za9xXv5dRrStja8xPbvw/i93B53a6k/0DWhGwwOiZev0C7
tZ53ok8w6sfNidt6bPaqjmrlIudzh3ANxS1OpwbirHdJ8PFlyaLcbl7fmrqn6LPv
40LQaRE9TYlSderZvb9AsFAQ9s/g3SnfQcPEH2/d5MCH/QNqowwGg3krObANNlXZ
qR/GdyKePCI/6r5NfMTh
=A/Sv
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

nrgaway wrote:

[...]

> Prepare the file in dom0 (Be sure the new fedora-21 TemplateVM is
> still running gnome-terminal): truncate -s 5GB
> /var/tmp/template-upgrade-cache.img qvm-block -A fedora-21
> dom0:/var/tmp/template-upgrade-cache.img
>
> Then use it in template: sudo mkfs.ext4 /dev/xvdi sudo mount
> /dev/xvdi /mnt/removable
>
> sudo cp -p /etc/sysconfig/ip* /home/user

What is the purpose of this line? ^^^

(I don't see any later step where we copy files back from /home/user.)

> sudo yum erase nautilus-actions sudo yum clean all
>
> # For release 2 of Qubes sudo yum

> --enablerepo=qubes-vm-r2-current-testing --releasever=21 --setopt=
> cachedir=/mnt/removable distro-sync

>
> # For release 3 of Qubes sudo yum

> --enablerepo=qubes-vm-r3.0-current-testing --releasever=21 --setopt
> =cachedir=/mnt/removable distro-sync
>
[...]
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVhWmPAAoJEJh4Btx1RPV8EhAQALR1YNaQFg8wGC6a2+olGIGp
l8IfHISYp5BYeYkKC3KitSMbdEc7YGXnTXhfqZwFlutIU+v6RnSYz32TZwmQKdXp
aTtraYpxDdQyQd3TRSFFRpt6sVhEipn/80TviRmyB4Mqglf9PqUT/rCWGahmkUpM
XzGvMqJdX7Stexvf03ANutBDB+GTaabBuDTcPoSPq5x/EROy3E20aZkTE5MbmC3d
lNuCRALkBY/wMemHvdKW0ISXlxmVF7KuYjAr4uLUVPi7kqUj1CsHbpN3Lmsbvucm
HcEvdIF/Y7B3UwlQlkGJmYO6hzPQd28fE/R5PRTHtIemkb2NmiwFPocnhBH8r/yq
EyATbVe1qknKt6bBx9y6hDNz5xT61DqMxuOprOUsjKoTQCG8HjvAM4o3Drye11KG
+8hGpn/Uck4mmr4Kam19jN+Bol4P/qh3YNja4BPgptQA5+RhKSulbJ8BK1F2i/aY
+EKDIsNZcYY45Si3VfdqyRbvPFtvWqE5X0/AkQhPdrq/jO+ISPlK+PX5IAPnEEXw
bPB72WXb0c9brcP5aMujaPTzk1248mO3zMgLIb0FsJ1BawtE2awi4UiodRO+/UkG
HSDGBerJ6D2DyPXoRnHcHHBdtk2dU/WE3/u/RKM4CNq0DHbbLYK6H3FQ3Hl72QoH
BetV4n0BKFoe764KNgo/
=PbFN
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

nrgaway wrote:

> I created some instructions on how to update a Fedora 20 template
> to Fedora 21 based on the existing wiki instructions. I hope
> someone finds it useful :)
>

> [...]

Has anyone tried upgrading a StandaloneVM from Fedora 20 to 21? Would
the procedure be the same as with a TemplateVM?
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVhYaqAAoJEJh4Btx1RPV8RhEQANN6x6BbP29GGSXwjGe3D2UI
KubrnHWKjjyZ701EkQw6Vx7YKRIbFf87ZMXFrvcb9RHZuGMC1Ygh3MDFU0bl0SJ9
v9luDgW/80DN0bFeD2X85LbDHOLZEv3A26jXsb5kRkGpPTECwWaQHvnseJeQU8VG
q9WJsapiBWgZaQwsJUPrUta0MzwIE2fyJhxNEatEnPw1kVuvyNrMjLj3sgLxtQzo
g2C+j5AH9sl2AC1tPgZCsHA0cSKki7che8PgeWpyZcVvseUn+aoG/16wsZV+yo9u
YkyamvuY+0tGmcYomPOvnltnWF1/tRVHhus6Egr3roA0rNFGWJE2cGl6587rhmrB
XsXWjNxyXs5KZyIHPPLPeQIOOovwrDx2OdxF2VPYt+A+OdwEn5cDsdu3dFM5tSiY
dqGrmbI6JS1zon05oQmFtdMyC/i9oKzV9O5tB7wZdF17VZXTwLDdg5S7LUCSuo9+
louu2Y9kMqHjTUqsJl+5nRhO94rqWCzJqWzotSdA4ZdrotkrCKADvnKLOtg5FvY5
hfH5qZXr6oO1CDTY/klfx88rQ6JD87a0beVzqAaWYGDghfBPX2rF2f8K0TkYDbQD
gvLB9pD5EY9MNsLYRViGjlRaZMlhvFMjIV7jLmCID1Tz85bjUieiwqcqgyM051Ts
/x8Slq6jYCx1ORXAdkdi
=hNCR
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Jun 20, 2015 at 01:24:33PM +0000, Axon wrote:
> nrgaway wrote:
> [...]
> > Prepare the file in dom0 (Be sure the new fedora-21 TemplateVM is
> > still running gnome-terminal): truncate -s 5GB
> > /var/tmp/template-upgrade-cache.img qvm-block -A fedora-21
> > dom0:/var/tmp/template-upgrade-cache.img
> >
> > Then use it in template: sudo mkfs.ext4 /dev/xvdi sudo mount
> > /dev/xvdi /mnt/removable
> >
> > sudo cp -p /etc/sysconfig/ip* /home/user
>
> What is the purpose of this line? ^^^
>
> (I don't see any later step where we copy files back from /home/user.)

I guess it makes a backup for those files, later overridden. I guess it
should be safe to skip, as you can restore the files from package anyway
if you want.

> > sudo yum erase nautilus-actions sudo yum clean all
> >
> > # For release 2 of Qubes sudo yum
> > --enablerepo=qubes-vm-r2-current-testing --releasever=21 --setopt=
> > cachedir=/mnt/removable distro-sync
> >
> > # For release 3 of Qubes sudo yum
> > --enablerepo=qubes-vm-r3.0-current-testing --releasever=21 --setopt
> > =cachedir=/mnt/removable distro-sync
> >
> [...]
>

- --

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 v1

iQEcBAEBAgAGBQJVhcshAAoJENuP0xzK19csm+gH/RDGA5wj9H6ccVHkuW3IWYay
6QsKW/PtoaP6VD4O+ub9GJDvUcpvIP/2FR0sI/wqAaVrNBpcG2so66LWPfmiw8wz
DLzQtJBCrsAq3gzNbuUdLIwSZ9Y5DgIH/9stla5s6XsyhIACuq772LTZVxHKzMWi
e4xktj3u6yzt/0BwJMcpNI6m1CXq4n+y38zC3vDfYhJ2OCeYDXOGYSS6Nm3EA3yz
aZgIyY66voL+4FqdzPiTNfMBoDklAAtKQ1q5bBouDHu8zsZVmmoENWqWbQFGZWpK
2V7MvSqvCfB1rRbteyqruyUZQYdGpJfKig8965cDBwg2F4Iw4jcBvBXQT9flFeM=
=AgC3
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Does it install any additional packages? Or just updates?

> No other problems encountered.
>
> Is this correct, or should a different procedure be used to upgrade
> minimal templates?

- --
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 v1

iQEcBAEBAgAGBQJVhctIAAoJENuP0xzK19csEesH/2zeljijWGh26hboz4/dxSpF
lhDQ37zBl2W7yJc8AV2tUFqeaLQFXAG4PLW/z/SgomN/gcXfcgbu2MDEgWOFmh8j
g5HRvyUHrbtSRSwb7WincNAzHW2Z2OUs8oC7a1oRHJ2JYKZfM6LWLWDSOxUrRw4M
fewYrLw1QpJnOuJO2BSKOY5az+uuVDqneTmls9RMmfR5l+JyVS87GrjTTULoEk1M
OV9twTWG6eVjce9t2PkuugzR/9hyPb8W54ob1wl8T1/8LehLy69SmvYKQtZDKDE6
zuZ9CN2XOs0/gQssEhQVbzQzTPxoycx9RKy3DLCIAszCgY4+kZlMPGLm1l/cH9M=
=+anO
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Jun 20, 2015 at 03:28:48PM +0000, Axon wrote:
> nrgaway wrote:
> > I created some instructions on how to update a Fedora 20 template
> > to Fedora 21 based on the existing wiki instructions. I hope
> > someone finds it useful :)
> >
> > [...]
>
> Has anyone tried upgrading a StandaloneVM from Fedora 20 to 21? Would
> the procedure be the same as with a TemplateVM?

I guess so. I'll be performing such operation soon (but on R3), so will
give some feedback.

- --
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 v1

iQEcBAEBAgAGBQJVhct9AAoJENuP0xzK19cs2AIH/j6Df4nTAOgRndxnE1d00c1x
hFR43P6/j7J+ZPHmACfzWe19/dG4+dDBGCNSKpvSnd0H2AzIzjDhr687F95zjcX6
88U4TXvHxi1Q0HlXX1FwzhTzJa9GN7AsPwczrbiJ5CpGgysJ7YGFeypuAVYgpzjh
CgbhUw2P8caj+I3RGMAtWyVHGFd+Qa+Nk0gZxkUgDe8MsDY83ElfY8AXK5YOZxac
zaBPDe0gdXO25SANl60s3Hku5eqFdXNrH85weA+CXJYWpNGz7GoOsPLIcqgbn1jz
Noxln5xf3f78qu8BN67NHMoi9VRABS3Vx3F68MQTZ+PzmZAsvYDNqnHyqV7iv70=
=F/nT
-----END PGP SIGNATURE-----

[nrgaway]

On 20 June 2015 at 09:24, Axon <ax...@openmailbox.org> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

nrgaway wrote:
[...]
> Prepare the file in dom0 (Be sure the new fedora-21 TemplateVM is
> still running gnome-terminal): truncate -s 5GB
> /var/tmp/template-upgrade-cache.img qvm-block -A fedora-21
> dom0:/var/tmp/template-upgrade-cache.img
>
> Then use it in template: sudo mkfs.ext4 /dev/xvdi sudo mount
> /dev/xvdi /mnt/removable
>
> sudo cp -p /etc/sysconfig/ip* /home/user

What is the purpose of this line? ^^^ 

(I don't see any later step where we copy files back from /home/user.)

It can be removed.  Initially it was to back up
 

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Only 3 of the packages are to be installed. The rest are upgrades. No
problem, them?

>> No other problems encountered.
>
>> Is this correct, or should a different procedure be used to
>> upgrade minimal templates?
>

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVhribAAoJEJh4Btx1RPV8UjoP/2UoiJ2K1vXQjkfcIX2b9Cew
T/SCPE+4XlQldkJgsHJxMiU1KQtkjQGOQeiA3nSY1rmrPKJFIo2E4vWHhhrF7R0i
X4/iawrCn2EVQlM1prIbIbK0Hu7G+vaTl+NwhiW2Dk63mIULLgEoQzVPau9bKfoy
1tOCmcGgtloUr1dQ3UdgZ1h0o3eS9EiHYsW08dRsQ2zq1qNbeDJ9tNbNnrTLxj8M
gxE/xzK3HVlBKFvMX0tTJ4t6sbM0njCctEsMndY9l9C9Pw1rA/cqvg72J5z8Bn5P
hien81yJ+0SRkCbpzs1m/xPtOnoFQ1wd7fC45d6iTxob26B6b/3BF9xnv+s7eE6Y
Rj63V3unwMMjmmrD3JeTFeTzG/QmAIcK4DZbJJoO3IqEZ+62zku0qqvwrsXf8G/y
zXJ4xH4RJz6kI199jvYFP7litAL2859pJ9lZfvbz4fK26PFtUnfSW304r4GfiQB5
6W07htEspsAHdrcRcazBwof+gH5u2uh7/gkGWMjVafxYuH6Jn9aIKrJt/wkCM4/n
CIs1V8zER5wRxy+1YO0jvKEBgfzY7BmeXPeAyWe3gyvXwZ2ARl82q/T8kxZSp7uY
gpjUkvVYlpSp4QEagKpd0GmvTWs7C5oQnmV8oea2sEovs/MSA4/fr2CsH1YuP0k0
WE5XTVyKaGAwRswKYcbD
=J8UC
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Franz wrote:
> On Mon, Jun 15, 2015 at 3:57 AM, Jason M <nrg...@gmail.com>
> wrote:
>
>>
>>
>> On Sunday, 14 June 2015 23:58:08 UTC-4, Francesco wrote:
>>>
>>>
>>>
>>> On Sun, Jun 14, 2015 at 12:54 PM, nrgaway <nrg...@gmail.com>
>>> wrote:
>>>
>>>> On 14 June 2015 at 11:44, nrgaway <nrg...@gmail.com> wrote:
>>>>
>>>>> On 14 June 2015 at 08:08, Franz <169...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On Fri, Jun 12, 2015 at 11:00 PM, nrgaway
>>>>>> <nrg...@gmail.com> wrote:
>>>>>>
>>>>>>> I created some instructions on how to update a Fedora
>>>>>>> 20 template to Fedora 21 based on the existing wiki
>>>>>>> instructions. I hope someone finds it useful :)
>>>>>>>
>>>>>>> One thing to note is that updates through qubes-manager
>>>>>>> GUI do not currently work. They will have to be done
>>>>>>> manually within a gnome-terminal or xterm session.
>>>>>>>

>>>>>>> *Upgrading Fedora 20 to Fedora 21*
>>>>>>>

>>>>>>> Commands to run in dom0 console (you can do the same
>>>>>>> from Qubes Manager): qvm-clone fedora-20-x64 fedora-21
>>>>>>> qvm-run -a fedora-21 gnome-terminal
>>>>>>>

>>>>>>> *Update instructions if fedora-21 template has at least
>>>>>>> 3GB free space.*

>>>>>>>
>>>>>>> Commands to run in new fedora-21 template: sudo yum
>>>>>>> erase nautilus-actions sudo yum clean all
>>>>>>>
>>>>>>> # For release 2 of Qubes sudo yum
>>>>>>> --enablerepo=qubes-vm-r2-current-testing
>>>>>>> --releasever=21 distro-sync
>>>>>>>
>>>>>>> # For release 3 of Qubes sudo yum
>>>>>>> --enablerepo=qubes-vm-r3.0-current-testing
>>>>>>> --releasever=21 distro-sync
>>>>>>>
>>>>>>> sudo cp /usr/lib/qubes/init/ip* /etc/syconfig/
>>>>>>>
>>>>>>> # poweroff via qubes-manager; may need to be killed
>>>>>>>
>>>>>>>
>>>>>> This one worked for the smaller template, with the
>>>>>> addition of
>>>>>>

>>>>>> *"If yum complains that there is not enough free space
>>>>>> in /usr/lib/modules, try this:"* Thanks
>>>>>>
>>>>>>
>>>>>>> *Update instructions if fedora-21 template DOES NOT
>>>>>>> have at least 3GB free space*

I just ran into the same problem with one of my templates. Surely
there must be a better solution than forcing the user to delete their
own files. Marek?

>>
>>>
>>>>>
>>>>>> After upgrade is finished, you can remove
>>>>>>> /var/tmp/template-upgrade-cache.img file.
>>>>>>>

>>>>>>> *If yum complains that there is not enough free space
>>>>>>> in /usr/lib/modules, try this:* sudo mkdir

>>>>>>> /mnt/removable/modules sudo cp -rp /usr/lib/modules
>>>>>>> /mnt/removable/modules/ sudo mount --bind
>>>>>>> /mnt/removable/modules /usr/lib/modules
>>>>>>>
>>>>>>>

>>>>>>> *Starting the newly created fedora-21 TemplateVM for
>>>>>>> the first time* Either start the new template via

>>>>>>> qubes-manager or in dom0: qvm-run -a fedora-21
>>>>>>> gnome-terminal
>>>>>>>
>>>>>>> Once started, within gnome-terminal, we need to make
>>>>>>> sure everything is up-to-date. Most likely some more
>>>>>>> packages will be installed to satisfy the upgrade
>>>>>>> dependencies sudo yum upgrade
>>>>>>>
>>>>>>>

>>>>>>> *Compacting templates root.img*

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVhxjMAAoJEJh4Btx1RPV8SU4QALGH6Uoo0YD1f2Wi6g+a/KwX
R0R7uxN5LPnlBTFMIMcnTrJxQ96MLJoxJ9EvhMjkwXwA1n7/4hH3p18n2octXLsw
IwVvPYULHN1wc+aObdpB2uu9mLQSFW3XqEfTXKWu+YqXddqD0OtyIRrSNkA0PS6y
PRal9UB2Q6ooqXCrg+RcnhCATfL7+AiOBMzRoOd4mGHeyYMt9eZgQuD168/5QZYC
EOnAgAQ9T35duNU/hmDny05airDigAYIDTrbW8rSFzUtUJ1xxnew9NhcYv1I6OLy
wV1G4B5km45KntFdclw5S3CxkJF4Pq5UKOcwS4KSVfiEgY8+Wd1YC581RQJn3+nb
h0mhPTglobJl7kgIVjFhWkpeMrLenL/EZ7EdjycJ2jEChPT0AYHJPHTDEjhRSkFz
Y2yzlsgb7SJNqr/nX/spT2DacLTzNza0k9zSzdnJ3Ua4si8fCWXWW07xGdu0q7pk
+5CbVuA6yf0PvAmk2gxcNckUwfZqzecyOiHPJS2kvXIXuUEC3tqGtHxYpOTDGMU2
2fAFFONU9Ao+IxkYOo8piUmQ4K7hqVKA3wkPjTY9XltYHqXjQ9XhKkyH/jjqYSLN
kOYissb93nbTa3/ZRQ8UctzrpvJ7jtATP0+PiQ50lPVcZqKRc/rDv4nMBW7zBDeV
WMkA633TA8X/2sLXqhhB
=OJXv
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Upgrade needs some space and we can't easily change that. I see those
options:
1. Increase root.img size - it needs some evaluation, but qvm-grow-root
can be rather easily extended to support PV, not only HVM
2. Do the upgrade in parts - for example use package groups - first
upgrade @core packages, then the rest
3. Do not perform in-place upgrade, simply download and install new
template package instead. Then redo all the template modifications...

Regarding the last step, personally I have a text file where I store all
the changes and additional packages installed in the template. I can
easily use that file when customizing new template. This is side effect
of my workflow - when I need some package in a VM, I just install it
there (to have it immediately, without VM restart), then write it in
that file to install the package in appropriate template during next
template upgrade.

- --
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 v1

iQEcBAEBAgAGBQJVhzGtAAoJENuP0xzK19csYWgH/A7kZzMM2OmbUArNo/EnuPpt
QuoEgDxbtAjFisRSE1LF8FQWvBc1Fqxc3PN4jur0FdBM+/iTDoS3NePT1f1Am0kL
aPNGx0VhAILU8vP2yIPeA45sTLy28rtWd47xT4JhZRAQ1YibdznU22nnQp43sgQt
4QkLNgBJS3qC4gZo3gc5ZNQoYrEJshfriha1Ov/7hKVEuwzhqRpjlHeGEmxDMv45
cETVLjOGaqPPphGfDvsIBahdm2JbLZsFViDkU2IjDUTTxmJVeRBaUc0urZzo7qR8
CjmD0OaSjytT4VKVX45QRa6Tap4rbs6u/7VnouhdS6gRU0w59Kzc6xBd7s+BWVw=
=yoGl
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki wrote:
[...]

Ok, I understand. I'll try to incorporate this into the documentation.
Thank you for explaining.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVhz5iAAoJEJh4Btx1RPV8AQMP+weFOZZFq27gksdQdv9XK2Bx
W9y5WXSOgiUntAg4HwGibR5euClJWYIMScpG6mgCv2dcI9fhWqs4oWiY9wdBqXCW
imDuRsfdtDmqCLXo9rv5Nu8CfwufTpe1HA93Vjv2RcJy3ebMXhfjaXLcuYsdBFQc
6rTn8oDiF/faXL9dl6shF6XYKEyx2rBTUDmhHTpZ9/eVYvRdGGDnv94ICD//I+Gt
1OHp/Ij3rJkrAtGYY/ecW8nJpH9pPsOWAjliKYI0OyWVO3uiVePVBjtlTl/IRwYn
AH4WmCldlX5XYJ0uF6TFLUGkq4POV7zOcHKPZhAtGi87APiAovgHhAI8gbEsofUN
54U/HNC7Lr/huXsqbX7BOMXDsS5PphBv6cKMsxDMQF/Ifnmb26lqwTGvlm9+Yxhd
1C6r569jwBRD4AaATl8cTxTCCuawRaz/j6p9FkS2pchUGhjVqnpEsWfdz5SOTkR5
WnkGNHmKhFR6k1HoQyawEuhByAnJf9CpfhidlGuwzL7WIbNsDp09Ydeuq+o93qGi
070Nzf9svQXXX/+q3SVpuzWN9NUHEgXTIr6Kcuwfae4UF0nBOUi4mjBm5822hOyv
CLhwPsvubylZc1UFXsi8JTT2Dw45Cj324UoWS3gTLqCOThJP4KgXkndMmiBBku9V
SP40a3Zog3W36hDGE40I
=VGax
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

nrgaway wrote:
> On 20 June 2015 at 09:24, Axon <ax...@openmailbox.org> wrote:
>
> nrgaway wrote: [...]
>>>> Prepare the file in dom0 (Be sure the new fedora-21
>>>> TemplateVM is still running gnome-terminal): truncate -s 5GB
>>>> /var/tmp/template-upgrade-cache.img qvm-block -A fedora-21
>>>> dom0:/var/tmp/template-upgrade-cache.img
>>>>
>>>> Then use it in template: sudo mkfs.ext4 /dev/xvdi sudo mount
>>>> /dev/xvdi /mnt/removable
>>>>
>>>> sudo cp -p /etc/sysconfig/ip* /home/user
>
> What is the purpose of this line? ^^^
>
>
> (I don't see any later step where we copy files back from
> /home/user.)
>
>
>> It can be removed. Initially it was to back up
>

Ok, thanks!

>
>>>> sudo yum erase nautilus-actions sudo yum clean all
>>>>
>>>> # For release 2 of Qubes sudo yum
>>>> --enablerepo=qubes-vm-r2-current-testing --releasever=21
>>>> --setopt= cachedir=/mnt/removable distro-sync
>>>>
>>>> # For release 3 of Qubes sudo yum
>>>> --enablerepo=qubes-vm-r3.0-current-testing --releasever=21
>>>> --setopt =cachedir=/mnt/removable distro-sync
>>>>
> [...]
>>
>

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVh0ACAAoJEJh4Btx1RPV81I8P/3y2rLHKwJX2ktbVIrDBNeET
teIG7jrMsITrfaxe6H4H0pOgqueZC7xMQyv5WrhquESpgLHIkJ4euqLBJpCdNckN
ahhjpjye8ORN/ye+3oK6Zf3TfhVvx38PRyQbm5Pib47fZESJIHanbDHjEmTk81fW
OpzDPRv8UbRlYFuK6SBqRYz/d/sUoeErVODubn+BtL2WbjcNaCLNNModFYhN3Pwz
MeF+pYSHr2FVJsGTBvJ4gR2sbyOOE5n1qn1SUk4/eS2YfcAtQi0M+BNi1a5I01I3
sgjrMjeMEWu8sA3fZxFuhrzCAdqkQ7PsTBVRNN823QGXmGpaO6arTVwREqyn1Ou5
0RUedqrq7hwdWsHZqzGBFzqgWGb+z2rgBEkCO1UWQ8sGgifl1UCFRZ712Kw+aXk5
3oJEZgkzBo5mUebeNmW26U6uhVVeQ0pn94Xis7POpNschbb1EMnkoQbrxT+oxmSS
RblF0NYfujscGG2Df25Hywar7MwjFD+dx/+7sQNBSyRpZphr3xzprzE2t7jVZ2zF
9eqZ3V/E6Yz1InI2AY8M/hK7mQ+2vN26AfVqIwb2abNn+sEI2gYRGq4ggdgGc7aI
GmMs43RcvBXnMrGNkUh3oV1tHXnRFxE/mXN2KElouvPTy7BJ6A0qs3ZCUbSiVMe+
c0m8shUNeAvB73dd/3Bz
=Sx2a
-----END PGP SIGNATURE-----

[nrgaway]

Here are some commands I use in regards to last step.

Generate a list of packages in a fresh template

This is the master list of all base packages

rpm --queryformat="%{NAME}.%{ARCH}\n" -qa | sort > base.list

Now generate a new list on AppVM which you want the differences in packages

from the master base list (All additional packages installed on top of default fresh template)

rpm --queryformat="%{NAME}.%{ARCH}\n" -qa | sort > appvm.list

Then use comm to find the differences:
comm -13 base.list appvm.list > packages.list

Now, after reviewing packages.list (and removing packages like nautilis-actions), remove ARCH
./split.py > packages.list.split

Now install the missing packages on other new VM
yum install `cat packages.list.split`

split.py

#!/usr/bin/python

import sys,os

filename = 'packages.list'

with open(filename, 'r') as infile:
    data = infile.readlines()

for line in data:
    line = line.strip()
    line_l = line.split('.')
    print ''.join(line_l[:-1])

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

nrgaway wrote:
> On 21 June 2015 at 17:50, Marek Marczykowski-Górecki <
> marm...@invisiblethingslab.com> wrote:
>
> On Sun, Jun 21, 2015 at 08:04:32PM +0000, Axon wrote:

[...]

>>>> I just ran into the same problem with one of my templates.
>>>> Surely there must be a better solution than forcing the user
>>>> to delete their own files. Marek?
>
> Upgrade needs some space and we can't easily change that. I see
> those options: 1. Increase root.img size - it needs some
> evaluation, but qvm-grow-root can be rather easily extended to
> support PV, not only HVM 2. Do the upgrade in parts - for example
> use package groups - first upgrade @core packages, then the rest 3.
> Do not perform in-place upgrade, simply download and install new
> template package instead. Then redo all the template
> modifications...
>
> Regarding the last step, personally I have a text file where I
> store all the changes and additional packages installed in the
> template. I can easily use that file when customizing new template.
> This is side effect of my workflow - when I need some package in a
> VM, I just install it there (to have it immediately, without VM
> restart), then write it in that file to install the package in
> appropriate template during next template upgrade.
>
>
>> Here are some commands I use in regards to last step.
>
>

>> *Generate a list of packages in a fresh template*
>
>> *This is the master list of all base packages* rpm

>> --queryformat="%{NAME}.%{ARCH}\n" -qa | sort > base.list
>
>

>> *Now generate a new list on AppVM which you want the differences
>> in packages*
>
>> *from the master base list (All additional packages installed on
>> top of default fresh template)* rpm

>> --queryformat="%{NAME}.%{ARCH}\n" -qa | sort > appvm.list
>

>> *Then use comm to find the differences:* comm -13 base.list
>> appvm.list > packages.list
>
>> *Now, after reviewing packages.list (and removing packages like
>> nautilis-actions), remove ARCH* ./split.py > packages.list.split
>
>> *Now install the missing packages on other new VM* yum install
>> `cat packages.list.split`
>
>> *split.py* #!/usr/bin/python

>
>> import sys,os
>
>> filename = 'packages.list'
>
>> with open(filename, 'r') as infile: data = infile.readlines()
>
>> for line in data: line = line.strip() line_l = line.split('.')
>> print ''.join(line_l[:-1])
>

Thank you, Jason. This is very helpful. I've added a links in the
documentation to your and Marek's posts.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJViTk7AAoJEJh4Btx1RPV8piAQANock1aBqCPjJRYB7T4JQ9rx
aOj02UsH1L5tA1GlgauXxBEgNbIH7E9OZDyoOPvVzSJZLL0w0s2Fyso0cdofoTct
uOsA6V7Is0D2ZG2naZcznLIRnnBpIFC3JE4zAOz9gTkFSM7tk7W+7MzhVTn5a/01
urVJh3p2hldC9nlDDoxGY4Dyp3PrelThVsS6/MVGqUBoNgCu0LlAlj25SvbhUCS/
eBK1R4F5MoY1k+kLC4DvN2UM1LuG12MxvIKCyEdotGSHTHjWSdYfBOmK1p89d7Wy
IL5Io7Eg5QMqS0nMJcxtzow1TkfqW9Ib54JRTmaSwb+sO2r3tkLNpGskVrHoBOWx
p+Br4wHp1U2DFLP3Uk3cLBTH6+EM+qw2t6qtA2IF1aVjpX7+e4ChcKeP2NrWHLHC
dKq5KGjUH9eJGpNuzygf+rEGyDch0D2ezSvSBZr1AeTUXVw0H0kB1myT+gmz7Y9G
kQkEjFVR/1Av5mJd5Nt7FVHwwSA7lueFfV34dAjptQ5NZtg9Odblrf/rczgYa4+v
bagDLSd5eA/+anp0M/+uBb9v04oxbApnzhGJOpbniSgm3fnKXob9PPcP5zNnfApC
ToqFzHZ7792PZm+GHJIO4cbph5b/UVPeyS3+D3dcvd6TLijezh9GhE6/ti3qVWBY
UH8ssAGd4SSDM0DMAHH0
=EqAs
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki wrote:
> On Sun, Jun 21, 2015 at 08:04:32PM +0000, Axon wrote:
>> Franz wrote:
>>> On Mon, Jun 15, 2015 at 3:57 AM, Jason M <nrg...@gmail.com>
>>> wrote:

[...]

Why can't one simply increase the template disk image size by
following the instructions here[1] under the "Template disk image"
section?

[1] https://www.qubes-os.org/doc/ResizeDiskImage/
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJViTvpAAoJEJh4Btx1RPV8rfkP/ib0e2qvckQIz6ASKUDD+StE
GGYiUWxQ3R3wMbrRyUEavdkpvdI6WV/n10AUFh+Nxt2fD/UQzHSyCiK8aMXMfEzE
aNR4OG4Ad7IG1KocgK9mDbA3Vyzmqg3xjBd5+M2YiF+RGy8TuMoAx/LZqqJTIPij
yLTHR6gvxsSUh4m7R5wEwWbxw1CoFbgr3zbNt2lUNIkGRG7Ir1NP69iTRyJNt7tD
5CSRi9enwvzHwqSCzd1RT0tLOIJgiqmzA7HvGxYfF35bqzFtIaET1yyXQE5Wuh54
leJ3dZokTCQO3+yoYZRYc8GHxNxYezknUHq/LlLvOo+PxHuqGCkN3ZueMmyxxWV8
+ui7sZqZZYM9cBZNuOwGednysGicXll+45DyMh6ejZ8psv/5hg7mHnGfKqVWwHin
Nm3XZzklkJ7E0XsjYtvIzqGbE7+pnGdRl15t5dqiHrpnzG1HrmsGYkuufeAAcYzx
iIHQe/4/m7VjJ4OCqqQPLO41mhZc5UYzzmvEsSeZoTXsYCE5lOeH1jAy6XcXqTGG
1SW2G6ig7ZRrvBiukwrRmsaW/WeCH/BnN116aA6pu9rzA99Sr3s+vjmI2L2yLTA+
SKgCLeTHSi3YBpC8E4cYAOFejj9sUnKxTkFo6YbNVZXY9pHu6gY+egIpk1SQNOQM
ZLzpZkCgEpxoQ0zYcKa0
=TBcV
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ah, I forgot we have this documented :)
Yes, this is an option.

> [1] https://www.qubes-os.org/doc/ResizeDiskImage/

- --
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 v1

iQEcBAEBAgAGBQJViUk8AAoJENuP0xzK19csnjwH/ii76DqwILdH8/agnsyfjDLN
0ho1TLmK3k7sXWuzHAVm6YpTiFKHxTZEaB0EGTFPalast9QQsAezTORPTajR11OC
r3saGI/d8UR2UJU+5e0TL/sIiBzuG4bwg0+mHV6T24KLne4UYdM3nc4oH/PwYTUP
AX1ri8lf9kp4EDQx7qz497BlVEoX+BK1GJs0nzAjxdvIjfHpfEGa+kMvE1A+HRX+
CnSZB61REBJiTabsCXFt62Tsg9pB2adLyoQVpLsYUGKBJvA2Ml0l3f4c6w03vTQ+
1rzUWoAXdG6xVN+Bjebh3LRIXZy09ipjVAXhvL5TZ1XEJ0DSW4Ma6HtoqRLmb48=
=uXLZ
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ok, thanks. Documentation updated.

>> [1] https://www.qubes-os.org/doc/ResizeDiskImage/
>
>

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJViWRIAAoJEJh4Btx1RPV8cBYP/2vvzaQlTgRKykiT3bYR/QKI
fthy+g5wEDiIGAXDxCNRpD2oQeOXNxZI5PROzH5fyX7DmOjDT4xJoY+tI9UO/Zwm
J03/JwY4PGCabuv97r9ufMOecRcayhu2tC4f1Ne93//AIUMp7bDH0J3Ifet4Jv5o
7Bza9ojY3wu/kHgLZ8Nib6Fzyr03lmUBETzG2hSCwYo0GSKFy3/45Eyofh2xHbZR
u11P2LFEKC1fntBadhJPuWcq98WOiAF3mK9NTBX3wZo2YuZsg+DCC6c1xR3aj8mQ
tEL0nwkXM1BgNbu6w1ioV6qBcFMw4Z3JdQiiBP8dIs2+FvWQAbpg4IDCK84G78Qe
kNSqi+l2iIjWnU4GxPaD8D764dYvl9cwrStRjemb+p265qMnxX4mos0vhKVum0Sm
/JyCizKYqkxcipItWJLXlOJnlabBDiGssM4eVvy+Kkf7i1UOHM4xeKCq6YvyW8bp
RswkxY5Yuj+G0bvfII9024xWzT9mZRLbmsscnWNdG/yxE/by59yM5fcgW8pL4mz9
arkOLkkLtNiC09FHCwTBjWFVScwfsqfZDA2dCHFxzYrvvO7BPiHXArc6SffgYkRM
bZGrD4r506/wLFWLKXJVqXWeM4fmJKtJl9Wt/pquz7y/pA5j2X6qB5AhYeRxcvaV
s36Qz/W4Y3lpcUj1TgtB
=jMF8
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Jun 21, 2015 at 01:14:11PM +0000, Axon wrote:
> Marek Marczykowski-Górecki wrote:
> > On Sat, Jun 20, 2015 at 09:38:08AM +0000, Axon wrote:
> >> nrgaway wrote:
> >>> # For release 2 of Qubes sudo yum
> >>> --enablerepo=qubes-vm-r2-current-testing --releasever=21
> >>> distro- sync
> >>>
> >
> >> This results in downloading 300-400 packages. I'm not sure if
> >> this is right. It seems like a lot for the minimal template.
> >
> > Does it install any additional packages? Or just updates?
> >
>
> Only 3 of the packages are to be installed. The rest are upgrades. No
> problem, them?

As the template is about that size, it looks good - you're upgrading the
whole system.

- --
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 v1

iQEcBAEBAgAGBQJVicCyAAoJENuP0xzK19csef4H/2Rw4nXCICUBhb06DzNuOlDp
SpeNJOKysqZgccKai55Zu6WOfAb1dpwfvWtF5YWqtMhJ7Lt9B3Sp5cPntPi7YfnF
XCwYd2RBFTuj+raUap3EKq6NxWeH1OoluRUIeqon58j8xf25u2OGDB2cCvoYtaI2
oFf0qnGnrRMLPTAs5gowAuW5rnaD9OaAIyLfoomvIx31msYrGBqRAI66VrCfR0kZ
nMWC3mg/upTEmzbA4hozIthWZJV1LueEJ7i7HLbxvXB28wwllf990IEm1Qnoe0o9
nCM/oDxVYueXRglULJ7pOK82/niKZRtK5S63wB20qhmxg4o71GyXhNspCq/EVDg=
=8fvP
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Jun 16, 2015 at 10:06:00AM -0300, Franz wrote:
> On Tue, Jun 16, 2015 at 3:15 AM, Zrubi <ma...@zrubi.hu> wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On 06/16/2015 01:11 AM, Franz wrote:
> > > Qubes R2. After a little testing it seems everything is working,
> > > except netvm and firewallvm. If they are based on fedora-21
> > > template all VMs loose network connection, even if I can ping
> > > google.com <http://google.com> from netvm terminal. So had to base
> > > both of them again on fedora -20 template.
> > >
> > > Any idea to solve this?
> >
> > Try this in the template:
> >
> > sudo cp /usr/lib/qubes/init/ip* /etc/syconfig/
> >
> >
> Many thanks Zrubi, network is back now, but it is "sysconfig"

The above step should be unnecessary when you update to
qubes-core-vm-2.1.65 (today uploaded to current-testing repository).

- --
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 v1

iQEcBAEBAgAGBQJVicDEAAoJENuP0xzK19csYC8H/3fj2Z5j30J84nb5EBoqPP1p
vqcZPKL2vEnzR5uq7LUArdcb1rs/4daWNUR9cDdl3YBpnXkusoVoCPBrHd3Tnjy1
pkyPK7a1RdzEFJXc6bWaSMWWey76HgkAGWbRJgtmqAVpAkGToqDyGaIlsjyzMCXS
9hrENEhkPs+YGt5fDd65t+xTWkrXeXi2WFXwAiIhSKwuYNJ7bNKzJTxbiYI3ZNAj
koylJb8mIOKdbxFqR6w7NjydQjkF9c35xNm7hAPVrE/UlYvQQX7PSd6Fko6h78iw
pDw5bTgAobW9ZMIKtwSbCh+pOc5v5Ieg4yCWX7wzVm1psr1+Ptdt4haZELrUqgk=
=15pz
-----END PGP SIGNATURE-----

[Hakisho Nukama]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Tue, Jun 23, 2015 at 8:25 PM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
> On Tue, Jun 16, 2015 at 10:06:00AM -0300, Franz wrote:
>> On Tue, Jun 16, 2015 at 3:15 AM, Zrubi <ma...@zrubi.hu> wrote:
>>> On 06/16/2015 01:11 AM, Franz wrote:
>>>> Qubes R2. After a little testing it seems everything is
>>>> working, except netvm and firewallvm. If they are based on
>>>> fedora-21 template all VMs loose network connection, even if
>>>> I can ping google.com <http://google.com> from netvm
>>>> terminal. So had to base both of them again on fedora -20
>>>> template.
>>>>
>>>> Any idea to solve this?
>>>
>>> Try this in the template:
>>>
>>> sudo cp /usr/lib/qubes/init/ip* /etc/syconfig/
>>>
>>>
>> Many thanks Zrubi, network is back now, but it is "sysconfig"
>
> The above step should be unnecessary when you update to
> qubes-core-vm-2.1.65 (today uploaded to current-testing
> repository).

Yesterday I updated all packages in a R2/fedora-20-template and was
without networking, had to copy iptables from /usr/lib/qubes/init/ to
/etc/sysconfig/.
Update included qubes-core-vm-2.1.65...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJVjKo7AAoJEDAdK/0oyrkqh90QAIoLzNpf+r5Zz+g8m7fomiiz
jyI69SS2Zl2S0Nb32czOcM5hJoeh3GN3ambHPxN9Yk7WsN2IN0dDdYvkLXhahzst
Riqk4eMWI31MUrT6QbjKHsgTskRiUkjUuxxFmH1inFbp7kvRUXTRjlsnAK0MM7rE
Oay6MvZg2BRe5uIhWZW+IFhmyHeX4+qTkkBUiTyBfI86CwEa+WE+qr3JJLn2/tcj
cVByXRSYXq77poZ7ux0++azAjG4kKQGgiTr7CJkwsku/SDfTatl5lvr5ocVtjgMF
h18gYPsySQCOU4mrMEHEKEeRJwSsSZ3YFn7L+pqiojZF2qPPRYTjo2jxmTOyO8Jw
/rOOQQp4F1YuOeF8RHHbk/fvehOU9gzPF6apZJ3dxQWHXILkByEY8gRO8JFKFdlW
LrCYmdf7Ylr0cIHOUZD8uSpd1YucWhFxbz7wa2URt6+xWzVcAPX/nMwbXWKbfUFG
P1P/eH8T5w+wxr3VxpCsrnNfea4sPvrmXW7wxUFGnCY88Rl3RjhOmyEU9+uA84u0
d5grFjURxF7pZRfBXoZT+wlKEu+nJSKeWVAlYX96OlomhNFUaZp6hjI/NCm6jBsh
Yp1RgihUWE8x7ec0i5tthHTtdZGg5bdffE4Dot/vFN6CbMr5eyAbQTfpsHCuvCUu
jtEv4k5xKGcEi8/XbH47
=7fJJ
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jun 26, 2015 at 01:26:19AM +0000, Hakisho Nukama wrote:
> On Tue, Jun 23, 2015 at 8:25 PM, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com> wrote:
> > On Tue, Jun 16, 2015 at 10:06:00AM -0300, Franz wrote:
> >> On Tue, Jun 16, 2015 at 3:15 AM, Zrubi <ma...@zrubi.hu> wrote:
> >>> On 06/16/2015 01:11 AM, Franz wrote:
> >>>> Qubes R2. After a little testing it seems everything is
> >>>> working, except netvm and firewallvm. If they are based on
> >>>> fedora-21 template all VMs loose network connection, even if
> >>>> I can ping google.com <http://google.com> from netvm
> >>>> terminal. So had to base both of them again on fedora -20
> >>>> template.
> >>>>
> >>>> Any idea to solve this?
> >>>
> >>> Try this in the template:
> >>>
> >>> sudo cp /usr/lib/qubes/init/ip* /etc/syconfig/
> >>>
> >>>
> >> Many thanks Zrubi, network is back now, but it is "sysconfig"
> >
> > The above step should be unnecessary when you update to
> > qubes-core-vm-2.1.65 (today uploaded to current-testing
> > repository).
>
> Yesterday I updated all packages in a R2/fedora-20-template and was
> without networking, had to copy iptables from /usr/lib/qubes/init/ to
> /etc/sysconfig/.
> Update included qubes-core-vm-2.1.65...

Oops, indeed. While this fixed upgrade path to Fedora 21, it breaks
Fedora 20...

- --
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 v1

iQEcBAEBAgAGBQJVjYTGAAoJENuP0xzK19csaesH/0EKV3iepBvUSU1e2uModuMX
eqRyJW4Y7bhUAbeYosWAP5WY63M8zmOgKbnRySaQ93R3G1ajVpeB46zRe+FLbWC7
YIxvFhozQ9E2GHD+3ESz56WPqpY8WZkXOVqJxk9RAsFdxa9ldT8NeNBzX4qBLLQf
9iD5we316U1oiKmxmyaFTOdbNeehW/lPz3DErUj+XRe99UBMIof0DeA+CKgg1PSg
96m43nfmElGAfr8g6/vKXIbqdQAfmu2zJ9aixOwAg+OgY1LYw8XGKu3sV0gCmGYO
SICtSDAXssPY8GzUJLibqm2UuvQ4E46OYPvV/YhOAFxzg0ClNM/HuhMherCcFKU=
=qAn2
-----END PGP SIGNATURE-----

[Franz]

Finally after testing new fedora-21 templates and being happy with them, I would like to delete old fedora 20 templates, but the QVMM does not work:

If I right click on fedora-20-x64 the option "remove applVM" is shadowed.

If I right click on fedora-20-x64-multimedia the remove option is NOT shadowed, but if I click on it, I get:

"This Template VM cannot be removed, because there is at least one applVM that is based on it.

If you want....first remove each individual ApplVM that uses this template"

Very good, but none of my ApplVMs are still based on this template, because moved all of them to the corresponding updated fedora-21 template.

Best

Fran

[Alex]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/28/2015 06:41 AM, Franz wrote:
> If I right click on fedora-20-x64 the option "remove applVM" is
> shadowed.

That's right: since it was installed with an RPM (from the default
system setup), it cannot just be deleted.

> If I right click on fedora-20-x64-multimedia the remove option is
> NOT shadowed, but if I click on it, I get: "This Template VM cannot
> be removed, because there is at least one applVM that is based on
> it. If you want....first remove each individual ApplVM that uses
> this template"

Try checking if any DispVM is based on that Template; if you don't
like to fiddle within dom0:/var/lib/qubes, just try running
qvm-create-default-dvm (check man pages for info) and check if this
resolves the dependencies on that template.

- --
Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVj6uPAAoJENNOJZnNP8uD1Z8P/A/cLtFRGswKg6bSIbFOjBVI
VP7UQuBJJd/E1yzvf6TZwPoIdUIgpheciOnnHwauODp7dt9hXvg12SUV1rqSa5RR
sHAcljFtb1IM3RaI/t/LxBr+p3Ez+yLo3L67ZD4KrZI1XjHyKlg7n3wh4Vjr7hDw
BE916U7pa6q9qpDjHBftSk4w3hNvN/gJo2AmrhUpgFGDI6Ri7b7BGjhXPVDSAy93
7nl/DZk5BSSMmzghlllocBI94MH0G+1dELXH09F+QkSO1FDIP3ZAaips1XwTUV3t
DohLqMHuLrAeO6K464Vp4tAv4ZSR/k22/q6HACv7yWax4nAT0NPxDPCowdkffH33
wN38YHjJvhI2KlIRfJsKuYU91aWUzJaiA/mhN8GW+sBdlT7czZYXi/FCPwnIjEKO
JpQLrC/w0Es89fUbsjO1e9+yAfS8awjdHDw+u2elgkKDMt+iq0nyKAmqSO5zPDmu
3FXA8bNhPKHrfZ4FPtUvhowwEWgpqQu7QCv44fnkjTCP0RWi1M8tasqy05CAQLu1
G8fmnBKQ8xDRuOXDk9hsU/oP81ycN7xGshXarMikeWaDcU14ZcW2U8x5n7lHbvJB
EHtt/259Nhr59CtdnrFPuQQeJv1Ex58IgOMAChUAUzf+AxAyqGH9xh/JJic+Qke9
K0YZ3T+TMTE7B576JcQf
=ShPf
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Jun 28, 2015 at 10:08:47AM +0200, Alex wrote:
> On 06/28/2015 06:41 AM, Franz wrote:
> > If I right click on fedora-20-x64 the option "remove applVM" is
> > shadowed.
> That's right: since it was installed with an RPM (from the default
> system setup), it cannot just be deleted.

Exactly. But you can remove the package
("qubes-template-fedora-20-x64"). Note that because of some RPM
dependencies, you need to have at least one template package installed,
so if this is the only package you've installed, you can't remove it.
But you can for example install minimal template, and then remove the full
one.

> > If I right click on fedora-20-x64-multimedia the remove option is
> > NOT shadowed, but if I click on it, I get: "This Template VM cannot
> > be removed, because there is at least one applVM that is based on
> > it. If you want....first remove each individual ApplVM that uses
> > this template"
> Try checking if any DispVM is based on that Template; if you don't
> like to fiddle within dom0:/var/lib/qubes, just try running
> qvm-create-default-dvm (check man pages for info) and check if this
> resolves the dependencies on that template.

Check "internal" VMs - you can show them using a switch in "view" menu.

- --
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 v1

iQEcBAEBAgAGBQJVkROGAAoJENuP0xzK19csVi0H/0H8CYRIuq8xEu2D5lIUikOy
D0QXGjiGV1RCgJ/24L/yxmXJuMec7fYMAfBnmGmaR8F787a92w/1xPXQh6WQmjav
FRSEZymDdZm6zfGzfXwK7sWmz7JopMJQIiAU8deiqgtYeoMEZl4gtNIjfQljItOR
sFtq6GUtm1Ah67BO2GDTUMx6x+JyZz5E5A8WZiNWvXA0S8spKqcfBOGQK0eGX2oY
bEwZTj3Ut4p+WMdiTSbOCIajTZ0yPRbZM0e1DOYjHgyS9XZbcdbKnkwgOQv+t1W1
H7rIlXPB5BoQzT+k9BeNMoCO1lS9PhKkmmuawg/YhQp2B75gYmMk7vnUPpJ3N80=
=tO1N
-----END PGP SIGNATURE-----

[Franz]

"Internal" changes nothing. QM displays 30 VM with and without internal.

But yes dispVM was still based on fedora 20-cloned-template so did the following in dom0:

qvm-create-default-dvm fedora-21-cloned-template --default-script

This worked in the sense that now new dispVMs are based on fedora 21-cloned-template, but the same I am unable to delete old fedora 20 templates, even after a system restart.

Particularly fedora-20-x64 "remove applVM" button in QM is shadowed, so no way

fedora-20-x64-cloned-template "remove applVM" button in QM is NOT shadowed but the same it does not work because it states there still is some depending applVM.

May it be that I created a new dispVM template, but the old one is still present somewhere?

Any idea?

Another legacy of template upgrade is that now "sudo yum update" does not work anymore if I do not use:

sudo mount --bind /mnt/removable/modules /usr/lib/modules

everytime, because

there is not enough free space in /usr/lib/modules

Best

Fran

 

- --
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 v1

iQEcBAEBAgAGBQJVkROGAAoJENuP0xzK19csVi0H/0H8CYRIuq8xEu2D5lIUikOy
D0QXGjiGV1RCgJ/24L/yxmXJuMec7fYMAfBnmGmaR8F787a92w/1xPXQh6WQmjav
FRSEZymDdZm6zfGzfXwK7sWmz7JopMJQIiAU8deiqgtYeoMEZl4gtNIjfQljItOR
sFtq6GUtm1Ah67BO2GDTUMx6x+JyZz5E5A8WZiNWvXA0S8spKqcfBOGQK0eGX2oY
bEwZTj3Ut4p+WMdiTSbOCIajTZ0yPRbZM0e1DOYjHgyS9XZbcdbKnkwgOQv+t1W1
H7rIlXPB5BoQzT+k9BeNMoCO1lS9PhKkmmuawg/YhQp2B75gYmMk7vnUPpJ3N80=
=tO1N

-----END PGP SIGNATURE-----

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20150629094438.GF982%40mail-itl.

For more options, visit https://groups.google.com/d/optout.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, creating new one does not remove the old one.

Just to be sure, check VM list using:
qvm-ls |grep fedora-20-x64

Then remove (or migrate to other template) VMs on that list.


The original fedora-20-x64 can be removed using "yum remove
qubes-template-fedora-20-x64". The cloned one can be remove normally
(Qubes Manager or qvm-remove).

>
> Any idea?
>
> Another legacy of template upgrade is that now "sudo yum update" does not
> work anymore if I do not use:
> sudo mount --bind /mnt/removable/modules /usr/lib/modules
> everytime, because

> *there is not enough free space in /usr/lib/modules*

You should not have kernel package installed in the VM. Try to remove
it. If something requires it, you'll see what. Let me know about such
packages.

- --
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 v1

iQEcBAEBAgAGBQJVlAEhAAoJENuP0xzK19cs7J4H/2m1LPlKIeO21BWKLfJorWPH
MCLSRIlL5FNdilfsRWVSGjVMRVuON3lTaZn2HEBmZnWP83RemMy1AGLwTm5Hv4aC
jd3ek/dEjti1UFPo6xVFg7b2pyzqlNTyF4hpZBh0tavymPU446t7i4J2M2OBLkLd
wfU/Kp8wWDtI7MB2DM2Uy7rsH6kgR6qfzkSebZKfNUsfVPA9LPU6ij1cp1r31t2J
fD0SbHtnbvZnBLmvU6hhyyPwtZDQR6NKxqLZTwj4ub7u5+53TD0LO2KHptCjvByk
/pmuxK8shPgM+V2fm+ITByAdOpZQ61hGKIr9gr7Az+JX4AmiL5Ry1z8s5KrkCs8=
=WTUp
-----END PGP SIGNATURE-----

[Franz]

Everything worked as per your instructions, thanks Marek

>
> Any idea?
>
> Another legacy of template upgrade is that now "sudo yum update" does not
> work anymore if I do not use:
> sudo mount --bind /mnt/removable/modules /usr/lib/modules
> everytime, because
> *there is not enough free space in /usr/lib/modules*

You should not have kernel package installed in the VM. Try to remove
it. If something requires it, you'll see what. Let me know about such
packages.

Which is command to remove kernel package? "sudo yum remove kernel-package" there is none, but "sudo yum remove kernel" gives:


================================================================================
 Package               Arch   Version        Repository                    Size
================================================================================
Removing:
 kernel-core           x86_64 4.0.4-202.fc21 @updates                      41 M
 kernel-core           x86_64 4.0.5-200.fc21 @updates                      41 M
 kernel-core           x86_64 4.0.6-200.fc21 @updates                      41 M
 qubes-core-vm-kernel-placeholder
                       x86_64 1.0-2.fc20     @template-builder-repo/20    0.0 
 qubes-core-vm-kernel-placeholder
                       x86_64 1.0-2.fc21     @qubes-vm-r2-current         0.0 
Removing for dependencies:
 NetworkManager-l2tp   x86_64 0.9.8.7-3.fc21 @fedora                      338 k
 kernel-modules        x86_64 4.0.4-202.fc21 @updates                      17 M
 kernel-modules        x86_64 4.0.5-200.fc21 @updates                      17 M
 kernel-modules        x86_64 4.0.6-200.fc21 @updates                      17 M
 kernel-modules-extra  x86_64 4.0.4-202.fc21 @updates                     2.1 M
 kernel-modules-extra  x86_64 4.0.5-200.fc21 @updates                     2.1 M
 kernel-modules-extra  x86_64 4.0.6-200.fc21 @updates                     2.1 M
 qubes-core-vm         x86_64 2.1.64-1.fc21  @qubes-vm-r2-current-testing 1.8 M
 qubes-core-vm-systemd x86_64 2.1.64-1.fc21  @qubes-vm-r2-current-testing  15 k
 qubes-gui-vm          x86_64 2.1.35-1.fc21  @qubes-vm-r2-current-testing 128 k
 xl2tpd                x86_64 1.3.6-8.fc21   @updates                     359 k

best

Fran

[Jason M]

I removed kernel-core, kernel-modules, kernel-modules-extra on mine :)
 

[Franz]

Strange, I removed them, but it seems they were not there anyway, got a very long list of warnings, but no error at the end. I paste here the final part of the list:

warning: file /lib/modules/4.0.6-200.fc21.x86_64/kernel/arch/x86: remove failed: No such file or directory
warning: file /lib/modules/4.0.6-200.fc21.x86_64/kernel/arch: remove failed: No such file or directory
warning: file /lib/modules/4.0.6-200.fc21.x86_64/kernel: remove failed: No such file or directory
warning: file /lib/modules/4.0.6-200.fc21.x86_64/build: remove failed: No such file or directory
warning: file /lib/modules/4.0.6-200.fc21.x86_64: remove failed: Read-only file system
Running post transaction command: /usr/lib/qubes/qubes-trigger-sync-appmenus.sh
  Verifying  : kernel-modules-extra-4.0.4-202.fc21.x86_64                  1/11
  Verifying  : NetworkManager-l2tp-0.9.8.7-3.fc21.x86_64                   2/11
  Verifying  : kernel-core-4.0.5-200.fc21.x86_64                           3/11
  Verifying  : xl2tpd-1.3.6-8.fc21.x86_64                                  4/11
  Verifying  : kernel-modules-extra-4.0.6-200.fc21.x86_64                  5/11
  Verifying  : kernel-modules-4.0.4-202.fc21.x86_64                        6/11
  Verifying  : kernel-modules-4.0.5-200.fc21.x86_64                        7/11
  Verifying  : kernel-core-4.0.4-202.fc21.x86_64                           8/11
  Verifying  : kernel-modules-extra-4.0.5-200.fc21.x86_64                  9/11
  Verifying  : kernel-core-4.0.6-200.fc21.x86_64                          10/11
  Verifying  : kernel-modules-4.0.6-200.fc21.x86_64                       11/11

Removed:
  kernel-core.x86_64 0:4.0.4-202.fc21                                          
  kernel-core.x86_64 0:4.0.5-200.fc21                                          
  kernel-core.x86_64 0:4.0.6-200.fc21                                          
  kernel-modules.x86_64 0:4.0.4-202.fc21                                       
  kernel-modules.x86_64 0:4.0.5-200.fc21                                       
  kernel-modules.x86_64 0:4.0.6-200.fc21                                       
  kernel-modules-extra.x86_64 0:4.0.4-202.fc21                                 
  kernel-modules-extra.x86_64 0:4.0.5-200.fc21                                 
  kernel-modules-extra.x86_64 0:4.0.6-200.fc21                                 

Dependency Removed:
  NetworkManager-l2tp.x86_64 0:0.9.8.7-3.fc21    xl2tpd.x86_64 0:1.3.6-8.fc21  

Complete!
[user@fedora-21-clone-1 ~]$

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, this is exactly why those packages shouldn't be installed in the
first place. /lib/modules is provided by dom0 (together with the kernel)
and VM have no direct influence on its content. So files installed there
are not preserved.

- --
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 v1

iQEcBAEBAgAGBQJVlPZ2AAoJENuP0xzK19csZrgIAJqukZEfFtv+UjkZsj4oVuhV
ChQucbQO7I9SuOtowZBuq2OQe9XpnMN+3vXvkbUAbLJrYyXTYS3me+NoSymchsW2
c9mTqI8cEEUwgiCxJSVz/zH6SWEf+JhyK74/WTXh3GI4KxKRjDPNAEmz6GcQf1dp
0GLUjn9WAGB1mIVcKf+3qpFO+WDLqN6MP2lmt+J1Gwg9Lb64+nv3A3TZurWmy3Rd
y5bGpa99uKHTIdC6RMKG8zfp0fuW3zFMnUj5UO/CGKqC32+NlEFOhzT9Am2cLT0Z
fG6XIcLeLy++u4nJkdaO65aW4lYvXzhOCOnuF7n9YbKND55/wqWOr+TPUvG+w/g=
=AUHh
-----END PGP SIGNATURE-----

[Rowan Crane]

On 2 July 2015 at 09:29, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:

Yes, this is exactly why those packages shouldn't be installed in the
first place. /lib/modules is provided by dom0 (together with the kernel)
and VM have no direct influence on its content. So files installed there
are not preserved.

To avoid the problem with xl2tpd I removed it before upgrading my FC20 template (rather than mounting /lib/modules/ as described in the doc). However, if I now attempt to install the package and its related networkmanager package in FC21, it wants to pull in all the kernel packages discussed in Fran's post. I was under the impression Qubes kernel placeholder (qubes-core-vm-kernel-placeholder-1.0-2.fc21.x86_64 installed) package was supposed to prevent this, or am I missing the point here of exactly what it does / how it interacts with the package system?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, qubes-core-vm-kernel-placeholder is exactly for that. But
apparently there is some dependency not provided by this package, so
real kernel package is pulled. Just added "kmod(l2tp_ppp.ko)" to it, so
this should not be a problem in the future. But if the kernel package(s)
are already installed, it need to be manually removed.

- --
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 v1

iQEcBAEBAgAGBQJVlV6jAAoJENuP0xzK19csUaUIAIZ4634q6RjXnqurkG4uNYBJ
LtoBbHACy1UKqGh4TAOiGIilPnmV02rY661gv5/foh54mPaijHmMHuh3+n6QxVL7
CzWa2QnBtaLUIaOESNKkGIpA3FbBhKMEQEqAPReHJW9NB8yUJcIe1mnPvsagGRl+
kP1FTe4Qual9wWPHZypCMvs/4jrSwwzSnzm7+CdhTSATYFRG43IopbwRwgki4CnC
oRspd7lxs0aiCOebxOhRp90oww7bcXoVSLz076Wxdil/0M76wN8j6cSmyAaP4lFE
geB+bUiAzBl1A8354siADGihRH1VP579wN+b8EmTtYIDi3BngfAHgh27g1R20O8=
=AtB7
-----END PGP SIGNATURE-----

[Franz]

Thanks for explanation Marek

Next problem is "open in dispVM". After upgrade dispVMs (dependent from cloned-template fedora-21) open ONLY from VMs depending from cloned-template fedora-21, but do not open from VMs depending from default fedora-21.

This problem was not present before upgrade, infact I was able to open in dispVM in all applVMs.

Best

Fran

[Franz]

Now something strange happend. I tried again to "open in dispVM" on a different applVM based on default fedora-21 template. So it was not supposed to work according to what I previously described. But it updated the dispVM as if it was the first dispVM opened after template update. But it was not the first dispVM, it was the 13th one. After that I was again able to fully "open in dispVM"

[Franz]

Hello , found a simple solution:

 service nfs start

this solves the above problems and am able again to mount the NAS, as before the upgrade. Well, most of all this is important to be able to backup Qubes.

Best

Fran