Some questions about using KLV-Airedale

[AlexOceanic]

Okay, I suspect I know what you have done using Gnome Disks. I think you have restored the hybrid iso KLV-Airedale to the first partition of an already msdos partitioned usb stick. The result will be like using 'dd' to a partition, and the size will be that of the iso image so just under 900MiB. Problem is that is ISO 9660 format, which is read-only. Yes, that could then be booted using RAM0 mode via an already existing grub2 (from your Fedora install).

When you say "restored to the first partition" - I had manually deleted all partitions on this USB so it then presented as the full 64 GB of unallocated space and then told Disks to restore the KLV ISO to this USB

You 'could' arrange save persistence therafter to some other partition - but best to make that ext4, say, rather than NTFS which would only work with savefile and not the preferred savefolder. i.e. you 'could' format the second currently (I think) unallocated partition on your usb as ext4 and then use a grub2 kernel line argument to tell KLV to use that partition for w_changes (i.e. save persistence). Unfortunatly, that is more complicated than simply doing a normal frugal install to an ext4 read/writable partition in the first place rather than ISO 9660!

Yes that was my thinking too regarding creating a second NTFS although now understand ext4 would have been better although I suspect Disks might have failed with any filesystem type I attempted - I want to keep this simple so think I'll use another USB stick formatted with two ext4 partitions to create the KLV system and KLV save folder partitions as described in an earlier post

Also, your usb stick will not boot by itself (without the Fedora grub2 current arrangement) when restored to a first partition like that. Rather you'd need to write it to the raw disk (e.g. /dev/sda and not /dev/sda1) if you want the hybrid iso grub4dos included part to boot (without needing your Fedora grub2). That's what I 'believe' the overall current situation is anyway. Let me know if I have it wrong.

I don't understand this part - I thought with the BIOS set to boot from USB it would do so providing it found the required files on the USB drive partition (init or vmlinuz?) - I thought what you describe would be the case if I put the KLV files in a HDD partition without GRUB pointing to it as a boot option from its menu?

We can start from there. Best if you can keep your Fedora grub2 - otherwise we'll need to find some way of getting grub2 back on your system if you remove that Fedora arrangement. You probably want to remove Fedora itself by the sounds of it so we have to find a way of keeping or re-installing grub2 thereafter... Alas, that installation of grub2 is always the tricky part - installing the distro itself is almost trivial thereafter. The 'key' to keeping the Fedora grub2 arrangement is first of all knowing where everything is, and usually then keeping the Fedora /boot folder (or at least the grub2 related stuff in there) - the result is a bit messy but the /boot/grub/grub.conf can with care then be edited to work with any frugal installed distro and still, hopefully, be able to boot your Windows installation too. Isn't life easy?

LOL!
OK so I previously thought GRUB (and maybe an MBR) might reside outside of the 6 partitions in a reserved "boot area" at the start of the HDD and I could simply delete the Fed partitions without affecting GRUB but it seems that might not be the case and now that I think about it - I actually found a GRUB folder with all kinds of config files and content under in a "Boot" directory in Fedora so that's just me being stupid!
Is GPT an alternative boot record to MBR?

Truth is, probably best to forget about Fedora altogether and use some system such as 'LICK' (search forum for info about that - I've never used it) to dual boot something like FossaPup with Windows. Thereafter, you should be able to remove FossaPup but still have the boot loader (hopefully it is grub2) and then frugal install of KLV-Airedale becomes trivial/easy. Sorry I can't help with LICK though and take no responsibility if that breaks anyone's system.
Understood - I'll keep that as a potential solution to explore.
I think I need to understand more about how to setup KLV as a dual booting system with Windows as was hoping this process might have allowed me to delete the Fed partitions and create a new GRUB during the standard install process.

It is simply a fact that one matter we, in this KL/FirstRib corner, have yet to get round to is to provide installation utilities for grub2 booting and with dual boot capability with Windows. We would need a huge DISCLAIMER if we supplied such a utility since easy to break booting altogether! Personally, I tend to use a method like you have done via Fedora, though I tend to use official Ubuntu to effect dual boot with Windows, and then I use its installed grub2 (and remove most all of Ubuntu itself other than what I need kept for grub2 to work... so a bit messy really, but often gets over Secure Boot EFI boot difficulties that otherwise can cause extra problems...). The 'frugalpup' utility, forum member bigpup often recommends is fine if you don't care about dual-booting; otherwise LICK is often recommended, but that is only designed for installing Puppy Linux, not KL/FirstRib distros.
Ah ok - Understood I thought KLV had a dual boot installer like Puppy had.

Easier if you just want to make a bootable usb stick with save persistence folder on it. More efficient and convenient if you want the (much trickier) dual boot with Windows on hard disk partitions arrangement though. Let us know.

If you don't know about this already, you need to get used to using the following really: https://psearch.puppylinux.com

A lot has been asked about similar booting matters for Puppy Linux itself over the years. Here is a 'not too old' thread: viewtopic.php?t=4382
The idea of using Fedora install, or my Ubuntu variant, is also suggested by mikeslr there, but using small AntiX, which sounds reasonable approach to me, and maybe safer than the grub2config method which is particular to Puppy Linux distro and may not apply so nicely for KL FirstRib distros (unless that utility is modified appropriately). As developers it might be a good idea to study how AntiX does it, if any good, and try to adapt their mechanism - I don't really like the Puppy Linux mechanisms (though haven't as I say tried LICK, which may or may not be 'safe'...).

Here is an AntiX forum discussion on same topic. Looks like, to me, that an initial AntiX install might be the best way to go at present for a small dual boot situation with Windows: https://www.antixforum.com/forums/topic ... windows-10
And once that is going you can simply configure the grub.conf to boot the likes of KLV or whatever. We probably don't have sufficient time to re-invent the wheel, though some in Puppy crowd try to, but AntiX method looks better to me (though I haven't tried it).

Thankyou - I'll check out those links and maybe that'll achieve the result I wanted to remove a broken Fed36 - if I'm left with a functioning Anti X on a smaller partition with GRUB setup to point to Win7, AntiX and KLV that would be ok too.

Maybe another (if a little messy) solution leaving some baggage on the HDD (SATA not SSD) might be:

- Leave Fed 36 as a backup Linux/GNU HDD OS although I'll resize it down to 50GB or something
- Create a seventh sda7 ext4 partition of 120GB or so for KLV running from a newly created live USB (with recommended partition types this time!) to use as a backup/alternative save location.

Given I've got a 128GB USB stick I could use - USB storage for a Live instance of KLV isn't really an issue and even the 32 and 64GB sticks I have should be fine for months.
- Just use KLV as a daily driver

I think we've got some options now so I'm going to read through this thread again and check out the links you've provided.

I'll provide brief answers to your subsequent posts and then present a plan of action if you'd be kind enough/still have the patience to review and make any amendments that may be required for the optimal/simplest solution to achieve the updated goals.

Update
I guess an even simpler solution might be:

- Delete sda 4/5/6 leaving a single boot Win7 machine
- Create sda4 with remaining space to be used as the save folder partition by KLV running from live USB when desired and my "dual boot" functionality is simply enabled by inserting the Live KLV USB

The only baggage left then is the unspecified sda3 which is small potatoes being only 1 GB of a 750 GB HD anyway

[wiak]

I think the main point is that dual boot with Windows isn't a straight forward undertaking.

Also it is difficult for you to get across exactly how your system is organized and where are what any existing grub2 components remain.

Best to read the related threads I gave and try whatever best suits and see how you get on. Plenty ways of doing this, so others likely will also likely offer ideas once you try more and report result, but details will be essential.

[AlexOceanic]

No, RAM1 is almost never a good choice - it does not result in apps running from RAM. As I said in post immediately below the one about RAM0, 1 and 2, the way to make the sfs files all first be loaded into RAM and thus mounted and then run from there is to use the single kernel argument w_copy2ram on the grub2 kernel line. But certainly that will use RAM. Will the result be faster - probably not much in practice on a modern system using modern hard drives such as SSD devices - I expect hardly noticeable really though yes, benchmarking tests would be interesting.

Main reason I don't expect much benefit in practice using w_copy2ram is that if your system has sufficient RAM once an app is loaded it tends to stay in RAM cache anyway so it is only the initial load that is slow. Also fast modern drives like SSD are solid state anyway so not slow at all. I am presuming the use of w_changes=RAM2 mode in which case there are no continual writes back to slow usb. The whole session gets kept in RAM until you choose to save it back (save on demand via the save2flash utility).

If booting from usb stick, you definitely should aim to achieve the normal frugal install with read-write capability rather than a simple hybridiso image write to usb which ends up stored as read-only iso9660 format though (instead of read/write ext4 or similar) - that's were I found the antiX approach useful (and as alternative way to arrange dual boot with Windows on hard disk probably).

Note that issue with overlayfs is that saving back to media (save on demand using save2flash) doesn't actually free up RAM, it just makes sure persistence has a correctly merged copy of it. The other oft-used method of layering a filesystem, aufs, however, actually can clear out the RAM at that point - which is indeed a big advantage of aufs. Having said that, my system has enough RAM that that disadvantage of overlayfs approach is irrelevant to me pretty much always, but might not be on smaller RAM systems when using RAM intensive apps... then aufs would win and KL doesn't support that and aufs support isn't planned. Problem with aufs is it needs a patched kernel and aufs isn't supported by the official kernel team, so eventually I think its days are numbered (and its upstream support is limited anyway).

So I have an SATA HDD and will post the results of my benchmark tests when I try the different session types to compare.
That's a shame about the aufs but no point crying over spilt milk I guess.
It sounds like I'm probably better off going with the standard USB install so its easier to get help if I run into any issues further down the line rather than complicating things with an ISO read/write install that few others are using.

[AlexOceanic]

I think the main point is that dual boot with Windows isn't a straight forward undertaking.

Agreed - I thought I could simply delete the Fed partitions on the HDD and then install a new OS with GRUB in its place that would auto detect Win7 and create boot entries on its menu for Win7 and the new OS (and perhaps AntiX can do that by the sounds of it).
I wonder what would happen if I resized the Fed partition sda6 down from 170GB to leave 100GB unallocated space and then install AntiX there to see if it creates its own GRUB which supersedes the Fedora GRUB so I know I can safely delete the Fedora partitions completely then?
Maybe I'd need to insert a partition before the Fedora partitions for AntiX so it executes that GRUB before the Fedora one - here I go overcomplicating again but just trying to think of the safest way with a path of recourse.

Also it is difficult for you to get across exactly how your system is organized and where are what any existing grub2 components remain.

I'm gradually building a clearer picture of the system setup - I'll use Gparted or Disks to mount sda3 and see if anything is actually in it to hopefully shed more light on the situation.
I don't know how to verify if sda5 is a swap or extraneous partition but will do my best to investigate and find any clues as to its function.

Best to read the related threads I gave and try whatever best suits and see how you get on. Plenty ways of doing this, so others likely will also likely offer ideas once you try more and report result, but details will be essential.

Will do - I just don't want to make this version of Win7 inaccessible but I'm probably over worrying so long as I leave sda1/2/3 untouched.
I'm guessing the worst that can happen is I might need to edit or create a new GRUB via a new OS or even perform a Windows rescue.
I'm going to start by making a copy of the GRUB2 folder from Fed36 which successfully boots to Win7 just in case - that way at least I should have the correct addresses/instructions to transfer to a new GRUB if its unable to boot Win7 for any reason.

If I go with the AntiX approach to install GRUB2 on a USB that can boot Win7 or AntiX (and then modify to KLV) then that info might come in handy manually updating the GRUB file if it has any issues too.
I guess if it picks up the Fed 36 installation and adds that as a boot menu option, providing it showed Win7 and I've tested it boots properly, that should give me the confidence to safely remove the Fed 36 partitions and then look at whether to setup another HDD dual booting GNU/Linux OS instance in its place or perhaps set it up as an extra storage partition and just run from the Live USB's.

I'm probably using all sorts of incorrect terminology here but this is all very new to me although that Puppy guide running through how a system starts and what each file actually does was very helpful and filled in many blanks in my knowledge:
viewtopic.php?t=5818
Once I've read that another 3 or 4 times I might be able to explain things a little better .

Thanks again for your patience and know how hard it can be trying to help someone with technical issues when you can't actually see their system let alone when the goals and setup keeps changing!
I'll try a few of the things you've suggested and report back with my results.

[AlexOceanic]

I think the main point is that dual boot with Windows isn't a straight forward undertaking.

Also it is difficult for you to get across exactly how your system is organized and where are what any existing grub2 components remain.

Best to read the related threads I gave and try whatever best suits and see how you get on. Plenty ways of doing this, so others likely will also likely offer ideas once you try more and report result, but details will be essential.

Well - first the good news...

KLV rebooted successfully from usb on several reboots (that's a win at the moment where even a formerly working version of Kali on a completely separate usb was failing to load (plus Fed37 tried six ways from sunday on a separate stick) since I started trying to update GPU drivers)

I couldn't get KLV to boot in RAM2 mode unfortunately.

Where I was unable to open any Terminal emulators in the RAM0 instance of KLV yesterday, I went into Fed 36 and installed "appimage" but it kept giving an error when I tried to write the ISO to USB and Thunar wasn't able to see it any despite unmounting and remounting, switching the USB off and on with Disks.
I tried deleting the partition, formating and created a fat32 partition with Disks but appimage wouldn't flash the ISO.

I thought I'd try KLV again and it failed to load in the USB slot I had used - I put it back in the slot it was in beforehand and It booted up before GRUB as before - something learnt there at least that maybe I have a dodgy usb slot and won't be using that for any testing!).

I selected KLV's RAM0 option again (where RAM2 failed during the install process - I can reproduce and try to capture the code if helpful?) and luckily this time I was able to open the Terminal for some reason - I struck while the iron was hot and downloaded appimage but it also gave an error when trying to write the ISO and hid the USB from Thunar like Fed 36 did (screenshots now inline below?).

Screenshot_2023-02-28_23-24-47.png (289.16 KiB) Viewed 1933 times

Full Terminal showing file location.png (234.93 KiB) Viewed 1930 times

My BIOS is set to "UEFI - disabled".
I recall on one attempt that the ISO flashed with Disks by using "restore partition" and booting the AntiX USB (attempts both with and without the legacy boot flag option tick box checked) still failed to boot - even though Disks had updated its view of the USB ISO partition and reported it as "Bootable".

The reason I'm doing this is as follows - please advise if any of this is doesn't match your understanding:

- Where Fed 36 is on sda5 (see updated system overview below) and I have a working GRUB2 loader in Fed 36 - I can create an ISO of AntiX on a USB with appimage
- Run AntiX, install it to sda6 alongside Fed 36 and get a grub config file code from it
- Run Fed 36 and go into the GRUB config file settings and paste said code into the "40 data" folder in etc/grub and run "update grub" so that GRUB then shows AntiX as a boot option if I boot from the HDD (where AntiX is installed in the Fed 35 root directory with a persistent save folder also created)

If successful, then I should be able to:
-- install a version of KLV alongside Fed 36 and AntiX on sda6
-- insert the appropriate GRUB config file changes (which I might need a little help manually creating/amending from the AntiX code )
-- ideally removing the three broken Fed 36 kernel entries too at some point (the only Fed 36 with working NIC is the initial rescue kernel under the other 3 broken ones on the menu - no idea why the GPU driver update attempts affected the NIC but there you go - its a software rather than hardware issue with the NIC running under those specific three kernels but its complicated to explain why I know that so will leave that for now)

to then just show Win7, AntiX (which I could delete afterwards too) plus KLV on the boot menu.

I wonder if it's safest to leave Fed 36 unchanged as even the rescue kernel is a useful backup and it's only a few extra folders in my directories which I can ignore once I get used to the KLV folder system one level down so to speak.

I feel like I'm complicating things again... lol

Anyway, step one at this is to get a working Live AntiX USB running I guess - any other ideas on what I might try e.g. different ISO burners, partition file types, boot flags, switching UEFI (without secure boot) on etc?

Thanks

Alex

PS - Loving the "minimise window up to window top bar" function (the ^ next to minimize/maximise and Close in top right corner of windows - liking lots of the KLV features as it goes with the CPU temp and "click anywhere for menu" etc)

New system overview

WD 750 GB HDD
Partitioning - MBR

Description of partitions when viewed from within HDD installed Fed 36 using Disks

Partition 1

Size - 105 MB
Contents - NTFS - Not Mounted
Device - /dev/sda1
UUID - 56CC996ECC9948DF
Partition type ntfs/exFAT/HPFS (Bootable)

Extra info from GRUB2 grub.cfg in Fed 36
menuentry 'Windows 8'
msdos
ntfs
hd0,msdos1

grub.cfg file points to the above partition to boot "else" set root to UUID - AEBE335DBE331D71 below (includes Disks Info)

Partition 2

Size - 561 GB
Contents - Mounted at /run/media/zak/AEBE335DBE331D71
Device - /dev/sda2
UUID - AEBE335DBE331D71
Partition type ntfs/exFAT/HPFS (Not described as "Bootable")
hd0,msdos2 (my assumption)

Comments: This is Win7

Partition 3

Size - 1.1 GB (1,073,741,824 bytes - appears to be unused and probably the 1GB of unallocated space I thought I was leaving when installing Kali before Fed 36)
Contents - Ext4 (version 1.0) — Not Mounted
Device - /dev/sda3
UUID - 55df69dc-24a7-4976-b119-cf4fd1c9932b (Not described as "Bootable")
Partition type - Linux
hd0,msdos3 (my assumption)

Partition 4

Size - 188 GB
Contents - Extended Partition
Device - /dev/sda4
UUID - not provided by Disks
Partition type - Extended
hd0,msdos4 (my assumption)

Comments: Disks shows this as containing partitions sda5 and sda6

Partition 5

Size - 1.1 GB - 725 MB free (32.5% full)
Contents - Ext4 (version 1.0) — Mounted at /boot
Device - /dev/sda5
UUID - 88b91fe1-7fa1-410b-ac1d-470a48f6588c
Partition type - Linux
hd0,msdos5 (my assumption)

Comments: Is this a Fed 36 swap file?

Partition 6

Size - 187 GB — 175 GB free (6.1% full)
Contents - Btrfs — Mounted at Filesystem Root
Device - /dev/sda6
UUID - 8ac06d2b-e04d-43ac-be22-4b147c4b1a29
Partition type - Linux
hd0,msdos6 (my assumption)

Comments - This is Fedora 36

[wiak]

I've nothing myself really to add to my previous comments Alex. You just need to keep trying and hope someone sees something they can help with if you run into problems. There are so many ways to do thing.

I suppose one comment is that KLV w_changes=RAM2 mode is likely not working because you are, I assume, still booting it from a iso 9660 format usb stick which is a read-only format. You can't of course save on demand (RAM2 mode) to a read-only filesystem.

The antiX utility is also only able write a read-only (dd style image) when the host system it is used in is not antiX itself. I believe you have tried to write it as a read-write image, which would indeed error out.

I do suggest you either try LICK with a Puppy Linux distro (at your own risk of course) or
try to install antiX onto your system and if that succeeds use its grub2 to boot a normal KLV-Airedale frugal install.

Once and if you have antiX grub2 working, others can certainly then help you understand how to install KLV-Airedale as a frugal install under that scenario.

Good Luck!

[rockedge]

@wiak I have KLV rc12 running from a Windows NTFS partition with save file using a previously made disk image.

The the boot partition is NTFS but I ran Grub4Dos on it which worked. To start Windows 10 I chain load from the Grub4Dos menu.lst otherwise it will boot KLV-Airedale, Puppy Linux's.

The problems seem to be getting a solid dual boot set up. I got really lucky on this machine because it has zero UEFI and the Windows boot loader wasn't over-written by Grub4Dos.

[Clarity]

... I thought I could simply delete the Fed partitions on the HDD and then install a new OS with GRUB in its place that would auto detect Win7 and create boot entries on its menu for Win7 and the new OS ...

GRUB2, from my experiences does this automatically.

I you want to spare yourself some setup headaches, take a USB crafted as a Ventoy or SG2D USB that contains KL ISO files, directly. Then your life is simplified to Persistence management while each of the 2 (Ventoy or SG2D) provide the ability to boot Windows if it is installed on any local drives you have while providing your ability to boot the KL ISO files you have on the USB.

Just an idea as this should/could afford an easy way to continue your investigations with those simple solutions.

Almost everyone here is a guide to leading you to this simplified direct ISO file solutions.

[rockedge]

@Clarity direct ISO boot is a nightmare and not easy to keep relivable across systems and I still see no evidence that Ventoy and Co. are any easier to implement than a simple frugal install.

[Clarity]

@Clarity direct ISO boot is a nightmare and not easy to keep relivable across systems and I still see no evidence that Ventoy and Co. are any easier to implement than a simple frugal install.

All I do is download the ISO file and boot for all the benefits. It, along with Persistence does not get any easier. NO MORE disk folder, ISO extractions, GRUB-local Menu updating or other potential issues including building a USB merely for frugal use are gone for users. The premise is merely simplicity if you have a the forum prescribed Ventoy or SG2D USB stick.

Everything currently, at least in my reviews with current KL designs indicate adding an ISO file is all I need for Frugal Persistence. My testing and displays shows such.

It behaves boots the same as all the other forum distros thus far.

AM I missing somehting else? If so correct me here or offline.

[wiak]

@Clarity direct ISO boot is a nightmare and not easy to keep relivable across systems and I still see no evidence that Ventoy and Co. are any easier to implement than a simple frugal install.

All I do is download the ISO file and boot for all the benefits. It, along with Persistence does not get any easier. NO MORE disk folder, ISO extractions, GRUB-local Menu updating or other potential issues including building a USB merely for frugal use are gone for users. The premise is merely simplicity if you have a the forum prescribed Ventoy or SG2D USB stick.

Everything currently, at least in my reviews with current KL designs indicate adding an ISO file is all I need for Frugal Persistence. My testing and displays shows such.

It behaves boots the same as all the other forum distros thus far.

AM I missing somehting else? If so correct me here or offline.

Whilst I agree with rockedge that, in my opinion, grub2-based normal frugal install (and more especially in dual boot arrangement) is the best overall once it is set up, setting that up is far from easy from a start position.

I also agree that Ventoy, certainly with all current KL distro releases provides a great alternative that includes working w_changes=RAM2 persistence. I would therefore indeed recommend @AlexOceanic to prepare a bootable usb Ventoy disk to contain a folder names /BOOTISOS (best to label the partition that is in as VENTOY) and initially at least therefore get up and running with KLV-Airedale and any other KL distro (KLA..., KLU...) that they wish to do. All you need to do with such a Ventoy prepared usb is indeed to simply copy the iso into /BOOTISOS and boot Ventoy and choose from the resultant menu which KL mode (e.g. RAM2 save on demand is a good one) you prefer to use.

I wouldn't bother at first with the optional extra option of saving sessions elsewhere to a partition labelled "Persistence" though you might consider that possibility later.

i.e. For now, just make a bootable Ventoy usb with /BOOTISOS folder and put KLV-Airedale iso in it. Should work out of the box as Clarity suggests.

I support KL distros working with Ventoy in that fashion and use it for quick tests and dev work myself.

[AlexOceanic]

I've nothing myself really to add to my previous comments Alex. You just need to keep trying and hope someone sees something they can help with if you run into problems. There are so many ways to do thing.

I suppose one comment is that KLV w_changes=RAM2 mode is likely not working because you are, I assume, still booting it from a iso 9660 format usb stick which is a read-only format. You can't of course save on demand (RAM2 mode) to a read-only filesystem.

The antiX utility is also only able write a read-only (dd style image) when the host system it is used in is not antiX itself. I believe you have tried to write it as a read-write image, which would indeed error out.

I do suggest you either try LICK with a Puppy Linux distro (at your own risk of course) or
try to install antiX onto your system and if that succeeds use its grub2 to boot a normal KLV-Airedale frugal install.

Once and if you have antiX grub2 working, others can certainly then help you understand how to install KLV-Airedale as a frugal install under that scenario.

Good Luck!

The problem is I'm stuck at the first hurdle (AntiX failing to write the ISO to USB in both Fed 36 and KLV with the approved application) and it seems the only live USB type that boots on this machine is the ISO9660 KLV (and even that seems to fail now and then with no changes made - a bit like the NIC which seems to do the same).

I've tried a large number of configurations like formatting the USB as GPT, EXT4 trying various partition boot/legacy boot flags, setting up the filesystem like the one ISO that actually works which appears to be MBR, fat32, Hidden HPFS, NTFS, bootable but I can't geta version running with save persistence, BIOS settings like UEFI on/off, legacy BIOS boot on/off but the number of possibilities are endless and its like trying to figure out a combination lock.

Where even the working ISO seems to fail sporadically, I might even have found the right configuration and it failed!

I was hoping I might find the official install method that should work and then try the smaller number of BIOS changes that I might have somehow misconfigured until it boots but to be tweaking those whilst trying various USB file system configurations too is just impossible and huge number of possibilities.

It also doesn't make sense to me that failed GPU driver update attempts on Kali and then Fed 36 would have changed anything to do with how this pc boots live USB's but then I didn't think it could affect the NIC either .

The fact that a formerly working Kali ISO on a separate usb stick now isn't working tells me there's an underlying problem with USB booting - even after I've reloaded the default BIOS settings.

Where the NIC issues started occurring on the three Fed 36 kernels (and even occasionally on the rescue Fed 36 kernel now) after I tried updating the GPU driver, it indicates either those actions have cause an issue or perhaps it was just coincidence and the hardware might even be failing. I think I might have even copy/pasted some Raspberry PI code into the terminal in Fedora when trying various fixes for the GPU driver and every kernel reports the NVidia kernel module couldn't be loaded and its falling back to Nouveau each time I boot up Fed 36 (including the rescue)

With so many unknowns, this is why I wanted to try and start from scratch again by wiping the GNU/Linux partitions and using the official defualt settings/methods for burning and loading the Live ISO's but the USB loading issues are preventing me from even doing that.

I've just seen a number of other posts on this thread now so will go through those and try those and your suggestions above.

Thanks again for your efforts to help and will provide an update if I ever do get the issue(s) fixed.

Alex

[AlexOceanic]

... I thought I could simply delete the Fed partitions on the HDD and then install a new OS with GRUB in its place that would auto detect Win7 and create boot entries on its menu for Win7 and the new OS ...

GRUB2, from my experiences does this automatically.

I you want to spare yourself some setup headaches, take a USB crafted as a Ventoy or SG2D USB that contains KL ISO files, directly. Then your life is simplified to Persistence management while each of the 2 (Ventoy or SG2D) provide the ability to boot Windows if it is installed on any local drives you have while providing your ability to boot the KL ISO files you have on the USB.

Just an idea as this should/could afford an easy way to continue your investigations with those simple solutions.

Almost everyone here is a guide to leading you to this simplified direct ISO file solutions.

Thanks Clarity

So I started using the below guide to install Ventoy on the Fed 36 running on my HDD and found:

1. Alt + Shift + T doesn't open a Terminal (minor point - I can open it in other ways)
2. I just saw that the Fed 36 Terminal seems to be using a void distro in Terminal per the screenshot i.e. user@void-live rather than user@fedora which seems mighty strange.

https://www.addictivetips.com/ubuntu-li ... toy-linux/

Screenshot from 2023-03-01 16-10-11.png (11.2 KiB) Viewed 1982 times

In simplified/noob terms it seems to indicate I'm somehow running as a KLV/void rather than Fedora user?

Other potentially relevant factors:

- I've got 4 usb slots, 1 has a USB mouse wireless receiver always plugged in
- There are two KLV ISO USB sticks plugged in
- One is the 64 GB KLV ISO that only runs in RAM0 and its plugged into a USB that doesn't seem to boot Live USB's
- One is a 32 GB USB with four GPT partitions (9GB, 10GB, 11GB and 1GB - the first three partitions each have a KLV ISO (flashed to them with different characteristics to see if one of them managed to boot) and this stick is in the slot that does boot the above 64 GB ISO but it didn't work and progressed to the GRUB2 menu on rebooting where I booted up the Fedora Rescue kernel which I'm typing this from and attempting the Ventoy USB creation

Where I've been unable to boot a previously working live Kali ISO USB and a number of Fed 37 ISO's which should have worked too having followed official and also alternative flashing methods, could there be an issue with accounts or users causing this problem do you know?

I started having issues with USB booting and NIC since trying to update my GPU driver on HDD installed Kali and then Fed 36.

Just mentioning in case you or anyone has seen this type of issue before and it might have been related to running as the wrong user/account rather than root or something?

I'll progress with the Ventoy USB creation anyway and see what happens...

Alex

[AlexOceanic]

... I thought I could simply delete the Fed partitions on the HDD and then install a new OS with GRUB in its place that would auto detect Win7 and create boot entries on its menu for Win7 and the new OS ...

GRUB2, from my experiences does this automatically.

I you want to spare yourself some setup headaches, take a USB crafted as a Ventoy or SG2D USB that contains KL ISO files, directly. Then your life is simplified to Persistence management while each of the 2 (Ventoy or SG2D) provide the ability to boot Windows if it is installed on any local drives you have while providing your ability to boot the KL ISO files you have on the USB.

Just an idea as this should/could afford an easy way to continue your investigations with those simple solutions.

Almost everyone here is a guide to leading you to this simplified direct ISO file solutions.

So I continued to try and install Ventoy on the 32 GB USB stick (overwriting the four previously described partitions I assumed) and, although it appeared to install successfully, the USB stick cannot be seen by the Fedora file manager and even Disks has very minimal info per the attached screenshot.

Screenshot from 2023-03-01 17-00-24.png (216.64 KiB) Viewed 1975 times

I don't know if the critical errors reported in the terminal window (bottom left of pic) have anything to do with it?

I'm going to reformat the USB with the default format settings in Disks (MBR/DOS) and all partitions deleted and try again....

Now Disks shows the Partitioning as MBR but Contents and Partition Type are still "Unknown".
The File Manager still doesn't show the USB stick at all even after restarting the File Manager.

Updated screenshots including GParted view of sdb1:

Screenshot from 2023-03-01 17-13-52.png (155.6 KiB) Viewed 1967 times

Screenshot from 2023-03-01 17-19-03.png (41.91 KiB) Viewed 1967 times

I'll try booting to KLV Live RAM0 and see if Thunar can detect the USB and alow me o place an ISO from another USB stick in the Ventoy partition.

Update:

Now the one remaining usb that would boot KLV USB ISO Ram0 isn't working with no changes being made to that USB stick - I tried twice (hit "c" then "Reboot" from the GRUB2 menu it shouldn't have reached).

Also just noticed that when I slightly moved the KLV USB ISO in the "formerly working" slot it unmounted the device - another slight movement and it remounted - I wonder if I'm dealing with failing hardware here (we're on a boat and sea air probably isn't helping matters)...

Still doesn't explain why only Disks and GParted could see the Ventoy USB where file manager couldn't though and Terminal is still logged as user@void-live after Fed 36 reboot.

Also heard the "click" sound when putting the Ventoy USB in the mouse receiver USB slot but it still doesn't show in filemanager - only in Disk utilities.

Will see if the USB slot used for mouse receiver can boot KLV and try wiggling it gently in the working slot...

Update2

Failed to boot previously working KSV ISO in previously working USB slot and mouse receiver slot. I just saw that even typing hard seems to unmount then remount in the prev working slot although when I was testing - I used "ls" in the GRUB2 cls and could see HD1 and (HD1, msdos1).
I'll try again and type gently this time but it seems unlikely that GRUB would see the KLV USB whilst BIOS (or whatever it is that boots USB's before GRUB) could not...

[Clarity]

Something interesting is going on with your hardware....maybe.

Reason: I see a GParted which seems that the creation process or some action (hardware/software) erased the partition #1 of that USB, 'sdb'. Is the GParted you are using old, maybe?

If you used the Ventoy creation steps, your partition #1 should be an exFAT labeled Vemtoy. Could the Fedora not know how to expose exFAT partitions? To test your GParted on Fedora

1. Open Gparted

2. on partition 1 (sdb1), right-click to get the drop-down and select Format

3. scroll the list of filesystems and choose exFAT if its offered

do you see exFAT?

f will try to trace your steps to create the USB.

[AlexOceanic]

Please see responses in line/bold below:

Something interesting is going on with your hardware....maybe.

Reason: I see a GParted which seems that the creation process or some action (hardware/software) erased the partition #1 of that USB, 'sdb'. Is the GParted you are using old, maybe?
I am using GParted v1.4.0 which is pre-installed in Fedora 36

If you used the Ventoy creation steps, your partition #1 should be an exFAT labeled Vemtoy. Could the Fedora not know how to expose exFAT partitions? To test your GParted on Fedora

1. Open Gparted

2. on partition 1 (sdb1), right-click to get the drop-down and select Format

3. scroll the list of filesystems and choose exFAT if its offered

do you see exFAT?
Yes it was able to format as exFAT (see screenshot of operation - note USB name is sdc1 as KLV USB also mounted as sdb1.
I'm now also able to see sdc1 mounted in the file manager again
Will retry Ventoy install...

Screenshot from 2023-03-01 18-24-02.png (57.19 KiB) Viewed 1950 times

f will try to trace your steps to create the USB.

Update1

Upon opening Ventoy - it shows it is still installed on the 32GB stick after the partition type change to exFAT (I didn't realise it would retain the data) so I didn't hit "Install" yet.

Screenshot from 2023-03-01 18-29-20.png (136.41 KiB) Viewed 1933 times

I wonder if its worth deleting and reformatting the stick with MBR partitioning and exFAT partition type (as it is now) and re-installing Ventoy to be on the safe side?
Also - sdc1 now has the Label VTOYEFI in Gparted now but it does not have that label under File Manager - when I right click and view properties it shows EBFF-D818 (UUID reported in Disks and GParted)

Note that Disks is reporting the partition type currently as NTFS/exFAT/HPFS (Bootable)

Sorry to introduce yet another variable but I just realised there were 6 neodymium magnets near the side of my computer that has the three USB slots I've been using - they are now removed but this might explain some of the sporadic behaviour with formerly working ISO's too perhaps if the USB's were close to the magnets as I put them in/took them out....

Also - I think its actually the 64Gb KLV ISO USB contacts that are getting worn as all other USB's fit tightly and are not suffering from the "unmounting if physically knocked" issue.

Update2

Just tested the Kali USB ISO and it booted!
I almost installed it over the broken Fed 36 on sda4(containing 5 and 6) but wanted to copy some files to USB beforehand so booted back into kernel 1 of 3 (not the rescue kernel I'd been having to select from GRUB2 as it was the only kernel left with working NIC settings) and lo and behold the NIC worked too since moving these magnets away!

Should I hit "Install" or "Update" on the Ventoy USB we applied the exFAT to or format it completely again first and reinstall from scratch?
I'm guessing we'd format it to MBR/exFAT?

[AlexOceanic]

@rockedge

Just to say, after I'm up and running on KLV, I'm happy to update the name of this thread to something more appropriate like "Diagnosing intermittent usb boot/nic issues - it was nearby magnets!!!" as not sure this will be useful to anyone with questions about using KLV although there's lots of good info in there I guess - up to you

[rockedge]

Glad to see you are up and running.

Let's leave the topic just as it is for now

Not often that magnets are knocking out the USB

[Clarity]

OK, I see that yu are using Ventoy's utility v63. That's OK, for forum distros, but, for Fedora, I wonder if you should UPDATE your utility to the latest Ventoy...now at v88.

If so and you run the latest Ventoy, it will offer the same Install or UPDATE option. UPDATE will retain all the prior folders, ISO files, and such while INSTALL will RECREATE the USB where you will need to recreate the BOOTISOS folder and add your ISO files to it.

My assumption is that the UPDATE (and Install) will add intelligence for handling the Fedora boot issues, and others too, you are seeing....guessing.

Hope this note is helpful as it seems you are on the right track for booting forum ISOs found. One you are comfortable, as @wiak has suggested indirectly, come back here for some of the proven ways of handling and managing Persistence for all the forum distros.

Persistence is the same 'externally', but each family of forum distros aka PUPs, DOGs, KL have slightly different management and namings for Persistence. This means we forum users must understand this to benefit from the proven tests we've done over the past few years since booting directly from ISO files for frugal operations began beneficial use and popularity in the LInux world..

[AlexOceanic]

OK, I see that yu are using Ventoy's utility v63. That's OK, for forum distros, but, for Fedora, I wonder if you should UPDATE your utility to the latest Ventoy...now at v88.

If so and you run the latest Ventoy, it will offer the same Install or UPDATE option. UPDATE will retain all the prior folders, ISO files, and such while INSTALL will RECREATE the USB where you will need to recreate the BOOTISOS folder and add your ISO files to it.

My assumption is that the UPDATE (and Install) will add intelligence for handling the Fedora boot issues, and others too, you are seeing....guessing.

Hope this note is helpful as it seems you are on the right track for booting forum ISOs found. One you are comfortable, as @wiak has suggested indirectly, come back here for some of the proven ways of handling and managing Persistence for all the forum distros.

Persistence is the same 'externally', but each family of forum distros aka PUPs, DOGs, KL have slightly different management and namings for Persistence. This means we forum users must understand this to benefit from the proven tests we've done over the past few years since booting directly from ISO files for frugal operations began beneficial use and popularity in the LInux world..

Well - I'm pleased to report some positive progress for once!

After all four of the Fed36 kernels decided to go "black screen" during boot up (for no reason I could see) - I tried the Kali ISO again (sans magnets) and it finally booted up.

I installed Kali over the broken Fed 36 (manually deleting sda5 and 6 in the process (sda4 wasn't selectable)

I selected the option to overwrite the GRUB file on HD0 and it fixed the messed up Fed 36 GRUB2 situation too!

I installed the latest Vento v88 as suggested and installed it to the old "Ventoy USB attempt" stick and it completed successfully.

I put AntiX, Fed 37 and KLV in the Ventoy directory, hit UPDATE and Ventoy has successfully booted at start up as expected each time with all three OS's selectable (and saw the options to boot from local for Windows)

I couldn't get AntiX or KLV to boot in Normal or Grub modes though with a couple of different attempts including the AntiX failsafe and KLV RAM0 - gave a waiting for /dev to be populated and timed out, entering "exit" produced attempts to do the same for another directory then it goes into kernel panic and its hard reset time.

Fedora 37 Live ran great from normal mode although it did hang for a long time during the boot and came up with an error but then continued to boot and function as normal.

Hopefully a few tweaks here and there will iron out the AntiX and KLV boot issues and I'll have a very customisable machine OS wise!

Really useful for new users to more easily try out new distros with a lot less hassle.

I also need to get my head around this persistent storage to RAM on the same directory the ISO is stored in (instinct tells me to shrink the Ventoy partition to half and create another partition (SaveFileFolder?) that AntiX and KLV can use for persistence?)

Once I get my Nvidia driver and Blender installed on KLV then I think I'll be there but that's one for tomorrow I think - lol

Anywho - feeling much better about things now and really appreciate everyone's help on this rather unusual catalogue of errors I managed to brew up - lol

Its amazing how much you learn by breaking and then fixing things eh...

@rockedge
@mikewalsh
@wiak
@Clarity

Oh and you'll kick me for this....

I forgot that, in a moment of madness, I thought I'd try copy the contents of a KLV ISO to sda3 (the 1GB chiunk of space I left on the HDD when setting up the initial Fed 36, then Kali then broken Fed36 dual boot with Win7. PErhaps, because its not set to "boot", it might still get recognised and some of the scripts run during boot up of whichever OS is actually loaded hence the user@void rather than user@fedora issue. I see that Kali has set me up as zaq so that doesn't seem to be an issue anymore but I should probably just delete or wipe sda3 - maybe it'll come in handy further down the road.

[wiak]

Check this KL-related information revarding its use with Ventoy. Done this way, no user work is required to get w_changes=RAM2 save on demand mode working. It just does. If it doesnt that would be a different kind of problem such as failing hardware or missing firmware:

viewtopic.php?p=82242#p82242

[Clarity]

I will attempt some valid comments on the following 3 items:

... I put AntiX, Fed 37 and KLV in the Ventoy directory, hit UPDATE and Ventoy has successfully booted at start up as expected each time with all three OS's selectable (and saw the options to boot from local for Windows) ...

... I couldn't get AntiX or KLV to boot in Normal or Grub modes though with a couple of different attempts including the AntiX failsafe and KLV RAM0 - gave a waiting for /dev to be populated and timed out, entering "exit" produced attempts to do the same for another directory then it goes into kernel panic ...

... I also need to get my head around this persistent storage to RAM on the same directory the ISO is stored in (instinct tells me to shrink the Ventoy partition to half and create another partition (SaveFileFolder?) that AntiX and KLV can use for persistence?) ...

1st paragraph
I assume you placed those ISO files in the BOOTISOS folder you created on Ventoy USB partition #1...Correct???

2nd paragraph
When booting KLV from its ISO file, did you allow the boot to proceed without hitting the enter-key OR did you merely hit the enter-key to allow the default boot? I ask to try to follow which of KLV's boot menu item you selected.

3rd paragraph
Althougt I have NEVER tried either of the 2 approaches you mention for persistence on a USB, I offer these ideas.

• Best of my ideas:

  • Create a 3rd partition formatted as a Linux format (i.e. ext2/ext3/ext4)

  • BE SURE to set its label to "Persistence"

  • BE SURE to make a folder named "Sessions" for your persistence files/folders to reside on this partition for all of the forum testing you do. This housekeeping is essential for your understanding all of the forum's PUPs/DOGs/KLs persistence; no matter where the Persistence partition resides on your PC.

• Next best without creating a 3rd partition:

  1. Create a "Sessions" folder on partition 1

  2. change the label name of partition 1 from Ventoy to Persistence

If possible, I would advise you consider a Persistence partition on your system drive...assuming space exist for you to do. KL series distros know to look for a partition labeled Persistence for couple pieces of its boot/shutdown needs for persistence to make our user lives 'simple and easy' due to this clear-eyed housekeeping.

Hope this is a helpful view to your achieving success moving forward.

P,S, It is known that I do not recommend use of USBs for any interactive system's operations. Thus I NEVER recommend USB use for installing an OS on it. Thus attempts at using a USB for a frugal use I do not advise. My tests have shown this to not match what a user has by using his system drive for any frugal needs. Frugal is defined by me as any OS that once booted will save its session, retrievable upon reboots. Direct ISO file booting and saving a session IS A FRUGAL installation-use case. This thread is not the place for this discussion as I only post it here to let you know some of what I've found in USB Frugal use...particularly in the performance AND repeatable stability areas. if more concerns for USB use in this manner, feel free to open a thread to discuss such.

You're up and running...That's the important piece in dealing with the PCs hardware.

[AlexOceanic]

Check this KL-related information revarding its use with Ventoy. Done this way, no user work is required to get w_changes=RAM2 save on demand mode working. It just does. If it doesnt that would be a different kind of problem such as failing hardware or missing firmware:

viewtopic.php?p=82242#p82242

Thanks wiak

Actually I've just been reading through the KLC RC12 release notes and think a lot of my questions will be answered by trying out this new version in the various modes with different partition setups (which I need a bit of practice with!) and I've duplicated some queries with Clarity too so please ignore the below for now.

A couple more questions on this if I may?

Method 1 (Label only required on the partition you want save persistence on): All of Ventoy, SG2D, and Qemu can use save persistence to any partition anywhere on your system (e.g. on hard drive or usb stick) that has been labelled Persistence and puts it in (auto-created) directory Sessions. For this mode, neither the Ventoy, SG2D, nor Qemu partition needs any label.

Where I'll have a number of distro ISO's in the Ventoy USB directory "Ventoy" and want to set up persistence (a save folder) in the same USB (and the Ventoy directories have used the entire USB memory) - would it be acceptable to resize the Ventoy partition to half the available memory then create a separate partition called "Persistence"?

Method 2 (Label Ventoy, or SG2D, or Qemu required): Ventoy can also put save persistence onto its own bootfrom media as long as the Ventoy main data disk is Linux formatted and given label 'Ventoy' (savefolders get automatically stored there into a directory auto-named Sessions - no user interaction required at all).

Alternatively - I can change the partition type on the existing Ventoy partition from MBR/exFAT to EXT4 and then KLV will create a sessions folder in the same directory that the ISO's are stored in?
Is EXT4 the correct Linux format to convert to and do I also need to change the Partitioning from MBR to GPT perhaps? (I'm guessing this would require formatting the USB and reinstalling Ventoy)

There are no such label requirements as the above for normal frugal install scenarios of any current KL distro.

I'm still a bit confused about the frugal install of KLV.
It seems a frugal install can be either installed alongside another fully installed distro in the same HDD partition or in its own, separate Puppy partition.

Having read the puppy frugal install guides it seems they use a Puppy Installer under Settings - I couldn't see this in KLV Settings although when searching applications I did find a"Run Install" application - is this what I should use for frugally installing KLV?

Rather than shrinking the Kali partition - I'd like to install it alongside Kali (installed with a "Home" directory) in the same partition (which I think will automatically have save persistence?) but even if I do get it installed, how do I boot it?
Do I update the Kali GRUB2 bootloader config files to include KLV as a boot option?

Would it be easier to shrink Kali and create a separate KLV partition then run "update-grub" so it picks up the new KLV install?

Is there a guide for a KLV frugal install you could point me to or would you be kind enough to help me understand the process to install and boot it please?

Many thanks

Alex

[AlexOceanic]

1st paragraph
I assume you placed those ISO files in the BOOTISOS folder you created on Ventoy USB partition #1...Correct???
If by "BOOTISO folder" you mean the sdb1 exfat Ventoy partition with "boot" flag (as opposed to the sdb2 fat16 VTOYEFI partition with "esp" flag) then yes - I copy/pasted the three ISO's into this directory using file manager.

2nd paragraph
When booting KLV from its ISO file, did you allow the boot to proceed without hitting the enter-key OR did you merely hit the enter-key to allow the default boot? I ask to try to follow which of KLV's boot menu item you selected.
No I've been trying to use the RAM2 persistence options - I think I tried the one which I thought would save to sda1 (HDD) and another RAM2 option - I forget which now - I also tried the Ram0 default option but all three failed.
I just tried booting it in "Memdisk" mode and it went to a GRUB4Dos cls - I hit "ls" and saw "boot, initi.gz and vmlinuz amongst other things - boot didn't work (error thatthe kernel needed to be loaded first I think) so I entered init.gz and it loaded something like 70 of 90 items and then seemed to hang - I wasn't sure what I was doing so maybe this was the expected result and should've run something else.

3rd paragraph
Although I have NEVER tried either of the 2 approaches you mention for persistence on a USB, I offer these ideas.

• Best of my ideas:

  • Create a 3rd partition formatted as a Linux format (i.e. ext2/ext3/ext4)

  • BE SURE to set its label to "Persistence"

  • BE SURE to make a folder named "Sessions" for your persistence files/folders to reside on this partition for all of the forum testing you do. This housekeeping is essential for your understanding all of the forum's PUPs/DOGs/KLs persistence; no matter where the Persistence partition resides on your PC.

• Next best without creating a 3rd partition:

  1. Create a "Sessions" folder on partition 1

  2. change the label name of partition 1 from Ventoy to Persistence

If possible, I would advise you consider a Persistence partition on your system drive...assuming space exist for you to do. KL series distros know to look for a partition labeled Persistence for couple pieces of its boot/shutdown needs for persistence to make our user lives 'simple and easy' due to this clear-eyed housekeeping.
Thanks although I thought the "Sessions" folder would be automatically created?
I'll try shrinking the Ventoy partition and then creating an additional ext4 partition called "Persistence" and see what happens.
If Ventoy doesn't like it I'll format the USB (GPT or MBR?), create two ext4 partitions, install Ventoy on the first, name the second, ext4 partition "Persistence" (I'm expecting Ventoy to create a third "fat16 VTOYEFI partition" during install)

P,S, It is known that I do not recommend use of USBs for any interactive system's operations. Thus I NEVER recommend USB use for installing an OS on it. Thus attempts at using a USB for a frugal use I do not advise. My tests have shown this to not match what a user has by using his system drive for any frugal needs. Frugal is defined by me as any OS that once booted will save its session, retrievable upon reboots. Direct ISO file booting and saving a session IS A FRUGAL installation-use case. This thread is not the place for this discussion as I only post it here to let you know some of what I've found in USB Frugal use...particularly in the performance AND repeatable stability areas. if more concerns for USB use in this manner, feel free to open a thread to discuss such.
Thanks and I might well look into your concerns further once I'm settled - I think I'd still take the trade off of the convenience of having a "pc in your pocket" and less reliability by having a frugal USB install, perhaps mitigating the risks by saving to both the USB persistence directory and a duplicate HDD persistence directory if such a thing is possible (or just create weekly backups of the USB persistence directory in the HDD).
I guess when working on my own pc I can run from the HD and do a reverse backup of the Persistence directory to the USB for when I want the portability to bring my "pc in a pocket" with me and have it updated with the latest data.

Update1

I was unable to resize the existing Ventoy USB partition to create a third partition so I changed the partition type to ext4 and changed the label to Persistence, added the Sessions folder but it didn't work.

I tried manually formatting the USB as ext4 with two partitions and installing Ventoy to the first, labelled the second (large) partition as Persistence but that didn't work and was getting a "permission denied" error when trying to copy a "Sessions" folder into it (the option to create a folder there is greyed out).

I tried installing Ventoy again and told it to create two GPT (better for Linux/GNU systems?) partitions (which left 15GB unallocated at the end of the disk) - created an ext4 partition in the unallocated 15GB and labelled it as Persistence but that didn't work as still got the "permission denied" error when trying to copy a "Sessions" folder into it.

I wonder if its because I'm using Kali and have a feeling I'm not acting as root user by default - I think I can change that with sudo -i though...

Managed to open Persistence dir as root and create folder - retrying with KLV RC12...

Nope - Ventoy won't boot now for some reason - I did check the "Align partition with 4KB" option in Ventoy which maybe I shouldn't have done?

I think Gparted was aligning to Mb when it deleted the prior partitions and created a single ext4 partition but think this is irrelevant because when I subsequently installed Ventoy it would have reformatted and created the partitions per the configuration I setup.

Just saw that the sdb1 Ventoy partition has a msftdata flag rather than "boot" as it did previously - will try manually updating to boot and retry...

So I saw from prev screenshot of default Ventoy that main ISO exFAT storage partition should be set to "boot" and the small fat16 VTOYEFI partition should be esp but Gparted only lets you set flags on these partitions as boot AND esp - if you try to uncheck esp it unchecks boot and vice versa...

Update2

OK so I went back to basics and got Ventoy to clear itself from the USB and reinstall itself as a single GPT partition without preserving any space.
I saw that "align partitions with 4KB" was checked
I also noticed "secure boot" is checked but haven't touched this during any tests so presume this is default and how it wrote on the previously working writes - my UEFI is also switched off in BIOS.
I wondered if my system doesn't like GPT for some reason but could've sworn it was setting Rufus to burn Kali in a GPT partition was what got it to load when I first tried it a few months back.
Look at the Kali ISO in Gparted it doesn't say whether its GPT and just reports it as ISO 9660.
Interestingly - I just looked at it from Disks and its showing as MBR so either it defaulted to GPT during Kali write for some reason or I'm misremembering.
Will run some tests with Ventoy in MBR write mode...

So I just got Ventoy to create a fresh install as MBR w securboot on and "align partitions with 4KB" checked and it booted but the second grub4does menu option of KLV 12 (RAM2 save on demand to Persistence_Sessions) failed with kernel panic again but I think that's expected where it couldn't find a "Persistence" partition or a "Sessions" folder?

Will now perform another Ventoy install with settings as above but leaving 15GB space of this 32 GB stick after the ISO directory which I'll then create an ext4 partition called Persistence in and put a folder called Sessions in there....

So Ventoy and KLV booted but boot attempt of RAM2 on demand save w pers ended with kernel panic again unfortunately.
Not sure what else to try other than the other RAM2 options and see if they work but it feels like I'm setting up this Persistence partition incorrectly.
I did notice that by creating an MBR file structure on the disk, when I went to create the ext4 Pers partition it allowed me to set it as "primary" or "extended" - it feels like it should be extended with the Ventoy partition as primary but if I select Extended then I can't select the partition type of ext4 (or any type at all - its just not an option then) - unless an extended partition is ext2,3 or 4 as default...

OK - trying again from scratch with a Ventoy wipe/new install and will set Pers partition as "extended"...

(Just to add all these Ventoy/KLV tests have been run in "normal" rather than "grub" or "memdisk" mode)

So I don't think that is going to work where, although Gparted letme add the label "Persistence", it had nothing in the Label field once the operation was complete.
Also, I can't mount the device to add the "Sessions" folder to it.
I'm going to add a folder called "Persistence" containing a folder called "Sessions" in Ventoys' ISO directory plus a separate folder called "Sessions" and see what happens...

Nope - worth a shot though - any other thoughts on what I might try or can you briefly describe how you run KLV with persistence/Ventoy so I can emulate please?

[rockedge]

There is no Kennel Linux installer programs fully formed and coded yet. Lots of room for development on this front.

[AlexOceanic]

There is no Kennel Linux installer programs fully formed and coded yet. Lots of room for development on this front.

Ah ok - I guess KLV and the kennel distro's are too different from Puppy to use an easily amended version of Puppy's installer perhaps?

It seems AntiX is able to install itself in the same partition as an existing distro on the HDD so maybe that's something I need to understand more and see if the same could be done for KLV to enable me to run KLV from a HDD (or perhaps setting up another HDD partition for KLV alone might be simpler).

I'll do some experimenting setting up KLV on USB with persistent storage in the same USB both with Ventoy and with a linux formatted USB to use it in its intended form too.

Maybe I'll even try to figure out some code or use a scheduler to auto-write the USB persistence folder to a "Persistence backup" folder somewhere on the HDD to alleviate Clarity's concerns around USB reliability.

I think the "save at end of session" function in KLV to reduce the number of writes to the USB is a great idea too.

At the end of the day, I've pretty much resolved all of the major issues I was encountering with everyone's help so that's great and I'm in a good place to start tidying up extraneous partitions etc and do some experimenting!

Out of interest - where I copied the contents of the KLV ISO directly to the root of sd3 (the blank 1 GB partition) - if I changed the partition flags to "boot" (and perhaps changed it to a Linux partition type if its not already) do you think would that boot KLV and perhaps be recognised by GRUB and added to the list of available OS's to choose from (Win7/Kali currently) after updating it?

[AlexOceanic]

Check this KL-related information revarding its use with Ventoy. Done this way, no user work is required to get w_changes=RAM2 save on demand mode working. It just does. If it doesnt that would be a different kind of problem such as failing hardware or missing firmware:

viewtopic.php?p=82242#p82242

Just to say Update 2 of the below post describes my most recent attempts to get KLV with save persistence on the same USB working with Ventoy - I know I've been pretty verbose in some posts!

viewtopic.php?p=83155#p83155

I feel like it needs to be an ext4 secondary partition rather than the primary partition that Gparted is forcing me to create the Persistence partition as.

I've also attached a screenshot of the error I keep encountering in every attempt of running the second KLV option (RAM2, save on demand to Persistence_Sessions) in case it gives a clue as to what I'm doing wrong with the Persistent partition (or boot?) set up.

Screenshot_2023-03-02_22-53-43.png (466.75 KiB) Viewed 2068 times

I guess I could try renaming that spare 1GB partition in sda3 as Persistence (formatting as ext4 first) and seeing if Ventoy autocreates the required folder as expected?

Would I choose either of "RAM2 save on demand to sda1/sessions or direct saves to sda1/sessions" if I wanted to point to the hdd for the persistence partition or would this only work if my sda1 really was ext4 and labelled as a Persistence partition and not the Win7 boot or recovery partition like it is on mine currently? (I didn't know if it would search the remaining hd partitions if it didn't find it in sda1)

Update

I just tried using Disks to delete the Persistence partition and create a new ext4 partition which I was able to label as Persistence (don't know if it's primary or secondary) and put a Sessions folder in there - I'll try again after deleting the Sessions folder in case it caused an issue but it seems the problem now is KLV being unable to find the Boot partition during install to my untrained eyes.

Screenshot_2023-03-02_23-09-48.png (72.74 KiB) Viewed 2058 times

This is the code I see before KLV install crashes from Ventoy using:
RAM0 No persistence w copy2ram (hadn't tried it before)
RAM2 save on demand to sda1/Sessions w_copytoram (I might try adding a "Sessions" folder to sda3 now I've finally identified it as a redundant ext4 Fedora 36 partition)

(Unable to upload 400KB screenshot in this or even a new reply post for some reason)

I'd also add that something seems to be upsetting all three distro's where:

Only KLV RAM0 (first option) appears to be able to boot of all its variations
Kali Live started loading then crashed with a multitude of errors before freezing like KLV
Fed 37 Live gave black screen for a long time before displaying a single error line at the top like "dracut .... sysctl: no such file or missing but then it did actually launch successfully

[Clarity]

Hello @AlexOceanic

I read over your work and see multiple attempts with varied configurations of your PC. Check your PM, soon, as I am going to give you access to an image file that I know boots F96 AND KLV.
Reason: Want to see if we can narrow down your efforts determining if the problem is your PC configuration or a component of the distros and your hardware.

I hope to have to get a PM to you in an hour from now.

Since it is a known working img disk that boots on some of my old hardware, it should work on yours as well.

By the way, what OS did your PC come with originally? Post here to this thread with that answer as its important to know for it infers a date-era of your PC.

[AlexOceanic]

Hello @AlexOceanic

I read over your work and see multiple attempts with varied configurations of your PC. Check your PM, soon, as I am going to give you access to an image file that I know boots F96 AND KLV.
Reason: Want to see if we can narrow down your efforts determining if the problem is your PC configuration or a component of the distros and your hardware.

I hope to have to get a PM to you in an hour from now.

Since it is a known working img disk that boots on some of my old hardware, it should work on yours as well.

By the way, what OS did your PC come with originally? Post here to this thread with that answer as its important to know for it infers a date-era of your PC.

Thanks very much Clarity - that sounds like a good approach

It was originally Win7 when we bought it (a Clevo W170HN, i7 CPU, 8GB RAM, Nvidia Optimus 540M GPU)

No hurry as off to bed now but looking forwards to trying tomorrow.

[wiak]

The problem I have with your reports, Alex, is that they are too varied and too complicated.

Booting via Ventoy is by design a simple process and arrangement. If you add more and more partitions and mix up LABELS and don't stick to one simple recipe known to work then it becomes effectively impossible for us to work out what is going on.

Clarity has various working examples of what he does. At this stage I would not however try to arrange save persistence to occur on any disk except the boot from Ventoy usb. At least then we know what you are attempting and will then more likely understand any error messages. Let's hope the errors are not in fact hardware failure errors, since nothing we could do to remedy that of course.

Attached are screenshots showing how my Ventoy usb stick is arranged. I've only ever bothered making one such Ventoy usb and it works every time for me with all KL distro.

NOTE WELL: Currently, on my system the usb stick partition labelled "Ventoy" is appearing at /dev/sda1 and is formatted ext4 (would be sdb on most computers but my hard disk is nvme type so sda becomes the first usb stick).
i.e. on your system, sdb will probably be the first usb stick (and sda maybe the internal hard drive, which we aren't bothered with here).
And, on my system, the usb partition labelled "VTOYEFI" is appearing at /dev/sda2 and is formatted FAT32. VTOYEFI just contains the boot files so you can generally ignore it.

On the "Ventoy" labelled usb stick partition I created a folder exactly called "BOOTISOS" (all uppercase). I did not bother creating the directory shown that is named "Sessions" (first letter capital) because the KL distro will create that automatically if booting with menu choice that provides save persistence back to that "Ventoy" labelled partition. No need in that arrangement to label any partition as "Persistence" - don't do that - it would simply confuse trying to get Ventoy working for you. Only thing you do need is to make sure your Ventoy disk has the LABEL "Ventoy" (first letter capital). You can manually create a Sessions directory as shown, but as I just said that is not necessary either - that will be done automatically by KL on booting.

The fact is, there is nothing you need to do except adopt that arrangement. Your only job is to:
1. Make sure to use LABEL "Ventoy" on that partition.
2. Make a directory called "BOOTISOS" on that same ext4 formatted partition.
3. Put your KLV-Airedale iso into that BOOTISOS directory.
4. Boot the resulting Ventoy usb stick and choose menu option:

menuentry "KLV-Airedale-rcX (Ventoy} RAM2 save on demand to Ventoy_Sessions)

(i.e. 4th choice down in the KLV boot menu)

or alternatively the 3rd menu choice down (direct writes back to save persistence) should also simply work...:
menuentry "KLV-Airedale-rcX (Ventoy direct saves to Ventoy_Sessions)

============================================================

If that doesn't boot, then there are only four possibilities:

1. You have not arranged the Ventoy usb stick with the correct labels and so on as described above.
2. There is something wrong with your hardware so no changing arrangements will help you anyway.
3. Rockedge has somehow messed up the grub configuration in making the iso you are using (however if same iso release version has been tested using Ventoy by others no such accident is the reason for any boot failure).
4. Your system needs special firmware to access the boot media, but this is very unlikely since we are simply talking about booting from a usb stick (unless your computer was so old it could not boot from usb).

I suggest you do not try any other fancy partitioning scheme, which just confuses everybody such that we cannot help. Stick to the above and get that working fine. If it doesn't work, then no other arrangement should work anyway.

Only once, and if, you get the above exact Ventoy arrangement working then I will write a short howto frugal install KLV-Airedale (assuming you already have a working grub2). For now JUST concentrate on Ventoy.