-
Posts
224 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Linguafoeda
-
-
2 minutes ago, 3dee said:
Go into Settings - VM Manager and enable advanced view. You should find Libvirt wake on lan. Other than on / off there are no settings. When running, VMs will wake up on magic packet.
perfect - thank you!
-
is there a settings menu / how do i use this software?
-
On 1/16/2022 at 7:09 PM, tjb_altf4 said:
If you want WOL functionally for the VM, you need to install:
- Wake On Lan support plugin (prereq for #3)
- NerdPack plugin - to select and install Python 2 (prereq for #3)
- Virtual Machine Wake On Lan plugin
VM sleep works out of the box (once user agent is installed), I've not had any issues using it... well other than the same flakiness windows exhibits in bare metal when waking sometimes.
Not tried hibernate, but I know there was a setting in the VM Manager to change the default shutdown action, if that helps.
I would have expected hibernate to work if fully enabled in the OS itself.
@tjb_altf4 I installed "python-2.7.11-x86_64-2.txz" as well as both WoL / VM WoL plugins. Do i need to do anything else?
-
On 3/31/2022 at 6:42 PM, Linguafoeda said:
Ah I see - thank you. So:
1. make sure array is stopped. eject old 4TB drive in slot #5
2. place new 8TB drive in slot #5
3. run new config process, shrink array / remove "slot #5" disk from all shares, then when new config process is done, add new 8TB drive into that same slot
4. start array?
5. use rclone / rsync / krusader to copy files to the 8TB drive in slot #5 using the old 4TB drive connected via USB?
How do you copy files from one disk to another without starting an array? Usually I just use krusader and copy everything from usb device -> /mnt/disk5/, but that would conflict with starting the array which would cause a ton of issues with all my dockers / torrents that are looking for files in an empty drive before copying?
bump
-
On 3/27/2022 at 5:25 PM, itimpi said:
A much easier approach would be to start with the New Config to get the 8TB into the array and then format that. Having done that you can connect the old 4TB disk using USB and copy its contents onto the 8TB drive you just added to the array.
Ah I see - thank you. So:
1. make sure array is stopped. eject old 4TB drive in slot #5
2. place new 8TB drive in slot #5
3. run new config process, shrink array / remove "slot #5" disk from all shares, then when new config process is done, add new 8TB drive into that same slot
4. start array?
5. use rclone / rsync / krusader to copy files to the 8TB drive in slot #5 using the old 4TB drive connected via USB?
How do you copy files from one disk to another without starting an array? Usually I just use krusader and copy everything from usb device -> /mnt/disk5/, but that would conflict with starting the array which would cause a ton of issues with all my dockers / torrents that are looking for files in an empty drive before copying?
-
-
9 hours ago, ghost82 said:
No, it has nothing to do with trim.
Try to boot into recovery, keep '0' pressed on vm boot (if you don't see the bootloader gui - opencanopy) and choose 'recovery'; once booted into recovery choose disk utility; select 'show all disks/devices', select each container and run repair, such as in the following picture:
Sorry last thing - I am trying to fix this separate issue of mac hanging on shutdown ocassionally. I can't seem to figure out how to access the recovery boot partition. I have tried pressing the 0 button held down, spammed it (both tried via the VNC window pre-opened and starting up the VM from fresh as well as restarting inside).
Do you have any idea how i can access the recovery partition if those don't work? I seem to remember tweaking something in openconfig to "disable picker", not sure if that disabled me accessing the recovery partition.
-
amazing - I edited the XML (type='qcow2' + source fil=/.../macOS_disk.qcow2) and that worked!!! Thank you so so much
-
thank you - do i need to change the resulting file back to .img after? my Windows vdisk is "Windows_disk.img" but believe it's still qcow2
-
Hmm interesting. Well the command I was basing my assumption on it actually taking up 100GiB was how 1. Krusader (docker app), 2. mc (blue terminal window above) and 3. Unraid GUI were reporting used space.
Is there any risk to converting to qcow over raw? If there's no downside and only benefit i.e. fixing cosmetic issue at the least, I'd like to do that if possible if you could point me in the right direction
-
Here's my Mac and Windows disk side by side (I just ran CleanMyMac to further clean up the mac partition down to 26.5GiB). The reason I think it's actually taking up the 100GiB space is that everywhere that my cache drive (NVMe SSD) reports used vs. free space, it is assuming the full 100GiB from the mac vdisk. For example, my usr/mnt/cache only has 5 folders, appdata is ~68GiB, system is 1GiB,, ISOs is 0GiB, Personal is ~0GiB, and that leaves my domains folder which has just two folders & files (Windows_disk.img is 36GiB + macOS_disk.img 100GiB). 68 + 1 + 0 + 0 + 36 + 100 = ~205GiB which is what Krusader and Unraid main tab show as "space used".
root@:~# qemu-img info /mnt/user/domains/macOS/macOS_disk.img image: /mnt/user/domains/macOS/macOS_disk.img file format: raw virtual size: 100 GiB (107374182400 bytes) disk size: 26.5 GiB root@:~# qemu-img info /mnt/user/domains/Windows/Windows_disk.img image: /mnt/user/domains/Windows/Windows_disk.img file format: qcow2 virtual size: 100 GiB (107374182400 bytes) disk size: 36 GiB cluster_size: 65536 Format specific information: compat: 1.1 compression type: zlib lazy refcounts: false refcount bits: 16 corrupt: false
root@:/mnt/user/domains# cd /mnt/user/domains root@:/mnt/user/domains# ls -la total 0 drwxrwxrwx 1 nobody users 24 Mar 23 00:10 ./ drwxrwxrwx 1 nobody users 20 Mar 27 04:30 ../ drwxrwxrwx 1 nobody users 32 Mar 23 00:10 Windows/ drwxrwxrwx 1 nobody users 28 Mar 22 23:05 macOS/ root@:/mnt/user/domains# cd macOS root@:/mnt/user/domains/macOS# ls -la total 27793620 drwxrwxrwx 1 nobody users 28 Mar 22 23:05 ./ drwxrwxrwx 1 nobody users 24 Mar 23 00:10 ../ -rw-rw-rw- 1 nobody users 107374182400 Mar 27 07:06 macOS_disk.img -
Hmm okay. Do you know if there is a way to convert my disk to get this option back? Or otherwise get the ability to have a dynamically sized vdisk?
-
This is my results from the above steps but the space taken up on the SSD itself is still 100GiB. Does the disk size being ~30GB vs. 100GB virtual size (which is fixed) never get reflected in usable space to the actual SSD (maybe I misunderstood this part, I thought that what we were actually solving similar to how my Windows vdisk only shows up as ~36GiB used)?
Step 1: Initial Setup root@:~# qemu-img info /mnt/user/domains/macOS/macOS_disk.img image: /mnt/user/domains/macOS/macOS_disk.img file format: raw virtual size: 100 GiB (107374182400 bytes) disk size: 32.3 GiB Step 2: Copied 3.4GiB movie file root@:~# qemu-img info /mnt/user/domains/macOS/macOS_disk.img image: /mnt/user/domains/macOS/macOS_disk.img file format: raw virtual size: 100 GiB (107374182400 bytes) disk size: 35.8 GiB Step 3: delete 3.4GiB movie file root@:~# qemu-img info /mnt/user/domains/macOS/macOS_disk.img image: /mnt/user/domains/macOS/macOS_disk.img file format: raw virtual size: 100 GiB (107374182400 bytes) disk size: 32.2 GiB
-
I see this screen on my VM when attempting to shut down - it's maxing out the CPU. Is this related to trying to run the trim command?
Here is the terminal log file for the spaceman command https://gist.github.com/jeff15110168/4949afeb29f4d773b6c2874e0ca60547
-
great, sata0-0-2 worked! i enabled the XML edit, enabled trim and below is what system report shows. My macOS vdisk.img is still being reported as 100GiB in the domains folder though
I ran command log show --start $(date +%F) | grep -i spaceman_trim_free_blocks and nothing showed up. Essentially - I think TRIM is enabled but not running at boot?
my XML now:
<devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/> <source file='/mnt/user/domains/macOS/macOS_disk.img' index='1'/> <backingStore/> <target dev='hdc' bus='sata'/> <boot order='1'/> <alias name='sata0-0-2'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> ... <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='device.sata0-0-2.rotation_rate=1'/> <qemu:arg value='-usb'/> <qemu:arg value='-device'/> <qemu:arg value='usb-kbd,bus=usb-bus.0'/> <qemu:arg value='-device'/> <qemu:arg value='************************'/> <qemu:arg value='-smbios'/> <qemu:arg value='type=2'/> <qemu:arg value='-cpu'/> <qemu:arg value='Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check'/> </qemu:commandline> </domain>
-
Had a question on how to easily upgrade a drive to larger capacity for a system with no more bays / slots and one not running parity (don't have enough bays for parity, plus I have everything 1:1 backed up to cloud so just not running for now but may plan to in the future).
Say I have 5 slot machine with 4x8TB and 1x4TB, running without parity. I want to upgrade the 4TB drive in Slot #5 to a new 8TB drive, what steps do I need to do to copy over all the files on that existing 4TB and replace the same physical slot #5 with the new 8TB drive so that nothing share/docker/torrent seeding wise breaks?
This was my initial plan but let me know if I'm missing anything:
1. connect the new 8TB drive via USB, format to XFS (i.e. make it compatible so it's plug and play with when it goes directly into array in step 4.), copy all the files from the 4TB disk currently in array using Krusader or rsync
2. Stop array, wipe / format the 4TB drive in Slot #5
3. run new config process to shrink array, make sure 4TB disk isn't in any old shares (note down which ones it is in)
4. Add new 8TB drive physically into same slot #5 that 4TB was in, add it to array, add 8TB drive back into relevant shares noted in step 45. start array
-
I have just 1 vdisk setup using the macinabox SpaceInvaderOne guide. How do i get the alias of the disk? "<qemu:arg value='device.sata0-0-0.rotation_rate=1'/>" doesn't work for me since I don't have "alias name" function anywhere in my XML. I've tried "sata0-0-3", "sata0-0-0", "drive", "disk" and none seem to work
<devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/> <source file='/mnt/user/domains/macOS/macOS_disk.img'/> <target dev='hdc' bus='sata'/> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/>
-
10 hours ago, ghost82 said:
You have no video acceleration, so this is expected and not limited to monterey.
---
If you run:
qemu-img info /path/to/vdisk.imgin a unraid terminal and in the output you see "virtual size" = "disk size", it means that the vdisk didn't shrink when you deleted files in the vm and when free space on vdisk increases (when you delete some files in the vm) it doesn't sync with the free disk space on the host; this means that one day in the future the host will see the real disk full.
You can sync the free space between the vm and host in different ways, the fastest and preferred is to use trim inside the vm and setup the vdisk as non rotational.
Note that if you use virtio controller to attach the vdisk this will probably not work (at least it didn't work last time I tried, now I'm passing through the sata controller directly); it works with emulated sata controller.
a. For unraid < 6.10RC2 (6.10RC2 excluded):
a1. check your vdisk settings in the xml, for example:
<disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/path/to/vdisk.img'/> <backingStore/> <target dev='hdd' bus='sata'/> <alias name='sata0-0-3'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> </disk>
and change the second line to:
<disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/> <source file='/path/to/vdisk.img'/> <backingStore/> <target dev='hdd' bus='sata'/> <alias name='sata0-0-3'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> </disk>
add this after <qemu:commandline>
<qemu:arg value='-set'/> <qemu:arg value='device.sata0-0-3.rotation_rate=1'/>
sata0-0-3 being the alias of the disk.
b. For unraid >=6.10RC2 (6.10RC2 included):
b1. check your vdisk settings in the xml, for example:
<disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/path/to/vdisk.img'/> <backingStore/> <target dev='hdd' bus='sata'/> <alias name='sata0-0-3'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> </disk>
and change to:
<disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/> <source file='/path/to/vdisk.img'/> <backingStore/> <target dev='hdd' bus='sata' rotation_rate='1'/> <alias name='sata0-0-3'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> </disk>
c. in the mac os vm enable trim: run a terminal, type:
sudo trimforce enableand follow instructions.
Mac os will reboot, the vm will see the vdisk as an ssd, trim will be enabled and free space will be synched.
---
That is not opencore, but opencore configurator.
About the update of opencore I wrote something here:
https://github.com/SpaceinvaderOne/Macinabox/pull/47#issuecomment-869157952
1. Is there a way to passthrough the integrated GPU from my 10th gen i7 CPU? I don't have a slot available to plugin a GPU but would love to get rendering working properly if there are any workarounds
2. How do i find the alias-name of the disk? I tried "sata0-0-3" but I don't have "alias name=" in my own XML. I assume by a/b/c you meant you need to make the XML changes as well as run the "sudo trimforce enable" function in macOS terminal. When i check "About this Mac" -> "Storage", it shows "70GB free of 107GB" so it looks like my macOS VM should be around ~30-40GB. when I ran that above command i get much different results:
qemu-img info /mnt/user/domains/macOS/macOS_disk.img image: /mnt/user/domains/macOS/macOS_disk.img file format: raw virtual size: 100 GiB (107374182400 bytes) disk size: 89.3 GiB3. will try that and report back. thank you so much!
-
On 8/24/2021 at 1:17 PM, Linguafoeda said:
I’ve noticed that docker folders on the dashboard has a GUI issue where the icons start mis-aligned when you load the dashboard page on any zoomed out / smaller resolution screen (for example, below is my iPad). Happens on iPhone safari mobile as well. Is there something internally to fix this? Would love to make it look consistent with desktop since I typically am accessing unraid from my iPad when away from my desk.
On 8/24/2021 at 6:20 PM, GuildDarts said:Dang i had fixed that but guess i forgot to include the fix *facepalm
currently not able to push a fix as im not at a pc, will be in a few days
Just tired this on an ipad and see the same thing. Will fix it when i get to a pc
On 11/26/2021 at 10:13 PM, wallas9512 said:My docker overview is a bit upside down, did I missed something.
I think the code for list docker in docker interface is reutilized in overview.
Do you have any solution for correct this himself?
Thanks.
are you accessing from an ipad or iOS device? this is exact same issue i have with messed up GUI. would love if the developer @GuildDarts is able to find a solution for this
Bump
-
20 hours ago, ghost82 said:
Opencore supports monterey fully, I'm running it with the latest monterey 12.3.
That is THE question...
You can look for commits at the official github acidanthera page:
https://github.com/acidanthera/OpenCorePkg/commits/master
and look for descriptions pointing to fixes for newer oses.
If it doesn't boot you could enable logging to file in bootloader and see where/why it doesn't boot.
Note that I have to say that for our qemu vms it's quite difficult that a "not so old" opencore will totally break the vm, unless you mess it with custom configurations or wrong settings.
In most cases, if it boots big sur it will boot monterey.
If the bootloader isn't able to boot a newer os because something in the os has changed and a fix is made to the bootloader to make it boot, you need to update the bootloader, you can compile it yourself, or you can wait for someone else to compile it and download the compiled files, or you can wait for someone else to compile it, to make a new vdisk with the newer files and download that vdisk and replace/boot with the new opencore.
Abilities to do this range from low/medium to high, again if you are not expert, just take precautions (backups) and then ask for help if something goes wrong.
I tried to update to Monterey internally and i got this screen that won't budge. Not sure what may be missing / error.EDIT - I force quit the VM, restarted it and it went about successfully updating to Monterey!Had a few follow ups:
1. I’m seeing major issues with Chrome running properly. Essentially it doesn’t render similar to issue describe in this thread on reddit. Anyone else have similar rendering issues on Monterey? I don’t have an external GPU plugged in if that matters.
2. Is there a way to reduce the size of the macOS vdisk to actual usage vs. its pre-allocated to 100GB? I noticed my Windows VM is dynamic size (i.e. i set it up as 100G with VirtIO vdisk bus, and it currently takes up 36G as vdisk1.img in Domains) while macOS vdisk is always a flat 100GB. Would make backing up much smaller if it can be dynamic but not sure how to set that up with my existing macOS vdisk
3. just generally, how would i go about updating my opencore to the latest version? I think I installed macinabox Big Sur with opencore 2.19.1.0 as I had issues trying to install with 2.50. Below is the current version I have
-
11 minutes ago, ghost82 said:
Simple answer is that you can update mac os from within mac os, and this will be successful if the bootloader is compatible with the new mac os version.
Sounds weird, but it is what it is...
So, if you don't know what you are doing, I would backup the vm you are going to update, mac os vdisk, bootloader vdisk (if any), vm xml, and then try the update.
Then you will have 2 cases:
1. it boots without issues --> you are happy
2. it doesn't boot --> you are not happy:
3a. --> you restore the backup --> it boots --> you are not so happy because it didn't update, but at least it boots
3b. --> you fix it yourself or ask for help to make it to boot
Thank you, that is very helpful. I'll bsckup the XML + vdisk as an initial step.Which bootloader supports Monterey / how do you know you have the right one installed before going down the upgrade path
-
On 7/24/2020 at 8:37 AM, bastl said:
@luca2 You can use a modified 7zip version for example. Either you install that modified version or like I did, only use the desired zstd codec in the already installed mainline 7zip version.
https://github.com/mcmilk/7-Zip-zstd#zstandard-codec-plugin-for-mainline-7-zip
You should be also able to decompress the file using tar
https://stackoverflow.com/questions/45355277/how-can-i-decompress-an-archive-file-having-tar-zst
Sorry am a total noob, but I tried installing the "zstd-x64.dll" codec on my Windows PC, but when I try to unzip using 7-zip (right click on the file -> 7-zip context menu -> extract here) it gives me error "can not open file as archive". I also tried to unpack this .zst file in Krusader where it says "unsupported archive type". Any advice?
EDIT: nevermind, I installed modern7z and it worked like a charm. I would recommend the owner of this plugin link it somewhere in the OP or within the info-bubble that shows up when toggling the zstandard compression option (I am using level 7 based on the benchmarking done in this thread here.
-
On 1/8/2022 at 9:27 AM, ghost82 said:
I hope you didn't copy the efi files from the opencore qcow2/img to the main mac os disk.
If you didn't copy it's a lot easier.
Try this:
Download the latest opencore img:
Extract from the zip.
Look at the xml, copy the extracted file in the same folder where you have the actual opencore qcow2/img (don't delete it, so it will be easier to swap it again if it doesn't boot for whatever reason).
Modify your xml to point to the new opencore.img
Note: check the disk section and make sure to have type='raw' (if your old opencore image was qcow2 you have type='qcow2' and this must be changed).
Try to boot the vm.
If it boots, upgrade in place, you won't have issues in booting monterey.
If it doesn't boot, do what you did to install mojave, but obviously make a monterey installer disk in your mojave vm and use the new opencore image, and make a clean install.
On 1/8/2022 at 10:28 AM, ghost82 said:Correct!
The critical part of a mac os vm is the bootloader (opencore).
If you change something in the bootloader and the vm doesn't boot, it's easier to replace the whole opencore image with a backup (that worked), otherwise you need to mount the fat32 partition inside the mac os disk (the efi partition, that contains opencore), feasible if you know how to do it, but not recommended for users approaching a mac os vm or linux in general.
Hello - I have Big Sur installed and working correctly right now. I am trying to find information of how to upgrade to Monterey and I cannot find a clear answer. A few people tell me "just go ahead and upgrade inside the OS" and then I found posts like yours that seem quite complex and I get confused.
Can someone please pin a guide or explain exactly how one is supposed to update to Monterey if you installed Big Sur via macinabox like the original guide had?
-
are you confident? haha don't want to screw up my install. Alternatively - what is the best way to backup my entire installation so that if it does mess up, i can just revert back to how it was pre upgrading within macOS
Bump - what do I need to backup so that if the update to Monterey within the OS fails, I can restore to my last stable version?
[Support] Linuxserver.io - Sonarr
in Docker Containers
Posted
Just restored from database and also edited all my docker apps to directly source the appdata folder from the cache drive instead of the unRAID share. I heard that was better way to eliminate overhead that is created for apps that are openly writing to data base constantly. Haven't had any issues since