KLV-Airedale-rc8 with Void Linux Kernel 6.1.4_1

[rockedge]

KLV-Airedale-rc8
Kennel Linux Void Airedale Release Candidate 8 776 MiB download size ↓
KLV-Airedale-rc8
SHA1-MD5.txt

Complete system update/upgrade and outfitted with a Void Linux kernel 6.1.4_1

Additional tuning of the /boot directory boot stanza's. improving the reliabltilty of booting in QEMU, Ventoy and S2SG.

Improved and rebuilt initrd.qz including expanded support for SD cards.

Routine system update/upgrade. And wallpapers from @Sofiya are included, replacing some of the stock xfce4 backgrounds.

@wiak has done work improving the boot system menus and further improvement to the initrd.gz boot mechanisms :

The iso config file boot/grub/menu.lst is used to boot from cdrom using that internal to iso provided menu.lst (i.e. he currently uses grub4dos for that purpose).
The iso config file boot/grub/loopback.cfg is used (per usual) to provide the boot menu for SG2D
The iso config file boot/grub/grub.cfg is used by Ventoy (but included no Ventoy-compatible entries until my alterations below)

I have made some modifications to all of the above (though have left previous entries in place for later experimentation and possible modification or deletion).
In particular I have provided the ability when booting via SG2D or Ventoy of using the FR modes:

a. RAM0 for session changes in RAM only (i.e. no save persistence)
b. RAM2 save on demand mode back to upper_changes folder (or ucimg savefile) in same directory iso is stored (or in subdirectory if symlink manually made to iso).
c. RAM2 save on demand mode back to upper_changes folder in, Clarity suggested, partition with LABEL 'Persistence' and directory 'Sessions'
d. Direct save (not in RAM) back to upper_changes folder (or ucimg savefile) in same directory iso is stored (or in subdirectory if symlink manually made to iso).
e. Direct save (not in RAM) back to upper_changes folder in, Clarity suggested, partition with LABEL 'Persistence' and directory 'Sessions'

No editing of the presented SG2D or Ventoy boot menus will be required to achieve these most useful FR initrd modes. User just needs to put the KLV iso in BOOTISOS (or wherever it is put usually) and boot...

starting of the pulseaudio system for any user that is logged in has been fixed and improved. Thanks wiak, Sofiya and fredx181 for the exact steps.

Upgraded to a new version of @fredx181 's save2flash, and set LANG=en_US.UTF-8 in /etc/environment as default localization.

Thanks to @Sofiya for the poorercputemp and Display Control packages that also have been added to desktop.

• Grub4Dos is now included in the System menu. Making KLV-Airedale capable of setting up a boot-able device using GParted and Grub4Dos.

• CUPS starting as a service has been added and is working thanks to @rcrsn51 spotting missing components!

This is constructed from KLV-Airedale-beta27->rc1->rc2->rc3->rc4->rc4.1 and is equipped with a Void Linux kernel version 6.0.12_1 SMP PREEMPT_DYNAMIC constructed with @wiak 's scripts that will extract the Void Linux kernel for KLV. Also has had a system wide upgrade. Uses an initrd.gz based on the FirstRib skeleton initrd.gz constructed by the kernel/module creation script. Firmware SFS is from a woof-CE kernel-kit built huge 6.0.0-1 kernel.

KLV-Airedale-rc5 is just as at home on FAT32, NTFS prtitions as it is running from ext2/3/4 formatted partitions.

Also included is wiak's generate a set of boot stanzas script. fredx181's mksplash has a menu entry and the remaster script is installed.

With the addition of a xfce4 desktop tiling configuration. A tip from wiak for configuring Tiling windows done with the Super (Windows) key and an up, down, left, right, home, pgup, pgdown or end key.

gxmessage in the default rootfs.

save2flash has been expanded to handle persistence on FAT32 and NTFS partitions.
The mksplash GUI utility to create splash notification banners.

The latest initrd.gz brings vFat and NTFS formatted partition support to KLV, allowing persistence on NTFS/vFat systems as well as the usual /ext2/ext3/ext4/swap support.

• included htop, Grub4Dos, CUPS

• created a symlink /root/spot with the target /home/spot

• Auto login cleaned up.

• includes also the logout logic provided by fredx181 gives true mulit-user support.

• replaced loop.cfg to the most recent modifications.

• Debian kernel 6.0.0-3-KLV SMP PREEMPT DYNAMIC is used.

• added gtkhash

Plus the other important improvements contributed by the KLV team.

Added @fredx181's save2flash utility that can be used when KLV is started in RAM2 mode to perform session saves on demand for persistence.
This is similar to PUPMODE13 in Puppy Linux.

fredx181's swap partition enable script includes the latest revisions and also added are the packages

• mime-add-1.0_0.noarch.xbps

• edit-sfs-1.0_0.noarch.xbps

KLV-Airedale-beta25 is able to load squash SFS packages on the fly or during the boot sequence.
Squash files and ISO images can be opened from the file manager and the read the contents.

• can run with rootfs, 01fimware and 00module SFS files as uncompressed directories.

• Also able to load compressed and/or decompressed directories,
  once a 2 digit prefix is added to the file name.

• It is possible to mix using compressed squash files and uncompressed directories.

Also can be downloaded from https://rockedge.org/kernels in ISO->Kennel_Linux->Airedale

[wiak]

Booted rc8 in qemu thus far using RAM2 save on demand to Persistence/Sessions option (had a usb stick with partition labelled 'Persistence' plugged in to computer and attached in qemu via option -hda /dev/sda1; more often I use a formated and partitioned with LABEL 'Persistence' qcow2 image for that but just thought I'd use raw usb stick for a change). Booted into VM guest without issue, and once there made a new file and entered command:

Code: Select all

save2flash

And was there on reboot.

All working fine so far. Note, at same time I'm also using the Plan 9 (9p) filesharing between host and guest technique I described here:

https://forum.puppylinux.com/viewtopic. ... 844#p78844

EDIT: Have since copied the rc8 iso to my Ventoy/BOOTISOS usb-stick directory and booted from that. Ventoy booted rc8 fine, and also tested with RAM2 save-on-demand mode to Persistence/Sessions second usb stick I had plugged in. Working fine. NOTE: Ventoy must be tested with actual Ventoy usb-stick boot on computer, not via qemu, which would not work!!!

Haven't tested other modes, or SG2D, but hopefully fine too.

[Clarity]

Tested on bare-metal: Ventoy USB AND SG2D USB boot to desktop for both RAM0 (1st Menu Entry) and for RAM2 Persistence entry.

Each of the 4 efforts booted to the same desktop wallpaper during these bare-metal test.

Bare-Metal Tests
	SG2D	Ventoy
RAM0	Y	Y
RAM2	Y	Y
Same Wallpaper	Y	Y

[wiak]

Tested on bare-metal: Ventoy USB AND SG2D USB boot to desktop for both RAM0 (1st Menu Entry) and for RAM2 Persistence entry.

Each of the 4 efforts booted to the same desktop wallpaper during these bare-metal test.

That's good to hear.

I am happy to report CUPS printing to my HP DeskJet 2520P worked fine from KLV-Airedale rc8 tonight at a time when I was having trouble printing on Zorin OS lite for unknown reasons. Used @rcrsn51's very reliable and small hplip-print-scan-klv-3.19.8_2.x86_64.xbps package, which fortunately I had kept a copy of.

[wiak]

Now that everything seems to be working so well, and so many new ideas to test, I almost feel we now have to slow down a bit to give ourselves time to catch up with all the very interesting and useful facilities that are available for KLV. I certainly could spend weeks now working with Qemu alone and still not exhaust the possibilities and scope! It's easy to install or out-of-the-box bag of available tricks is making KLV the most useful distro on my computer right now - turning to it for printing reliability was a new one that took the cake of the month award for me!

[rockedge]

@wiak I agree that slowing down right now is in order. Time to let the system be stable and find out all the things that can be done with it. We can gather How-To's and collect the pieces of documentation and put together something to consolidate it at least in a searchable concentration of it.

Plus time to finish up the last bits and pieces so F96_4-radky6-CE can become F96_5-radky6-CE, get it's release name finalized then have it uploaded to the Puppy Linux distro repo. Also I am looking at KLA in a QEMU machine to add the KLV tools that are used to easily create simple or complex qemu virtual machines even from a RAM0 mode direct from ISO boot in a QEMU VM.

[wiak]

Tested on bare-metal: Ventoy USB AND SG2D USB boot to desktop for both RAM0 (1st Menu Entry) and for RAM2 Persistence entry.

Each of the 4 efforts booted to the same desktop wallpaper during these bare-metal test.

That's good to hear.

I am happy to report CUPS printing to my HP DeskJet 2520P worked fine from KLV-Airedale rc8 tonight at a time when I was having trouble printing on Zorin OS lite for unknown reasons. Used @rcrsn51's very reliable and small hplip-print-scan-klv-3.19.8_2.x86_64.xbps package, which fortunately I had kept a copy of.

Well, still happy with printing; better even since now I've set up the old HP deskjet 2540p to work via wireless. Printing via above CUPS and @rcrsn51's package fine, but... I installed simple-scan from Void package manager, but it is failing to detect any scanner... I know nothing about this unfortunately.
I forgot about his print scan apps; which I'll try again now. They worked when I was previously just using usb cable, and I felt they should be included in official KLV releases if possible.
EDIT: PeasyCUPS is finding the networked (wifi) HP printer, but PeasyScan isn't - nor is Simple-Scan (Document Scanner). Odd thing is, even when I connect via usb cable it is printing but not finding scanner, but when I first tested these packages it all worked.
EDIT2: Good news. Scanner is now working with PeasyScan after removing and re-installing rcrsn51's hplip-print-scan-klv package. I do wonder why I needed to re-install it - maybe something to do with installing simple-scan after initial hplip-print-scan-klv package? Simple-Scan still doesn't work - maybe some collision between the two (PeasyScan/simple-scan)?
EDIT3: Simple-scan now working. Yes, I didn't notice I still had an instance of PeasyScan running when I tried simple-scan before. Closed that and simple-scan also now working fine from wifi-connected AOI HP 2540P deskjet printer/scanner. This is great.

Really happy with KLV-Airedale operation now. I might even just boot into it when doing business work I normally use Zorin for; just need to install a few needed apps if I do that.

[Clarity]

This distro 'should' have SAMBA & utilities for it to be a true equivalent distro in the forum.

Maybe we could see such in RC9. If so, the QEMU document being produced would be the same for this distro and the F96 distro which has SAMBA along with the other WoofCE forum distros and DOGs.

Just a thought

[wiak]

Tested on bare-metal: Ventoy USB AND SG2D USB boot to desktop for both RAM0 (1st Menu Entry) and for RAM2 Persistence entry.

Each of the 4 efforts booted to the same desktop wallpaper during these bare-metal test.

Bare-Metal Tests
	SG2D	Ventoy
RAM0	Y	Y
RAM2	Y	Y
Same Wallpaper	Y	Y

For some reason Ventoy is now only booting in RAM0 mode, but RAM2 persistence not working either to iso location or to Persistence/Sesssions. I haven't modifed the iso and I was sure I tested it all worked before, or have I sent old grub.cfg file to rockedge (I don't think so). Are you sure Ventoy is booting KLV-Airedale-rc8.iso with RAM1 persistence mode working, Clarity? Currently I feel like I am going made because I was certain it worked for me before, but isn't now...

[rockedge]

@wiak weird is also option direct save to Persistence/Session is not working. I just tried that option. The direct save to /mnt/sda1 does work.
This is running in qemu.

I think the correct /boot/grub files are in place but a check is worth it.

[wiak]

@wiak weird is also option direct save to Persistence/Session is not working. I just tried that option. The direct save to /mnt/sda1 does work.
This is running in qemu.

I think the correct /boot/grub files are in place but a check is worth it.

Looks like it needs revisited... I realise a major problem when testing all of Ventoy, SG2D and Qemu is that poor wee FirstRib initrd can end up with different conflicting information to Ventoy or SG2D and so on - meaning Ventory discovers an iso but if two isos happen to be somewhere on computer then it can be a different one than FR initrd then finds ... But I'm not sure now what is going on. I certainly tested modes and all worked - but maybe I had different devices plugged in. Problem is I have to search for all isos of same name and try to just test with one such.

Qemu shouldn't be such a problem because generally speaking it is more likely 'maybe' that you use Persistence/Sessions on a qcow2 image rather than use an external hda device (though that is possible too of course...). For now I'm trying to simplify my set up, but scratching my head with bewilderment anyway. Thought I had the grub configs good, but maybe not afterall; hopefully will suss it all out better for next time...

I'm also redownloading rc8 to make sure I'm using released iso since I also made temporary rc8 iso of my own during testing. I just hope I haven't forgotten something I did that happened to work because it is not easy getting this correct!

When it comes to the likes of Ventoy and SG2D, more than one same-named iso on system is a problem I think. Seems they find all of them or many of them and then who knows which one they are booting from? FR initrd has to make one choice in terms of which partition to mount. Alas, neither Ventory and certainly not SG2D pass back even which partition the iso (or iso?) is in, so FR initrd finds one, but that's the best it can do - there must only be one and the same one!!! Normal frugal installs is much better - safer - since we control subdir the install is in exactly - no problem with wrong one being used there. I think I see an error on loopback.cfg so SG2D shouldn't be working with persistence if I am correct, but I'm not sure of anything right now... Been doing too much computing so brain more than a bit frazzled.

[wiak]

@wiak weird is also option direct save to Persistence/Session is not working. I just tried that option. The direct save to /mnt/sda1 does work.
This is running in qemu.

I cannot confirm this. The opposite in fact. Qemu, which is the important one for me in addition to normal frugal installation, worked perfectly in all the tests I just performed.

I tried every menu choice, with success every time.

Two different scenarios tested:

1. with "-hda example.qcow2" image partitioned to one partition with label "Persistence". Ran that one with command:

Code: Select all

qemu-system-x86_64 -enable-kvm -m 2G -vga cirrus -smp 2 -device AC97 -cdrom KLV-Airedale-rc8.iso -hda1 example.qcow2 -boot once=d

Having exhausted all the first six LABEL-related boot methods, I tried /dev/sr0 that included w_copy2ram for direct saves to Persistence, and that worked too.

2. Then I tried an actual usb stick formatted and with its partition 2 given label "Persistence". Ran with command using -hda /dev/sda such that actual /mnt/sda2/Sessions/KLV-Airedale-rc8/upper_changes will be used for persistence:

Code: Select all

qemu-system-x86_64 -enable-kvm -m 2G -vga cirrus -smp 2 -device AC97 -cdrom KLV-Airedale-rc8.iso -hda /dev/sda -boot d

Following your comment, for this one I just tested menu choice:

KLV-Airedale-rc8 (LABEL, direct saves to Persistence/Sessions)

Worked perfecly.

My own tests convince me that not only is FR initrd doing everything it should but all menu.lst Qemu choices are working fine. Not sure why didn't work for you - check your configuration carefully. Post some exact details here please if you still can't get it working; I'm confident all is actually fine with Qemu side of things.

I've noticed what I think is a blunder on my part for SG2D loopback file (used BOOTISOS when should have been /BOOTISOS).

Biggest problem, is Ventoy - that grub.cfg just isn't working for me.

Summary, Qemu all modes working fine, SG2D I think is minor mistake so I can fix that, Ventoy grub.cfg I need to check out more carefully and find fix.

Not sure what Clarity was drinking when he released Ventoy and SG2D pass tests for all modes. Simply isn't working at all for me though I did think Ventoy worked before (?!!!!!), but maybe I became mixed up and didn't properly test (so many tests required for so many modes with all of Ventoy, SG2D and Qemu to work through...!). Accurate test results with exact code details of how the tests were run is essential to fix matters like this quickly.

Next I'll make what I believe is the fix for SG2D loopback.cfg (the least important boot system IMO), and then I'll see if I can get Ventoy working. Thank goodness Qemu passes with everything I threw at it since that is the one I want!

[rockedge]

The only time I am running into this problem is when the start up from within AQEMU. Not via command line start here there is no problems at all.

It happens when starting the system in the aqemu GUI from ISO as a CD-ROM. Then once the CD-ROM boots those options are the ones not working 100%.

The system will boot after a moment and typing in exit, but ends up in RAM0 mode. This seems like a special case where that option can't find the save partition because it's impossible in this circumstance. This does not worry me at all.

Otherwise KLV in QEMU works very well. I have been experimenting with file transfer between host and guest VM

[wiak]

The only time I am running into this problem is when the start up from within AQEMU. Not via command line start here there is no problems at all.

That's strange indeed, but if works by commandline then that means the menu.lst is fine - something odd about AQEMU there.

[wiak]

The grub boot situation is nothing like as bad as I was feeling. I thought I was going mad since had seemed to work for me in earlier pre-rc8-release tests.

Right now I am posting after booting using SG2D with save on demand RAM2 to partition Persistence having Sessions folder in it (a separate /mnt/sdb1 usb stick). The savefolder used is therefore: /mnt/sdb1/Sessions/KLV-Airedale-rc8/upper_changes. Clearly that works afterall.

Similarly, exactly the same arrangement worked a minute ago when I used Ventoy instead to same Persistence usb stick... This explains how Clarity also reported success; these modes do indeed work.

So what doesn't work? Well, the savefolder straight back to iso location on SG2D or Ventoy doesn't work whether direct write or save on demand write. The why not I haven't yet determined, but I am reasonably comfortable with the situation now since Persistence/Sessions method is fine and good enough; if I can't get savefolder straight onto Ventoy or SG2D device I'll just remove these entries since Persistence/Sessions method is best anyway and fine alternative. Qemu boot selections all work - from command line anyway; I don't care about Aqemu really since that is a configuration of Aqemu situation when you think about it and nothing to do with KLV menu.lst being correct or wrong - the menu.lst is proved to be correct.

One caveat regarding both Ventoy and SG2D though. These boot mechanisms are designed to find ALL isos on various places on the system and then present a menu of choices as to which to boot. Unfortunately since neither pass the 'chosen-one' onto FR initrd, poor old FR initrd has to find the iso itself simply based on path information (i.e. searches all partitions looking for that fullpathname for iso). FR initrd thus uses the first one it finds (impossible to do otherwise in practical sense), but issue is that could well end up being a different iso than the one chosen on SG2D or Ventoy iso. No practical way round that other than to not have more than one copy of iso on your system that might be chosen by Ventoy or SG2D - then it is luck if FR initrd chooses same one... i.e. be careful using Ventoy or SG2D - easy for things to get mixed up. Would all be fine if both passed partition info onwards to FR initrd, but, for some reason, they simply don't...

In summary, all of Ventoy, SG2D and FR initrd successfully find KLV iso location on computer, but the issue is do they all find and use the exact same one at the same time; the answer when there is more than one available is quite likely to be NO in which case boot naturally breaks. Answer to that issue is make sure only one on your system since FR initrd can't boot two at same time despite the likes of Ventoy saying there are more than one...!

I'm considering the Ventoy fail case more now to see if any grub.cfg fix possible since I don't know why that direct back to Ventoy iso location is failing. I suspect the answer to that may be why Clarity discovered Ventoy couldn't be run under Qemu with KLV, and still boot; rather it needs actual computer boot of Ventoy disk to work. At least the existing fail menu choice is not due to my use of grub variables, which is what I suspected at first since I had never tried that grub2 facility before. Final report and altered grub files soonish.

[rockedge]

I don't care about Aqemu really

AQEMU is just a convenience GUI that makes in the end command line strings. You don't need to remember the syntax to connect to a usb webcam on the host machine for example. In AQEMU it's quick and easy doing complex system start strings.

It is not that important and it's 2 or 3 selections which I don't use and they boot in the end anyway.

[Clarity]

Please do not take this the wrong way as I am not telling members what to do.

Yet, I continue to share that we still may be a year/several away, before USB sticks would be a good choice for anything other than as transports or as read-only of the ISO files as we use them via Ventoy/SG2D.

There are many reasons for this position and why I refuse to use them even for session saves. Too many times of unexplained failures in various USB sticks...excepting the costly SAMSUNG USBs.

The PC's drives connected to the PCs BUS (not USB) is the best use case I find where little to no troubles exist or have been experienced in my last decades of use. This includes the system's HDD/SSD/NVME this shows great performance without issues.

Not so using USBs in my experiences, thus far. Thus, I continue to suggesting not using USBs for saving distro sessions.

I do expect that as new USB4 controllers become mainstream and USB4 units show up at reasonable cost will a disappointing non-erratic behaviors, diminish the USB sticks issues into non-existence.

So, we should continue to advise users of 'safe' use cases. I know some members will disagree, even strongly; but my evidence cannot be refuted in my findings.

[Clarity]

AS I KNOW someone is going to really object, here's an example that recently happened.

On a 16GB RAM PC using an un-named PUP (as it could appear as disparaging), I started a ROX write to an USB2 stick on a USB-A port. The display shows the file write started and complete in a very short period of time; maybe 15-20 seconds. I started a 'timed' sync command in the terminal. 22 minutes 31 seconds later the system completed the write operation on the USB. I noticed too that the USB light stop flashing indicating transfer had completed.

This is a combination of OS, bare-metal system hardware and the actual USB cable and device all, while working in tandem with each other, may have some impact on this behavior.

And I know ALL USB sticks I have do not all exhibit this specific characteristic. But, I also know that copy of the same file to the system's HDD takes only a minute/so.

Just one of many bad experiences seen in USB sticks.

As such, the "ISO file containing" is one of the few USB stick functions I trust as this is almost a write-once phenom in our use as a ISO file boot unit. Hence, once initially created, we only drop ISO files onto it and read-forever from the USB unit.

[rockedge]

@wiak I think I have the folder sharing between host and VM guest working.

This set up shares a folder on the host system (F96_5-radky6-CE) = /root/Build2

Command line string to start the KLV QEMU machine:

Code: Select all

/usr/bin/qemu-system-x86_64  -smp 4 -soundhw ac97 -machine accel=kvm -m 4096 -cdrom "/mnt/home/KLV-Airedale-rc8.iso" -hda "/root/.aqemu/KLV_Airedale_rc8_HDA.img" -virtfs local,id=shared_folder_dev_0,path=/root/Build2,security_model=none,mount_tag=shared0 -boot once=d,menu=off -net nic -net user -usb -device usb-ehci,id=ehci -device usb-host,bus=ehci.0,hostbus=2,hostport=1.1 -rtc base=localtime -name "KLV-Airedale-rc8" $*

Then once KLV QEMU VM is started, in the KLV virtual machine open a terminal and use:

Code: Select all

# The 9p filesystem module must be available on the guest
modprobe 9p
mkdir /tmp/shared0
mount -t 9p -o trans=virtio shared0 /tmp/shared0 -o version=9p2000.L,posixacl,cache=mmap

This will make host = /root/Build2 connected to guest = /tmp/share0

Screenshot(2).jpg (55.91 KiB) Viewed 569 times

[wiak]

Not so using USBs in my experiences, thus far. Thus, I continue to suggesting not using USBs for saving distro sessions.

That's fine Clarity, and there is no need to use USB sticks for your perstistence saves in any of the supported KLV-Airedale mechanisms (Normal frugal install, Ventoy, SG2D, or Qemu); you can use hard drive partitions only or in Qemu you also can use hard drive image files if you so wish. Having said that, it is better to be as generic as possible (meaning flexible user choices here) so KLV-Airedale supports using any read/write media for persistence according to user choice.

[wiak]

@wiak I think I have the folder sharing between host and VM guest working.

Happy to hear Plan 9 (9p) file sharing is working for you. Inside the guest it becomes easier to have a simple 9p_guest.sh script, for doing the commands needed in the guest, like the one I shared here (which I keep in my /usr/local/bin for use on guest VM):

https://forum.puppylinux.com/viewtopic. ... 008#p79008

[Sofiya]

@wiak I think I have the folder sharing between host and VM guest working.

Then once KLV QEMU VM is started, in the KLV virtual machine open a terminal and use:

Code: Select all

# The 9p filesystem module must be available on the guest
modprobe 9p
mkdir /tmp/shared0
mount -t 9p -o trans=virtio shared0 /tmp/shared0 -o version=9p2000.L,posixacl,cache=mmap

This will make host = /root/Build2 connected to guest = /tmp/share0
Screenshot(2).jpg

I also start like this only with AQemu right away,
before that in the terminal I enter modprobe 9p I press start in Aqemu, the installed https://forum.puppylinux.com/viewtopic. ... 805#p78805
AQemu:
#!/bin/sh
# This script created by AQEMU
/bin/qemu-system-x86_64 -smp 2 -vga std -machine accel=kvm -m 4096 -virtfs local,id=shared_folder_dev_0,path=/root/Build2,security_model=none,mount_tag=shared0 -cdrom "/run/media/root/MULTISYSTEM/KLA_OT2.iso" -hda "/root/.aqemu/example.qcow2" -boot once=d,menu=off -net nic -net user -rtc base=localtime -name "KLA_OT2_x86_64" "$@"

on guest KLA in the terminal
modprobe 9p and

Code: Select all

# The 9p filesystem module must be available on the guest
mkdir /tmp/shared0
mount -t 9p -o trans=virtio shared0 /tmp/shared0 -o version=9p2000.L,posixacl,cache=mmap