Quote from: DeepDayze on August 30, 2024, 03:32:13 PM

Quote from: VastOne on April 18, 2024, 02:42:23 PM

Quote from: DeepDayze on April 18, 2024, 01:41:59 PMBummer. Fsarchiver as a backup/restore tool for BTRFS then is no bueno. There should be some sort of override so that you can restore a BTRFS .fsa with its original UUID.

It's really a security feature to make sure that you don't have multiple instances of the same UUID booting.. IMO, the ext4 part should do the same but does now.

You could try this format above using the uuid you want to see if it would work, I never tried to restore with the exact same uuid, it may be possible. I'll test this as well

You should be able to restore your own .fsa's with same UUID.

Recent updates now allow this to happen. Not sure when it started, but you can now install on same machine with same uuid on it elsewhere

Both VSIDO FSA's were updated to the new 6.10.7-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

Quote from: VastOne on April 18, 2024, 02:42:23 PM

Quote from: DeepDayze on April 18, 2024, 01:41:59 PMBummer. Fsarchiver as a backup/restore tool for BTRFS then is no bueno. There should be some sort of override so that you can restore a BTRFS .fsa with its original UUID.

It's really a security feature to make sure that you don't have multiple instances of the same UUID booting.. IMO, the ext4 part should do the same but does now.

You could try this format above using the uuid you want to see if it would work, I never tried to restore with the exact same uuid, it may be possible. I'll test this as well

You should be able to restore your own .fsa's with same UUID.

Both VSIDO FSA's were updated to the new 6.10.6-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

Solved! The workaround was as followed which layed out here by Ash Joubert and within a chroot settings I did exactly as Ash said

Workaround was to boot from an older kernel/initrd, manually download the previous packages, downgrade to them, and then hold them.

dpkg -i kmod_32+20240611-1_amd64.deb libkmod-dev_32+20240611-1_amd64.deb libkmod2_32+20240611-1_amd64.deb
apt-mark hold kmod libkmod-dev libkmod2
I am now booted back into the nvme system. This shows how important it is to search for the exact messages which I got when I ran update-initramfs -k 6.10.4-amd64 -u in chroot and it showed the KMOD5 errors.

Thanks, that is the end of my TED speech for tonight, thank you all for attending

Found the issue but not the answer here. I need to somehow down grade LIBKMOD_5 in a chroot setting

I should also add that when I boot to any other system on this machine, all the nvme, ssd and WD drive I have are seen and available. There is nothing in the fstab that is off or has changed.

Got a new TV and made room to move my PC from the floor to a table. I never switched, touched or moved anything at all, just a simple plug back in of the cords to the same places. Upon reboot the shit hit the fan hard. Attached is the image of the actual message. It is a frozen initramfs login and I have to literally hard shutdown the box and restart it (in effect, pull the plug), nothing in bios or anywhere else helps. I have searched all day and most everything points to Goto BIOS setup,Goto SATA Configuration, Change to AHCI
save and restart except that was already set that way. On the same box I have 3 drives. THe main system is on  a nvme drive and it will not boot from there. On an additional SSD drive I have an older install in case something like this happens but I get the same issue with that one.. Both of those are nvidia graphics installs with the latest drivers and modules built into the kernel .. On the nvme it is a btrfs system and on the ssd it is a ext4 install with a two month old kernel.

The only thing I could boot to was the development instances of VSIDO which is essentially what you download now. One is btrfs and one is ext4 and neither is nvidia. I booted to both with no issues.

Now here is where it gets really fun. I have another PC that had an older version of my system so I fsarchived it and installed it on this box on the same ssd stated before and it is now what I am using to write this. It is nvidia, the fsarchive even take from a nvidia box with a different card but fsarchiver is boss! This is the btrfs version but I do not believe that is an issue at all.

I have searched as I said and have gotten nowhere so I bring this to the VSIDO guru's here, what say you?

To close this out, this is still an ongoing issue with VSIDO/Debian/Linux in having to restart the entire cpu just to restart the network and that's a bitch. The silver lining was contacting my ISP about all the down time and they noticed something was amiss during the call and for whatever reasons, I have not had a single instance of an outage since. Up to that call I was seeing it drop up to 10 times a day. 

Both VSIDO FSA's were updated to the new 6.10.4-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