On 08/06/23 22:29, Carlos E.R. wrote:
> On 2023-06-08 13:27, MarioCPPP wrote:
>> On 08/06/23 01:18, David W. Hodgins wrote:
>>> On Wed, 07 Jun 2023 19:09:29 -0400, David W. Hodgins
>>> <dwhodgins@nomail.afraid.org> wrote:
>
>
>> Could you also give an opinion about my doubt (expressed
>> in a question to Mr Carlos E.R. in this thread) ?
>>
>> The point, summed up, is that the target drive for the new
>> home is NON empty and that, possibly, the new home could
>> be attached to a more deeply nested folder in that partition.
>
> /dev/sdb47            /home.dirty   ext4  defaults  1 2
> /home.dirty/home.new  /home         none  bind      0  2
>
ok Tnx ! Tomorrow I'll try the great manouver :D
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 08/06/23 21:05, Carlos E.R. wrote:
> On 2023-06-08 13:17, MarioCPPP wrote:
>> On 08/06/23 04:17, Carlos E.R. wrote:
>>> On 2023-06-08 00:53, MarioCPPP wrote:
>>>> On 07/06/23 21:16, Carlos E.R. wrote:
>>>>> On 2023-06-07 20:17, MarioCPPP wrote:
>>>
>>> ...
>>>
>>>>>    5 - "umount /home"
>>>>>
>>>>>    6 - "umount /ANYWHERE"
>>>>>
>>>>>    7 - create directory "/home.old"
>>>>>
>>>>>    8 - edit fstab:
>>>>>        change the existing /home entry to mount in
>>>>> "/home.old"
>>>>>        create new entry for new disk or partition to
>>>>> mount as "/home"
>>>>
>>>> this step is not so clear to me
>>>
>>> Ok, suppose you had:
>>>
>>> /dev/sda35     /home      ext4  defaults  1 2
>>>
>>> /dev/sdb47     /ANYWHERE  ext4  defaults  1 2
>>>
>>>
>>> You do:
>>>
>>> /dev/sda35     /home.old  ext4  defaults  1 2
>>>
>>> /dev/sdb47     /home      ext4  defaults  1 2
>>
>>
>> I know, frequently I am dumb, but ... the Folder ANYWHERE
>> was not empty, and could contain almost anything, and only
>> one of its subfolders would actually contain a
>> "non-corrupted" home copy.
>
> Huh, no, the destination partition should be empty. I am
> assuming it is freshly formatted. You did not say you were
> using a disk with things inside.
>
>>
>> Now, correct me if I'm wrong, the mount command would make
>> appear all the former structure (plus a nested copy of
>> original home, under the new /HOME.
>
> If there is a directory /home.new with contents, and then
> you do:
>
> mount /dev/sdb47 /home.new
>
> all the previous contents of /home.new will disappear from
> sight, and you will only see the contents of /dev/sdb47
>
>
>>
>> Is this not a problem ? I mean, a lot of SW tend to expect
>> its own-made structure for app/data, config, local share
>> and so. Nesting that all deeper is fair ?
>
> I did not nest anything. The structure should be clear, you
> are now saying things you did not say at the start. This
> changes things.
uhm, pleas look at the TITLE of this thread. It says to an
existing, NON EMPTY, different disk.
With non empty I meant to assume that the former content
should be retained, neither hidden nor worse deleted or else.
Anyway, with this "new" assumption, should I not consider
all of your previous advices ?
I hope that the answers from David Hodgins have been aware
of this restraint, that maybe I did not stress enough ...
I haven't tried nothing yet, so no damage done !
>
>> And where it is stated (in the mount command) the real new
>> home "entry point" ?
>
> In fstab, or in the command if done as I posted above.
>
>
>
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On Thu, 8 Jun 2023 19:21:29 +0200, MarioCPPP wrote:
> On 08/06/23 16:29, J.O. Aho wrote:
>> On 6/8/23 14:08, MarioCPPP wrote:
>>> On 08/06/23 13:36, J.O. Aho wrote:
>>
>>>> of course you would need to create the /home after you
>>>> moved it (mkdir /home) and then in fstab add:
>>>>
>>>> /mnt/newdisk/home  /home  none  bind  0 0
>>>
>>> is this a complete command to be added to FSTAB ?
>>
>> this is what you would add in the fstab as I mentioned just
>> two lines above the fstab line.
>>>> then "mount /home"
>>>
>>> a separate, later, command in FSTAB or where ?
>>
>> mount command is what you run on the command line
>> (console/xterm/konsole/...), if you don't dare to do that,
>> then you can do the microsoft way of doing things: reboot.
>>
>
> please confirm if I have got it right.
>
> the BIND command is necessary and sufficient, but simply
> does not update current status, and no "permanent" mount
> command is needed if one just reboots the system.
> If so, a reboot is safer for me !

I can make some recommendations for you.
You could install something like VirtualBox, create a guest.
do a install move stuff onto the guest from host.
Clone the guest, then try making whatever you plan to do on
the host as a test shot in the guest. If mods on guest go bad and you
cannot recover/reboot, you delete the guest and clone the
clone back as original and try again.
Other option is create another user test account, say junk,
and then see how your moving junk to new location.
I find it handy to have a rescue cd in the event I really screw something
up, for example /etc/fstab and system fails to boot.
I just boot the rescue cd, create/mount point/mount it
and start fixing my problem.

I pull down an iso from https://www.system-rescue.org/ burned a cd
and modified grub to be able to boot the iso.

On 6/7/23 14:17, MarioCPPP wrote:
> I guess this topic has just been "over-answered", but googling I find a
> lot of answers where the disk has to be formatted and the partition
> created and alike.
>
> So a very short question.
>
> Assume I launch file manager with ROOT privilege (is it necessary ?
> maybe not, and maybe this could create copies with wrong owner ?), then
> unhide both DOT files and backup files (hence the file manager should
> "see" every file, right ?), then I copy the original /home to the
> destination.
> (then I use a difference checking tool, I love FreeFileSync, and verify
> all is ok)
>
> Then
> would be enough just edit FSTAB, commenting out the old home and mount
> the new /home to the new partition ?
> I mean, how to point not to the device as a whole, but to a subfolder on
> it ?
>
> Could I simply create a SymLink for /home (in the root partition)
> pointing to the new folder ?
>
> Tnx in advance for any mistake signalled.
> Ciao

I'm doing exactly that with 7 installed distros; in each under
/home/userMe is a link to a directory on a data drive. Other 'stby'
users remain on the system root partition so if I run into issues I just
log-in under another id. But I cannot 'suggest' this because it's really
experimental and an attempt aiming to explore the idea of a single
/userMe folder serving all the distros that I use, a thing that is still
far from doable.

On Fri, 09 Jun 2023 03:47:00 -0400, MarioCPPP <NoliMihiFrangereMentulam@libero.it> wrote:
> uhm, pleas look at the TITLE of this thread. It says to an
> existing, NON EMPTY, different disk.
> With non empty I meant to assume that the former content
> should be retained, neither hidden nor worse deleted or else.
>
> Anyway, with this "new" assumption, should I not consider
> all of your previous advices ?
>
> I hope that the answers from David Hodgins have been aware
> of this restraint, that maybe I did not stress enough ...
> I haven't tried nothing yet, so no damage done !

Yes, I read the subject line before responding. You may remember my first
reply started stating the assumption that newdisk was already mounted.
The rest of my reply is not impacted by whether or not newdisk is empty,
or where within the directory tree of newdisk /home is moved to, provided
the correct path is used in the symlink or bind mount.

Regards, Dave Hodgins

On 2023-06-09 09:47, MarioCPPP wrote:
> On 08/06/23 21:05, Carlos E.R. wrote:
>> On 2023-06-08 13:17, MarioCPPP wrote:
>>> On 08/06/23 04:17, Carlos E.R. wrote:
>>>> On 2023-06-08 00:53, MarioCPPP wrote:
>>>>> On 07/06/23 21:16, Carlos E.R. wrote:
>>>>>> On 2023-06-07 20:17, MarioCPPP wrote:
>>>>
>>>> ...
>>>>
>>>>>>    5 - "umount /home"
>>>>>>
>>>>>>    6 - "umount /ANYWHERE"
>>>>>>
>>>>>>    7 - create directory "/home.old"
>>>>>>
>>>>>>    8 - edit fstab:
>>>>>>        change the existing /home entry to mount in "/home.old"
>>>>>>        create new entry for new disk or partition to mount as "/home"
>>>>>
>>>>> this step is not so clear to me
>>>>
>>>> Ok, suppose you had:
>>>>
>>>> /dev/sda35     /home      ext4  defaults  1 2
>>>>
>>>> /dev/sdb47     /ANYWHERE  ext4  defaults  1 2
>>>>
>>>>
>>>> You do:
>>>>
>>>> /dev/sda35     /home.old  ext4  defaults  1 2
>>>>
>>>> /dev/sdb47     /home      ext4  defaults  1 2
>>>
>>>
>>> I know, frequently I am dumb, but ... the Folder ANYWHERE was not
>>> empty, and could contain almost anything, and only one of its
>>> subfolders would actually contain a "non-corrupted" home copy.
>>
>> Huh, no, the destination partition should be empty. I am assuming it
>> is freshly formatted. You did not say you were using a disk with
>> things inside.
>>
>>>
>>> Now, correct me if I'm wrong, the mount command would make appear all
>>> the former structure (plus a nested copy of original home, under the
>>> new /HOME.
>>
>> If there is a directory /home.new with contents, and then you do:
>>
>> mount /dev/sdb47 /home.new
>>
>> all the previous contents of /home.new will disappear from sight, and
>> you will only see the contents of /dev/sdb47
>>
>>
>>>
>>> Is this not a problem ? I mean, a lot of SW tend to expect its
>>> own-made structure for app/data, config, local share and so. Nesting
>>> that all deeper is fair ?
>>
>> I did not nest anything. The structure should be clear, you are now
>> saying things you did not say at the start. This changes things.
>
> uhm, pleas look at the TITLE of this thread. It says to an existing, NON
> EMPTY, different disk.

Nobody pays attention to subjects :-P

> With non empty I meant to assume that the former content should be
> retained, neither hidden nor worse deleted or else.
>
> Anyway, with this "new" assumption, should I not consider all of your
> previous advices ?

I modified my advice using bind.

--
Cheers, Carlos.

On 09/06/23 17:02, David W. Hodgins wrote:
> On Fri, 09 Jun 2023 03:47:00 -0400, MarioCPPP
> <NoliMihiFrangereMentulam@libero.it> wrote:
>> uhm, pleas look at the TITLE of this thread. It says to an
>> existing, NON EMPTY, different disk.
>> With non empty I meant to assume that the former content
>> should be retained, neither hidden nor worse deleted or else.
>>
>> Anyway, with this "new" assumption, should I not consider
>> all of your previous advices ?
>>
>> I hope that the answers from David Hodgins have been aware
>> of this restraint, that maybe I did not stress enough ...
>> I haven't tried nothing yet, so no damage done !
>
> Yes, I read the subject line before responding. You may
> remember my first
> reply started stating the assumption that newdisk was
> already mounted.
> The rest of my reply is not impacted by whether or not
> newdisk is empty,
> or where within the directory tree of newdisk /home is moved
> to, provided
> the correct path is used in the symlink or bind mount.
>
> Regards, Dave Hodgins

tnx ! I'll restudy all together then.
Grazie

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 07/06/23 20:17, MarioCPPP wrote:

In the main branch of this discussion, I have been advised
to use "bind" (or bind mount) command in FSTAB to achieve
the purpose.

Now, just before trying I had the bad idea to try to
self-document more using MAN page on mount, which made
emerge an aspect which didn't before, and which I have not
understood well.

The concept of SUBMOUNT points (which would not be "copied"
or remounted by default ... unless using a recursive synthax)

now I wasn't unable to understand the concept of submount
point, so I dunno whether or not this would be a problem for me.

The "non empty" disk has a complex tree (and apparently is
mounted just ONCE for all, at the topmost level, to expose
all folders, in FSTAB, plus a symlink under root for faster
and shorter access, bypassing even /home/user part of the
path, aspect which does not seem relevant for me).

also the REMOUNT concept is not clear to me.
Could be important to clarify this, before moving /home ?

also another aspect in man page is confusing : it seems that
the relation created by
mount --bind olddir newdir
is SYMMETRICAL, that is both newdir files are "seen" through
olddir and the reverse.
Biunivocal maybe is more proper.

What does that mean exactly ?
That the order of mention is irrelevant ?

If not, how can coesist this symmetry in visibility with the
non commutability of the order of mention ?

And anyway, the visibility includes ALL SUBTREES BELOW the
directory, right ? But not HIGHER parts (if existing), right ?

Assume olddir and newdir are both at "intermediate" level of
each own tree, neither topmost nor bottommost, either one
after BIND could grant access of the downstream part of each
tree ?

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 13/06/2023 10:54, MarioCPPP wrote:
> On 07/06/23 20:17, MarioCPPP wrote:
>
> In the main branch of this discussion, I have been advised to use "bind"
> (or bind mount) command in FSTAB to achieve the purpose.

Lets go back to the beginning.
What is your current /etc/fstab?
Is /home currently a mounted disk?
What are your current disks (devices)?
You say you have a non-empty disk that you wish to use for your home
directory. Or do you wish to use it for all /home/* directories?

--
Chris Elvidge
England

On Tue, 13 Jun 2023 05:54:08 -0400, MarioCPPP <NoliMihiFrangereMentulam@libero.it> wrote:

> On 07/06/23 20:17, MarioCPPP wrote:
>
> In the main branch of this discussion, I have been advised
> to use "bind" (or bind mount) command in FSTAB to achieve
> the purpose.
>
> Now, just before trying I had the bad idea to try to
> self-document more using MAN page on mount, which made
> emerge an aspect which didn't before, and which I have not
> understood well.
>
> The concept of SUBMOUNT points (which would not be "copied"
> or remounted by default ... unless using a recursive synthax)
>
> now I wasn't unable to understand the concept of submount
> point, so I dunno whether or not this would be a problem for me.

An example is probably the easiest to explain it. For example, let's assume
that / is mounted on one partition, /var is on it's own partition with lots of
directories stored in it. One of those directories is /var/mnt, with a few
directories in it that are used as mount points for removable devices such as
usb sticks.

In this example, / is a mount point. /var is a submount of the / filesystem.
Each of the mounts that use a directory in /var/mnt is a submount of the
/var filesystem.

When reading the documentation, the term submounts is discussing mounts
that use directories somewhere inside of the mount that's being discussed.
It's still a mount, it's just a mount that inside of another mount.

You could choose to mount things in a subdirectory of /home/$USER, in which
case those mounts are submounts of /home (assuming /home is on it's own
filesystem.

Where it matters most is when it comes time to unmount things. The /var mount
can not be unmounted while something is (sub)mounted in /var/mnt. All of the
submounts of /var must be unmounted first or the unmount will fail due to the
file system being busy.

For example. let's assume a user as a script that uses sudo to mount an
encrypted file system somewhere under /home/$USER. When it's time to reboot,
unmounting /home will fail until that encrypted file system has been unmounted
or the shutdown/boot reaches the point where the kernel forces it.

> The "non empty" disk has a complex tree (and apparently is
> mounted just ONCE for all, at the topmost level, to expose
> all folders, in FSTAB, plus a symlink under root for faster
> and shorter access, bypassing even /home/user part of the
> path, aspect which does not seem relevant for me).
> also the REMOUNT concept is not clear to me.
> Could be important to clarify this, before moving /home ?

The key difference between a normal mount and a remount, is that with
a remount, "the same contents are accessible in two places."

One example where a remount is used is to allow some users to have
write access to a file system while other users only have read access.
In fstab it's mounted ro. In a script in the /etc/profile.d (or other
startup script that runs as root), the filesystem is remounted rw
for selected users.

> also another aspect in man page is confusing : it seems that
> the relation created by
> mount --bind olddir newdir
> is SYMMETRICAL, that is both newdir files are "seen" through
> olddir and the reverse.
> Biunivocal maybe is more proper.

With a bind mount, "the same contents are accessible in two places.".
Either one can be unmounted and not impact the other.

> What does that mean exactly ?
> That the order of mention is irrelevant ?

The order does matter. Consider the following example
/home
/home/dave/dira
/home/dave/dira/filea
/home/dave/dirb
/home/dave/dirb/fileb

mount --bind /home/dave/dira /home/dave/dirb

After the mount, fileb is hidden. filea is visible is both paths.

If instead, the command was
mount --bind /home/dave/dirb /home/dave/dira

then filea is hidden. fileb is visible in both paths.

> If not, how can coesist this symmetry in visibility with the
> non commutability of the order of mention ?

I hope the above explains it.

> And anyway, the visibility includes ALL SUBTREES BELOW the
> directory, right ? But not HIGHER parts (if existing), right ?

Correct.

> Assume olddir and newdir are both at "intermediate" level of
> each own tree, neither topmost nor bottommost, either one
> after BIND could grant access of the downstream part of each
> tree ?

Correct. Only what's shown by "tree -ifa olddir" will be visible in the
directory used as the mountpoint newdir.

Regards, Dave Hodgins

On 07/06/23 20:17, MarioCPPP wrote:
> I guess this topic has just been "over-answered", but
> googling I find a lot of answers where the disk has to be
> formatted and the partition created and alike.
>
> So a very short question.
>
> Assume I launch file manager with ROOT privilege (is it
> necessary ? maybe not, and maybe this could create copies
> with wrong owner ?), then unhide both DOT files and backup
> files (hence the file manager should "see" every file, right
> ?), then I copy the original /home to the destination.
> (then I use a difference checking tool, I love FreeFileSync,
> and verify all is ok)
>
> Then
> would be enough just edit FSTAB, commenting out the old home
> and mount the new /home to the new partition ?
> I mean, how to point not to the device as a whole, but to a
> subfolder on it ?
>
> Could I simply create a SymLink for /home (in the root
> partition) pointing to the new folder ?
>
> Tnx in advance for any mistake signalled.
> Ciao
>

Here I am, reporting, after the moving
First : every attempt to save the home correctly (including
TAR, RSYNC, FreeFileSync) failed due to strange pseudomounts
(existing only in the UP system, expecially pCloud and
DropBox) and to strange permissions and name patterns (like
the ones used by BOTTLES, which uses strange files of type
unknown, maybe sockets but unsure, resembling Z: C: and so).
The only SW that was able to store all (but the DropBox
daemon status) have been
FSArchiver, with savedir option
It was relatively slow with --compression flag = 9

fsarchiver -A -a -v -j 3 --compress=9 savedir
Source/Home_User__FSA__12_06_2023.fsa
/media/demo/b7e3be4f-15a0-4e58-a323-fd6b0e4fbf4d/home/

(maximum) achieving an outstanding
56,4 GB from an original size of about 115 GB
* files successfully processed:....regfiles=1616738,
directories=867406, symlinks=6956, hardlinks=47169, specials=8
* files with errors:...............regfiles=0,
directories=0, symlinks=0, hardlinks=0, specials=0
particularly heavy are (in order)
Zeal/docset
gnome-boxes
Telegram Folder and media cache
Bottles (and inner Wine like folders)
Restoring elsewhere did not work as expected : the rebuilt
tree was much deeper, with useless prefixed paths, but
moving was instantaneous.
Ah ... I forgot to say : before moving, I also made a full
dist-upgrade from a mixed bullseye / bookworm to "pure"
bookworm, downloading 13 GB of .deb !!!
Some doubts about DropBox : the update did not work neither
in apt, nor dpkg (--configure pending), and not even the gui
self-launched app, which invariably hangs at 88-90 % eating
up 64 GB of ram.
I suspect it is buggy, or maybe relies on Python 2.7 or some
other old version no longer existing in bookworm. I cannot
get dropbox working again.
I am considering deleting all and retrying from scratch.
In the past DropBox dismissed the BTRF support (but here the
folder has been moved from ext4 to ext4).

============================

for those possibly interested in inspecting the .FSA
archives, I have done some research, which I post as is :

MOUNTING img.FSA
=======================================================
How to mount an fsa image
Recovery mode
I did not know where to write it, I think the place will be
on the hub Everywhere they write that fsarchiver is a
wonderful utility that can create archives with the file
system, compresses them well, etc. And indeed it is! And
most importantly, these archives can be done on working systems.
But today is a day off, the servers are in another city and
one of them has gone down, on the system unit the light with
an exclamation mark is lit in red, which means a serious
trouble with the glands. We can’t lift it by remote. Of
course, we will deal with the server and fix it, but we
should rather lift the service on the backup machine. Of
course, the images of all servers were carefully made by me
using the wonderful fsarсhiver utility.
And then the task arose of how to get configuration files
from an fsa image. Of course, if there is an empty hard
drive connected to the backup machine, this is not a
problem, but if it is not?
A search query like: “how to mount an fsa image” did not
return positive answers. And even on the turnover is not a
lot of misleading. On the website, the developers said:
“Unfortunately it won't be possible to do that we the
current file format.” (unfortunately this cannot be done
with this file format).
It became sad. But something inside me said that it was
possible! After all, this is Linux!
There is still not much search on the Internet and I found
the necessary information . Of course, everything is
elementary! I already used this command - losetup, but for
some reason it completely flew out of my head.
Now just give an example.
To begin with, we need to find out what size we need to make
a file that will emulate a block device.
#fsarchiver archinfo backup.fsa Get
what type:
======================
filesystem information
====================
Filesystem id in archive: 0
Filesystem format: ext4
Filesystem label: lboot
Filesystem uuid: f8eebcb0-ba54-47e4-8a86-769880291a3e
Original device: / dev / md0
Original filesystem size: 921.43 MB (966189056 bytes)
Space used in filesystem: 59.61 MB (62504960 bytes)

Here we are interested in the parameter Space used in
filesystem: 59.61 MB (62504960 bytes),
that is, how much minimum space is needed to deploy the
image. The image file should be slightly larger.
Create an empty vd.img file with a size of 100 megabytes
(59.61 MB required).
The parameters speak for themselves the count-number of
blocks, bs-their size.
#dd if = / dev / zero of = vd.img count = 100 bs = 1M
Then let's see which loopback interfaces we do not use
#losetup -f
If there are none, then we can add.
#modprobe loop max_loop = 128
And we associate the image file with this interface
#losetup / dev / loop0 vd.img
Then we restore our archive
#fsarchiver restfs backup.fsa id = 0, dest = / dev / loop0 to it
And mount
#mount -o loop = / dev / loop0 / mnt / vd
After we pulled out the files we need from the image, we
need to unmount it, untie it and delete it - if we don't
plan to use it again. The following commands do this:
#umount / mnt / vd
#losetup -d / dev / loop0
#rm -f vd.img
Good luck to everyone, do not forget to backup.
=======================================================


=======================================================
Howto fsarchiver: restoring a full partition archive to a
mountable image
Restoring an entire archived partition is wonderfully
easy with fsarchiver, but recently I needed only a single
file from an archive and had no free partitions to restore
to. After failing to find any instructions to mount the
*.fsa image directly I came up with the following method
which may come in handy for other novices out there.
Note: this how-to is for those with a *.fsa created
using 'fsarchiver savefs ...' . From now on I will be using
'fsarchiver savedir ...' on my home directory instead, which
will greatly simplify restoring single files.
From the man page on fsarchiver:
fsarchiver is a system tool that allows you to save the
contents of a
filesystem to a compressed archive file. The
file-system can be
restored on a partition which has a different size and
it can be
restored on a different file-system. Unlike tar/dar,
FSArchiver also
creates the filesystem when it extracts the data to
partitions. Every‐
thing is checksummed in the archive in order to protect
the data. If
the archive is corrupt, you just loose the current
file, not the whole
archive.
Ultimately, I don't believe there currently is a way to
directly mount a fsarchiver saved filesystem. Instead we
will create an image file, restore the archive to this
image, and then mount the image which will give direct
access to the files.
Step 1) Create an empty image for the restoration.
Remember that the *.fsa is compressed and will expand
somewhat. For example, my 10GB archive expanded to 15GB
after this step. Make sure the image is large enough to
accommodate the full restoration!
Code:
$ ls -lh home_fsarchiver_backup.fsa #check the size of
the archive
$ df -h #check the free space on accessible drives,
choose a location
$ dd if=/dev/zero of=home.img count=20 bs=1G #create
an empty 20GB image
Step 2) Setup a loop device for the empty image and
restore the archive to it.
Code:
$ sudo losetup -f #check for unused loop back devices
to use
/dev/loop0
$ sudo losetup /dev/loop0 homefsa.img #setup a loop device
$ sudo fsarchiver restfs home_fsarchiver_backup.fsa
id=0,dest=/dev/loop0

Click here to read the complete article

On 19/06/23 15:49, MarioCPPP wrote:
> On 07/06/23 20:17, MarioCPPP wrote:
>> I guess this topic has just been "over-answered", but
>> googling I find a lot of answers where the disk has to be
>> formatted and the partition created and alike.
>>
>> So a very short question.
>>
>> Assume I launch file manager with ROOT privilege (is it
>> necessary ? maybe not, and maybe this could create copies
>> with wrong owner ?), then unhide both DOT files and backup
>> files (hence the file manager should "see" every file,
>> right ?), then I copy the original /home to the destination.
>> (then I use a difference checking tool, I love
>> FreeFileSync, and verify all is ok)
>>
>> Then
>> would be enough just edit FSTAB, commenting out the old
>> home and mount the new /home to the new partition ?
>> I mean, how to point not to the device as a whole, but to
>> a subfolder on it ?
>>
>> Could I simply create a SymLink for /home (in the root
>> partition) pointing to the new folder ?
>>
>> Tnx in advance for any mistake signalled.
>> Ciao
>>
>
>
> Here I am, reporting, after the moving
>
> First : every attempt to save the home correctly (including
> TAR, RSYNC, FreeFileSync) failed due to strange pseudomounts
> (existing only in the UP system, expecially pCloud and
> DropBox) and to strange permissions and name patterns (like
> the ones used by BOTTLES, which uses strange files of type
> unknown, maybe sockets but unsure, resembling Z: C: and so).
>
> The only SW that was able to store all (but the DropBox
> daemon status) have been
>
> FSArchiver, with savedir option
> It was relatively slow with --compression flag = 9
>
>
> fsarchiver -A -a -v -j 3 --compress=9 savedir
> Source/Home_User__FSA__12_06_2023.fsa
> /media/demo/b7e3be4f-15a0-4e58-a323-fd6b0e4fbf4d/home/
>
>
> (maximum) achieving an outstanding
>
> 56,4 GB from an original size of about 115 GB
>
> * files successfully processed:....regfiles=1616738,
> directories=867406, symlinks=6956, hardlinks=47169, specials=8
> * files with errors:...............regfiles=0,
> directories=0, symlinks=0, hardlinks=0, specials=0
>
> particularly heavy are (in order)
> Zeal/docset
> gnome-boxes

also MONERO wallet, far from be a complete node, is just
rather heavy !

> Telegram Folder and media cache
> Bottles (and inner Wine like folders)
>
> Restoring elsewhere did not work as expected : the rebuilt
> tree was much deeper, with useless prefixed paths, but
> moving was instantaneous.
>
> Ah ... I forgot to say : before moving, I also made a full
> dist-upgrade from a mixed bullseye / bookworm to "pure"
> bookworm, downloading 13 GB of .deb !!!
>
> Some doubts about DropBox : the update did not work neither
> in apt, nor dpkg (--configure pending), and not even the gui
> self-launched app, which invariably hangs at 88-90 % eating
> up 64 GB of ram.
>
> I suspect it is buggy, or maybe relies on Python 2.7 or some
> other old version no longer existing in bookworm. I cannot
> get dropbox working again.
>
> I am considering deleting all and retrying from scratch.
>
> In the past DropBox dismissed the BTRF support (but here the
> folder has been moved from ext4 to ext4).
>

apparently, the free plan of DropBox (which supports at most
3 devices connected) is unable to recognize its own old
install after the upgrade (even if the username and the
machine name were the same).
So it required (WITHOUT SAYING IT, it has been just a random
attempt by me) logging in in the WEB PAGE, DISCONNECT THE
OLD MACHINE and RECONNECT the upgraded machine.
Very bad habit from DropBox I must say ... I mean, to both
bind so tightly to the machine, but not tightly enough to be
able to recognize a simple UPGRADE, and particularly
misbehave silently.

I will see if the account, now reconnected, will survive
reboot bypassing the BUGGY INSTALLER (that not only got
stuck at 88-90 %, but ATE UP 64 GB of physical RAM ! Buggy
indeed, true ?)

Now I reboot.

Telegram, which has the bad habit also to give the illusion
of tailoring the download folder (while it still keeps loads
and loads of data where it wants, deeply buried in home), at
least survived seamlessly both the system dist-upgrade and
home moving to another partition. It seems a robust app !

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 2023-06-19 15:49, MarioCPPP wrote:
> On 07/06/23 20:17, MarioCPPP wrote:
>> I guess this topic has just been "over-answered", but googling I find
>> a lot of answers where the disk has to be formatted and the partition
>> created and alike.
>>
>> So a very short question.
>>
>> Assume I launch file manager with ROOT privilege (is it necessary ?
>> maybe not, and maybe this could create copies with wrong owner ?),
>> then unhide both DOT files and backup files (hence the file manager
>> should "see" every file, right ?), then I copy the original /home to
>> the destination.
>> (then I use a difference checking tool, I love FreeFileSync, and
>> verify all is ok)
>>
>> Then
>> would be enough just edit FSTAB, commenting out the old home and mount
>> the new /home to the new partition ?
>> I mean, how to point not to the device as a whole, but to a subfolder
>> on it ?
>>
>> Could I simply create a SymLink for /home (in the root partition)
>> pointing to the new folder ?
>>
>> Tnx in advance for any mistake signalled.
>> Ciao
>>
>
>
> Here I am, reporting, after the moving
>
> First : every attempt to save the home correctly (including TAR, RSYNC,
> FreeFileSync) failed due to strange pseudomounts (existing only in the
> UP system, expecially pCloud and DropBox) and to strange permissions and
> name patterns (like the ones used by BOTTLES, which uses strange files
> of type unknown, maybe sockets but unsure, resembling Z: C: and so).

Remember I said to do the operation in runlevel 3?

--
Cheers, Carlos.

On 19/06/23 18:49, Carlos E.R. wrote:
> On 2023-06-19 15:49, MarioCPPP wrote:
>> On 07/06/23 20:17, MarioCPPP wrote:
>>> I guess this topic has just been "over-answered", but
>>> googling I find a lot of answers where the disk has to be
>>> formatted and the partition created and alike.
>>>
>>> So a very short question.
>>>
>>> Assume I launch file manager with ROOT privilege (is it
>>> necessary ? maybe not, and maybe this could create copies
>>> with wrong owner ?), then unhide both DOT files and
>>> backup files (hence the file manager should "see" every
>>> file, right ?), then I copy the original /home to the
>>> destination.
>>> (then I use a difference checking tool, I love
>>> FreeFileSync, and verify all is ok)
>>>
>>> Then
>>> would be enough just edit FSTAB, commenting out the old
>>> home and mount the new /home to the new partition ?
>>> I mean, how to point not to the device as a whole, but to
>>> a subfolder on it ?
>>>
>>> Could I simply create a SymLink for /home (in the root
>>> partition) pointing to the new folder ?
>>>
>>> Tnx in advance for any mistake signalled.
>>> Ciao
>>>
>>
>>
>> Here I am, reporting, after the moving
>>
>> First : every attempt to save the home correctly
>> (including TAR, RSYNC, FreeFileSync) failed due to strange
>> pseudomounts (existing only in the UP system, expecially
>> pCloud and DropBox) and to strange permissions and name
>> patterns (like the ones used by BOTTLES, which uses
>> strange files of type unknown, maybe sockets but unsure,
>> resembling Z: C: and so).
>
> Remember I said to do the operation in runlevel 3?

sorry, I did not understand that statement and I forgot about.
I thought that being ROOT, could be enough ... later I tried
a living distro (always being root user), but so I lost some
"live strange mounts like pCloud cached drive.

Now, by attempts, I somehow got them back with all the data
in their place, and I am beginning to forget how.

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 2023-06-20 09:50, MarioCPPP wrote:
> On 19/06/23 18:49, Carlos E.R. wrote:
>> On 2023-06-19 15:49, MarioCPPP wrote:
>>> On 07/06/23 20:17, MarioCPPP wrote:
>>>> I guess this topic has just been "over-answered", but googling I
>>>> find a lot of answers where the disk has to be formatted and the
>>>> partition created and alike.
>>>>
>>>> So a very short question.
>>>>
>>>> Assume I launch file manager with ROOT privilege (is it necessary ?
>>>> maybe not, and maybe this could create copies with wrong owner ?),
>>>> then unhide both DOT files and backup files (hence the file manager
>>>> should "see" every file, right ?), then I copy the original /home to
>>>> the destination.
>>>> (then I use a difference checking tool, I love FreeFileSync, and
>>>> verify all is ok)
>>>>
>>>> Then
>>>> would be enough just edit FSTAB, commenting out the old home and
>>>> mount the new /home to the new partition ?
>>>> I mean, how to point not to the device as a whole, but to a
>>>> subfolder on it ?
>>>>
>>>> Could I simply create a SymLink for /home (in the root partition)
>>>> pointing to the new folder ?
>>>>
>>>> Tnx in advance for any mistake signalled.
>>>> Ciao
>>>>
>>>
>>>
>>> Here I am, reporting, after the moving
>>>
>>> First : every attempt to save the home correctly (including TAR,
>>> RSYNC, FreeFileSync) failed due to strange pseudomounts (existing
>>> only in the UP system, expecially pCloud and DropBox) and to strange
>>> permissions and name patterns (like the ones used by BOTTLES, which
>>> uses strange files of type unknown, maybe sockets but unsure,
>>> resembling Z: C: and so).
>>
>> Remember I said to do the operation in runlevel 3?
>
> sorry, I did not understand that statement and I forgot about.
> I thought that being ROOT, could be enough ... later I tried a living
> distro (always being root user), but so I lost some "live strange mounts
> like pCloud cached drive.
>
> Now, by attempts, I somehow got them back with all the data in their
> place, and I am beginning to forget how.

Well, it is a mistake to clone the virtual filesystems that you may
encounter on an active home, like for example, .gvfs, or what you call
pseudomounts.

--
Cheers, Carlos.