Current mood! 

Both VSIDO FSA's were updated to the new 6.12.19-amd64 kernel

You can download the btrfs and ext4 fsarchives at the VSIDO download site here

There is also a How To on how to effectively use fsarchiver to get VSIDO installed

There is a current a package list that shows everything that is installed in VSIDO. Please review this file and let me know of anything needed, removed or added

Annual Greetings. VastOne. Happy Birthday.

Both VSIDO FSA's were updated to the new 6.12.15-amd64 kernel

You can download the btrfs and ext4 fsarchives at the VSIDO download site here

There is also a How To on how to effectively use fsarchiver to get VSIDO installed

There is a current a package list that shows everything that is installed in VSIDO. Please review this file and let me know of anything needed, removed or added

Both VSIDO FSA's were updated to the new 6.12.13-amd64 kernel

You can download the btrfs and ext4 fsarchives at the VSIDO download site here

There is also a How To on how to effectively use fsarchiver to get VSIDO installed

There is a current a package list that shows everything that is installed in VSIDO. Please review this file and let me know of anything needed, removed or added

As you most likely have noticed I have marked this as Pseudo-Solved. The reason for this is simple, I have not solved the core issue but I have solved my issue and can move on and this is how:

I added a completely new Linux Machine Instance in Virtual-Box. I then added 3 new vdi drives and used fsarchiver from there to rebuild the base (sda1) instance I test with. Booted perfectly. I then created two new vdi drives and one at a time tested each VSIDO fsarchive install and all booted perfectly without issues.

My assessment is that the old original files had some 'attachment' to the original V-Box Machine they were established on and was looking for something that just wasn't there anymore.

All it cost me was minute frustrations but in the end all is good again in the Dev world of VSIDO.

I have a conundrum that is driving me batty and we all know that most of us here when we can't find the solution, it's pretty fucking deep. I'll spell it out:

I have used the same VirtualBox setup on a specific drive for the last 5 years testing all the fsarchive versions of VSIDO. It's a pretty simple setup, 3 8 gig vdi partitions that I boot into sda1 then test installs of the new releases on sdb1 and sdc1. This has always worked seemlessly.

Recently I ordered and installed a new 4T SSD (Samsung EVO) and relocated the v-box files to the new SSD. I re-established everything in V-Box and the sda1 boots fine but anything I try and install on the same vdi on sba1 and sdc1 installs fine, update-grub sees them fine and on a reboot the grub menu shows them exactly as they should.

But when selecting and booting to them I get the generic message that this UUID cannot be found and yes the UUID's are correct in both the grub menu when you edit them and in all versions of /etc/default/grub ..

I have gone over at length chrooting into everything over and over and now find myself stumped. For the life of me I cannot find what UUID grub is missing and where it is missing it at.

I have googled every damn solution possible and tried them all and now am calling in arms.

That's my story.

Both VSIDO FSA's were updated to the new 6.12.12-amd64 kernel

You can download the btrfs and ext4 fsarchives at the VSIDO download site here

There is also a How To on how to effectively use fsarchiver to get VSIDO installed

There is a current a package list that shows everything that is installed in VSIDO. Please review this file and let me know of anything needed, removed or added

That's awesome RatMan.. 

We set up trail cams a few weeks back to see what was coming into the yard at night. Pretty sure we have a couple of armadillos, bit no photos of them yet.

Caught this small herd though -



Pretty sure this is a fox, photographed him a couple of times:



Sent that picture to SCDNR for confirmation.