Yesterday, 01:08 AM
It will take more time to fully-respond than I have at the moment and I can't get to the right machine, but a couple quick thoughts for now.
- Can't recall if that uses cli-installer (found in /usr/local/bin) or minstall (maybe poke around in CD loop mount) or otherwise findable on either github or gitlab or whatever it was they use -- check upstream at antiX forum. Either way, you should be better able to understand what's happening during installation once you get eyes on those.
- I think the P3 of that vintage is pushing it for Bookworm-based things in terms of X and mesa. Honestly, I'd try antiX 22-based things (still supported) to go one rev backward in the ecosystem.
- I once tested RAM limits systematically in the net installer of antiX in VBox and had installer symptoms like that with insufficient RAM. Testing from 256MB on up, incrementing by 32, the installer didn't complete successfully and install grub until 416MB was available. Not in a position to check that installer at the moment. Call it a FWIW.
- Again, I'm not in a spot to checkthe restore file package list, but you can dig in /usr/local/bin/restore for the url to the tar file, pull that down, and see if that gets you the libuuid if it's not in your installation.
The fact that you got as far as you did "by hand" means the partition sizes and machine recognition must be usable (?) although I have no experience trying such a device installation. If you have another machine on which you can install it to that same device, you can at least confirm that you get that 100% right to begin with and then just reconfigure X and change UUID's in fstab etc when back in the 600X machine
Applaud the heroic effort. Still think it's probably pushing past the hardware limits a bit, but love the initiative. If you can post an from even the live session, it might help.
Just an idea, but maybe if you get a "known good" install all the way through using another host computer, at least you can stop questioning the integrity of the baseline.
- Can't recall if that uses cli-installer (found in /usr/local/bin) or minstall (maybe poke around in CD loop mount) or otherwise findable on either github or gitlab or whatever it was they use -- check upstream at antiX forum. Either way, you should be better able to understand what's happening during installation once you get eyes on those.
- I think the P3 of that vintage is pushing it for Bookworm-based things in terms of X and mesa. Honestly, I'd try antiX 22-based things (still supported) to go one rev backward in the ecosystem.
- I once tested RAM limits systematically in the net installer of antiX in VBox and had installer symptoms like that with insufficient RAM. Testing from 256MB on up, incrementing by 32, the installer didn't complete successfully and install grub until 416MB was available. Not in a position to check that installer at the moment. Call it a FWIW.
- Again, I'm not in a spot to checkthe restore file package list, but you can dig in /usr/local/bin/restore for the url to the tar file, pull that down, and see if that gets you the libuuid if it's not in your installation.
The fact that you got as far as you did "by hand" means the partition sizes and machine recognition must be usable (?) although I have no experience trying such a device installation. If you have another machine on which you can install it to that same device, you can at least confirm that you get that 100% right to begin with and then just reconfigure X and change UUID's in fstab etc when back in the 600X machine
Applaud the heroic effort. Still think it's probably pushing past the hardware limits a bit, but love the initiative. If you can post an
Code:
inxi -Fv7Just an idea, but maybe if you get a "known good" install all the way through using another host computer, at least you can stop questioning the integrity of the baseline.