VSIDO Installation Guide for fsarchive version

[PackRat]

Performed another install this morning. I guess it would be Method 3.

Method 3 - Install to clean, partitioned drive. Legacy BIOS system

Needed -
1. Live system with fsarchiver included. I used SystemRescue for this exercise. The VSIDO iso should also work.
2. The VSIDO fsarchive file on an accessible drive/partition.

Step 1 - Back up any data on the target drive

Step 2 - Boot the live session and use it to create a target partition for the install. For this install, I deleted all the existing partitions on the drive and created a new partition (sda1) for the install of VSIDO. Also created an additional partition to hold the VSIDO fsarchive file. Partitions were formatted to ext4

Step 3 - Log into an xsession and download the VSIDO fsarchive file. In this example I downloaded the file to one of the partitions I created in Step 2. I assume the fsarchive file could also be restored from an external drive or removable media.

Step 4 - Unpack the fsarchive to the target partition. Use Method 1 or Method 2 depending on tools available.

Before updating grub, the user needs to chroot into the system.

Mount the partition and file systems -

Code Select Expand

sudo mount /dev/sda1 /mnt

sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
chroot into the system

Code Select Expand

sudo chroot /mnt
update and reinstall grub

Code Select Expand

update-grub

sudo grub-install /dev/sda
sudo grub-install --recheck /dev/sda
exit chroot and unmount file systems and partition

Code Select Expand

# exit chroot
exit

# unmount
sudo umount /mnt/sys &&
sudo umount /mnt/proc &&
sudo umount /mnt/dev &&
sudo umount /mnt
Shutdown the system, remove the thumbdrive, and reboot into a VSIDO system.

I performed this install on a legacy BIOS system. I assume the procedure would be similar for a uEFI system, but more complicated to migrate the existing /boot and grub over to uEFI directory tree - /boot/efi.

[VastOne]

Great stuff RatMan...

Gotta run for a while but I will update all of this when I return

Thank you!

[VastOne]

Performed another install this morning. I guess it would be Method 3.

Added this content to the How To

Please look, vet and advise

Thanks

[PackRat]

For Method 1

Change:

Code Select Expand

sudo fsarchiver -v restfs vsido_23DEC2023.fsa /dev/sdxx
to

Code Select Expand

sudo fsarchiver -v restfs vsido_23DEC2023.fsa id=0,dest=/dev/sdxx
So it matches up with the SpaceFM command in image #3 but without the variable substitutions.

Take this line ahead of Step 8:

Code Select Expand

These things should be done once you boot and are logged into the new install the first time
and increase the font size or something so that the break between installing and post-install customizations sticks out.

Add change of timezone to the post install actions. I don't know about jed's install, but both times I installed the timezone was US Central Time (Chicago). I assume that's because fsarchiver preserves that information, and it's simply restored. I used this link - Set/Change timezone Debian 10. The Debian Wiki also has the info, but it's in this really, really verbose wiki page. Basically need to change a symlink.

[VastOne]

For Method 1

Change:

Code Select Expand

sudo fsarchiver -v restfs vsido_23DEC2023.fsa /dev/sdxx
to

Code Select Expand

sudo fsarchiver -v restfs vsido_23DEC2023.fsa id=0,dest=/dev/sdxx
So it matches up with the SpaceFM command in image #3 but without the variable substitutions.

Take this line ahead of Step 8:

Code Select Expand

These things should be done once you boot and are logged into the new install the first time
and increase the font size or something so that the break between installing and post-install customizations sticks out.

Done ... See if it now matches your thoughts

[PackRat]

Your quick. The fixes look good.

I added a blurb about pointing out that US Central Tiimezone is preserved in the fsarchive, so users outside that zone will need to make a change manually.

[VastOne]

Your quick. The fixes look good.

I added a blurb about pointing out that US Central Tiimezone is preserved in the fsarchive, so users outside that zone will need to make a change manually.

I added step 10a: Change your timezone, because the timezone is US Central Time (Chicago)  that's because fsarchiver preserves that information, and it's simply restored. You can use this link - Set/Change timezone Debian 10. The Debian Wiki also has the info, but it's in this really, really verbose wiki page

Thank you!

[PackRat]

@vastone

In Method 1

change:

Code Select Expand

sudo fsarchiver -v restfs vsido_23DEC2023.fsa id=0, dest=/dev/sdxx
to

Code Select Expand

sudo fsarchiver -v restfs vsido_23DEC2023.fsa id=0,dest=/dev/sdxx
can't have that space between "id=0" and "dest=/dev/sdxx"

It failed on me first two attempts, then I removed the space and it went to completion.

[VastOne]

@vastone


can't have that space between "id=0" and "dest=/dev/sdxx"

Done

Thanks RatMan

[PackRat]

Thanks
I have successfully installed twice to a clean drive and chroot in to update and install grub. So the How To for Method 3 is good.

[VastOne]

Be careful of the same UUID on the same machine if you have multiple installs. That is a natural issue with fsarchive like the time zone because it keeps it.. I think I will add how to change the UUID in the After you install section and HIGHLY recommend it be done

What say you?  It most likely won't ever hit anyone but peeps like you and I and jedi, who are constantly in testing mode, I think I will add it just to make sure that people can see it could be an issue

[jedi]

Be careful of the same UUID on the same machine if you have multiple installs. That is a natural issue with fsarchive like the time zone because it keeps it.. I think I will add how to change the UUID in the After you install section and HIGHLY recommend it be done

Might want to also be aware that SWAP may also need tinkering if you have/use one. I do on this lappy so it can go into hibernate easily.  I think I had a couple of /etc/fstab edits to make before that all settled itself as well.  I'm thinking anyone using a sid is probably pretty versatile using things like blkid and mkswap and swapon stuff on the fly... 

[VastOne]

Might want to also be aware that SWAP may also need tinkering if you have/use one. I do on this lappy so it can go into hibernate easily.  I think I had a couple of /etc/fstab edits to make before that all settled itself as well.  I'm thinking anyone using a sid is probably pretty versatile using things like blkid and mkswap and swapon stuff on the fly... 

True that.. Luckily I already had a how to on how to change the UUID to avoid conflicts and just pointed to that. I don't think it will be an issue but bases are now covered..

Thanks Jedi

Are you enjoying GMB and Pithos again?

[PackRat]

What say you?  It most likely won't ever hit anyone but peeps like you and I and jedi, who are constantly in testing mode, I think I will add it just to make sure that people can see it could be an issue

Yes, this and the potential swapfile/partition issues should be pointed out.

I didn't run into the UUID issue since it was clean install on fully formatted drive each time.

I actually created a swapfile manually instead of a partition. Appears to be working.

[jedi]

True that.. Luckily I already had a how to on how to change the UUID to avoid conflicts and just pointed to that. I don't think it will be an issue but bases are now covered..

Thanks Jedi

Are you enjoying GMB and Pithos again?

I can't believe that I went so long without.  There's been a lot of late nights playing with the machines again since the end of August!!!