Ed_P wrote: ↑22 Sep 2022, 20:58
What will you be using to boot the other systems? Porteus's menu doesn't use grub2.
I convert the way grub boots things into the way porteus.cfg boots things by looking into the grub menu file.
Ed_P wrote: ↑22 Sep 2022, 20:58
Did you ever delete a Grub2Win cfg file? Is it in your Windows Recycle Bin?
When Witless7 went kaboom it also corrupted its sda2 partition (the largest on the internal harddisk - its "C:" partition) which did hold all of /WITLESS/ and its user files and also the Neogrub-folder with the grub menu.
And most of my personal files as well since it was the largest internal partition.
I did save the ls and the find info of the files on that partition [*] some days prior the crash, and I used the then newest version of that recovery of lost files program (I posted it as x86-64 module back then - it was sometime in either late November 2020 or early December 2020 since late November is the date of the preserved intHDD1_2-preserved.find.gz and intHDD1_2-preserved.ls.gz data files) and so I was able to recover many files using the exact size and filetype and filename of what I had in my intHDD1_2-preserved.ls.gz (since the recovery program just randomly names the files, e.g. recup_dir.234/f250943360.jpg or recup_dir.234/f250952952.swc ).
When I recall correct the grub.menu file was called NST/grub.cfg or similar. I know it was a 3 character name all in CAPS for the folder, followed by grub* for the config file…
I will look into my preserved ls & find databases and then look if the menu file was recovered as some random f???????.txt file with the same file size (but different time stamp since it has the time stamp of when I ran the recovery).
______________________
[*] What my lsfind suit does is find by itself if the internal devices or the external devices are really there when I tell it to create updated *ls.gz and *find.gz datafiles - and finds by itself where the partitions are actually mounted (since external partitions can be mounted as sda* when there is no internal harddisk or sd[b-z]* when there is one internal harddisk.)
The commands to create these are the most simple part of it all:
is how my lsfind script is called - or in other words
Code: Select all
lsfind /VALID-MOUNT-PATH CORRECT-DEVICE-NAME
e.g.
The script itself then cd's into the folder where the certain partition of that drive it actually mounted, say, /mnt/sdb2 and does for ls:
Code: Select all
$lsexe -loaR --time-style="+%Y-%m-%d %H:%M" >>"${TMPDIR}${base}.ls"
and for find even more simple
Code: Select all
$findexe . >>"${TMPDIR}${base}.find"
Then a gzip for both files and the compressed files got moved back to where the script originally called sits, usually that's my ext2 container mounted in /Lsfind .
Added in 26 minutes 26 seconds:
And, believe it or not - the lsfind databases can be helpful in many ways.
Just yesterday I did a screen recording without sound and saved the URLs of the blob: video (see here:
Desktop screen recorder *with* *sound* ) in a txt file in the same folder.
Then Porteus again crashed during its suspend and I recalled wrong that the out.ogv and its out.txt are sitting in one of my /backup/ or /tmp/ folders - but I could not find them.
So I did a recent lsfind of all my internal and external harddisks (the 8th external harddisk) partitions to update the databases of both drives and ran a
Code: Select all
zgrep " 2022-09-22 " intHDD1* extHD8*|grep -vE " .$| ..$"
intHDD1 = the internal harddrive of the current PC, extHD8 = 8th external harddrive
The
|grep -vE " .$| ..$" is to exclude all ls entries of just changed folders ( referenced by ls as relative folder names of "." or ".." ) - and what I get is a list of all files that have the time stamp of yesterday aka all files that either I downloaded via wget or yt-dlp and just happen to have the server time stamp of yesterday - or
files I myself saved on that date.
And guess what? I did recall wrong and the files I was looking for was in one of my /video/ folders - not in a /tmp/ or /backup/ one.