Re: [EXT] [qubes-users] Re: Replacing SSD with larger SSD on Qubes System

2020-06-14 Thread Ulrich Windl 

On 6/7/20 3:06 PM, TheGardner wrote:

Did this in the past with a
- clon of the entire (smaller) in Tails - Drives on a extern backup dive
- replace the old drive with the new one
- and extend the written partition later up to 1TB


Wouldn't a Qubes OS command like "clone drive" (that re-creates the 
partitions, VGS, LVs, etc. on a new drive, optionally resizing the LVs) 
be useful?
My idea would have been to create a corresponding VG (initially under a 
different name), the LVs, and then "dd" the old LV contents into the 
corresponding new LVs.  However that would work best when started from a 
different system, because when you "swap" old with new you would have to


vgrename qubes_dom0 qubes_dom0_old
vgrename qubes_dom0_new qubes_dom0 # assuming your new VG is named 
qubes_dom0_new




A fresh install is also a way. Just backup all your VMs and restore them 
later on the new system. I -for myself- would do such a new install / 
rename all new and fresh vms to somewhat "original-x" and then 
restore the backup.
So you have your old system beside fresh installed original cubes from a 
actual Qbs installation.


Am Samstag, 6. Juni 2020 21:27:32 UTC+2 schrieb Verifiable List:

Hello All,

I'm a long-time user of Qubes. I'm upgrading my laptop from a 256GB SSD
to a 1TB SSD. I wanted to check whether it is preferable to clone the
existing drive to the new one and expand the volumes, or whether I
should do a fresh Qubes install on the new drive and restore from
backup. I've not had great luck with Qubes' restore process in the
past,
but it's been a long time since I've needed to use it. Also, if the
fresh install/restore method is preferable, should I install Qubes with
the "Do not configure anything" option checked so that none of the
default VMs are created?

Thanks.

--
You received this message because you are subscribed to the Google 
Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to qubes-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6e032ee9-bdaf-4fc4-9668-b0c5b7e091dao%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c54e9b02-688c-bd3a-db67-504d853808b1%40rz.uni-regensburg.de.

Re: [qubes-users] Re: Replacing SSD with larger SSD on Qubes System

2020-06-08 Thread Verifiable List 
I figured out that I could restore as long as I allowed Qubes to set up 
sys-net, sys-firewall, etc. I wish there was an option during install 
for "restore Qubes from backup"... so you didn't need to create VMs 
you'd just need to delete later.


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

Re: [qubes-users] Re: Replacing SSD with larger SSD on Qubes System

2020-06-07 Thread a 

On 2020-06-07 08:06, TheGardner wrote:

Did this in the past with a

- clon of the entire (smaller) in Tails - Drives on a extern backup
dive

- replace the old drive with the new one
- and extend the written partition later up to 1TB

A fresh install is also a way. Just backup all your VMs and restore
them later on the new system. I -for myself- would do such a new
install / rename all new and fresh vms to somewhat "original-x"
and then restore the backup.
So you have your old system beside fresh installed original cubes from
a actual Qbs installation.

Am Samstag, 6. Juni 2020 21:27:32 UTC+2 schrieb Verifiable List:


Hello All,

I'm a long-time user of Qubes. I'm upgrading my laptop from a 256GB
SSD
to a 1TB SSD. I wanted to check whether it is preferable to clone
the
existing drive to the new one and expand the volumes, or whether I
should do a fresh Qubes install on the new drive and restore from
backup. I've not had great luck with Qubes' restore process in the
past,
but it's been a long time since I've needed to use it. Also, if the
fresh install/restore method is preferable, should I install Qubes
with
the "Do not configure anything" option checked so that none of the
default VMs are created?

Thanks.


 --
You received this message because you are subscribed to the Google
Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/6e032ee9-bdaf-4fc4-9668-b0c5b7e091dao%40googlegroups.com
[1].


Links:
--
[1] 
https://groups.google.com/d/msgid/qubes-users/6e032ee9-bdaf-4fc4-9668-b0c5b7e091dao%40googlegroups.com?utm_medium=email&utm_source=footer



Restoring from backup would be my preference, but it doesn't seem to 
work. It fails immediately. After restoring multiple VMs failed, I 
attempted to restore *only* a template VM. These are the resulting 
errors from journalctl (any help would be greatly appreciated):


Jun 07 16:36:44 dom0 qubesd[2664]: Creating directory: 
/var/lib/qubes/vm-templates/fedora-30
Jun 07 16:36:44 dom0 qubesd[2664]: unhandled exception while calling 
src=b'dom0' meth=b'admin.vm.volume.Info' dest=b'fedora-30' arg=b'kernel' 
len(untrusted_payload)=0

Jun 07 16:36:44 dom0 qubesd[2664]: Traceback (most recent call last):
Jun 07 16:36:44 dom0 qubesd[2664]:   File 
"/usr/lib/python3.5/site-packages/qubes/__init__.py", line 227, in 
__get__
Jun 07 16:36:44 dom0 qubesd[2664]: return getattr(instance, 
self._attr_name)
Jun 07 16:36:44 dom0 qubesd[2664]: AttributeError: 'TemplateVM' object 
has no attribute '_qubesprop_kernel'
Jun 07 16:36:44 dom0 qubesd[2664]: During handling of the above 
exception, another exception occurred:

Jun 07 16:36:44 dom0 qubesd[2664]: Traceback (most recent call last):
Jun 07 16:36:44 dom0 qubesd[2664]:   File 
"/usr/lib/python3.5/site-packages/qubes/vm/qubesvm.py", line 128, in 
_func
Jun 07 16:36:44 dom0 qubesd[2664]: return getattr(self.template, 
prop)
Jun 07 16:36:44 dom0 qubesd[2664]: AttributeError: 'TemplateVM' object 
has no attribute 'template'
Jun 07 16:36:44 dom0 qubesd[2664]: During handling of the above 
exception, another exception occurred:

Jun 07 16:36:44 dom0 qubesd[2664]: Traceback (most recent call last):
Jun 07 16:36:44 dom0 qubesd[2664]:   File 
"/usr/lib/python3.5/site-packages/qubes/__init__.py", line 227, in 
__get__
Jun 07 16:36:44 dom0 qubesd[2664]: return getattr(instance, 
self._attr_name)
Jun 07 16:36:44 dom0 qubesd[2664]: AttributeError: 'Qubes' object has no 
attribute '_qubesprop_default_kernel'
Jun 07 16:36:44 dom0 qubesd[2664]: During handling of the above 
exception, another exception occurred:

Jun 07 16:36:44 dom0 qubesd[2664]: Traceback (most recent call last):
Jun 07 16:36:44 dom0 qubesd[2664]:   File 
"/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line 275, in 
respond
Jun 07 16:36:44 dom0 qubesd[2664]: 
untrusted_payload=untrusted_payload)
Jun 07 16:36:44 dom0 qubesd[2664]:   File 
"/usr/lib64/python3.5/asyncio/futures.py", line 381, in __iter__
Jun 07 16:36:44 dom0 qubesd[2664]: yield self  # This tells Task to 
wait for completion.
Jun 07 16:36:44 dom0 qubesd[2664]:   File 
"/usr/lib64/python3.5/asyncio/tasks.py", line 310, in _wakeup

Jun 07 16:36:44 dom0 qubesd[2664]: future.result()
Jun 07 16:36:44 dom0 qubesd[2664]:   File 
"/usr/lib64/python3.5/asyncio/futures.py", line 294, in result

Jun 07 16:36:44 dom0 qubesd[2664]: raise self._exception
Jun 07 16:36:44 dom0 qubesd[2664]:   File 
"/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step

Jun 07 16:36:44 dom0 qubesd[2664]: result = coro.send(None)
Jun 07 16:36:44 dom0 qubesd[2664]:   File 
"/usr/lib64/python3.5/asyncio/coroutines.py", line 210, in coro

Jun 07 16:36:44 dom0 qubesd[2664]: res = func(*args, **kw)
Jun 07 16:36:44 dom0 qubesd[2664]:   File 
"/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 349, i

[qubes-users] Re: Replacing SSD with larger SSD on Qubes System

2020-06-07 Thread TheGardner 
Did this in the past with a 
- clon of the entire (smaller) in Tails - Drives on a extern backup dive
- replace the old drive with the new one
- and extend the written partition later up to 1TB

A fresh install is also a way. Just backup all your VMs and restore them 
later on the new system. I -for myself- would do such a new install / 
rename all new and fresh vms to somewhat "original-x" and then restore 
the backup.
So you have your old system beside fresh installed original cubes from a 
actual Qbs installation.

Am Samstag, 6. Juni 2020 21:27:32 UTC+2 schrieb Verifiable List:
>
> Hello All, 
>
> I'm a long-time user of Qubes. I'm upgrading my laptop from a 256GB SSD 
> to a 1TB SSD. I wanted to check whether it is preferable to clone the 
> existing drive to the new one and expand the volumes, or whether I 
> should do a fresh Qubes install on the new drive and restore from 
> backup. I've not had great luck with Qubes' restore process in the past, 
> but it's been a long time since I've needed to use it. Also, if the 
> fresh install/restore method is preferable, should I install Qubes with 
> the "Do not configure anything" option checked so that none of the 
> default VMs are created? 
>
> Thanks. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6e032ee9-bdaf-4fc4-9668-b0c5b7e091dao%40googlegroups.com.