PeteAsking

I believe it would only be possible if the switch you use can set a pvid for traffic that has no tag as otherwise there will be no way to recreate port 1s setup afaik. Sent from my iPhone using Tapatalk Pro

I see your question on both forum posts, and I think you are under the impression that you can add encryption to anything using an ssl cert. This is not the case. It is impossible to simply add encryption to a stream on one side of the connection and have it work. When a client makes a connection it is expecting a certain type of response. If you alter that response to be an encrypted reply, then the client receiving this encrypted reply has no idea what to do with it. To resolve the issue you must patch both sides of the communication, so make a change to the server side to enable encryption and then on the client side make a change to allow for this new method of communication. In web browsers this change was done in 1994 by netscape, they created a client side browser that could communicate in HTTPS and a server side implementation was developed in 1995 for testing and never released until 1996 where they had improved upon the design (the dates might be a little fuzzy but something like that). Once both server and client side coding was done then https was functional between client and server. To achieve the same thing you would have to do the exact same thing - encrypt the server side communication and then rewrite the client to be able to communicate in this new way/add support for the encryption method you chose. As the client app is released by a company (Microsoft essentially) they would have to add this into the client for you (you dont have access to the source code presumably). Another alternative is to separate the server and encryption from the app and run it as a separate layer on top so have a server that encrypts anything it sees (with no understanding of what its looking at) and the client decrypts this and then passes that stream onto the app (with no understanding of the data). This is how a VPN like wireguard works, however it adds an additional layer of complexity and incompatibility. For example it would be inconvenient to have to establish a VPN to every server you wanted to connect to via HTTP if https had never been developed. Similarly it would be less convenient for people to connect to your MC server if they must first setup a VPN in order to do so.

Where did you see in the documentation for minecraft bedrock server that it supports ssl encryption via a certificate?

Mine is still working fine and I updated to the latest unraid.

https://github.com/virtio-win/virtio-win-pkg-scripts/blob/master/README.md Sent from my iPhone using Tapatalk Pro

Reinstall the nic drivers from the new virtio red hat iso file. You can download if off their site. Probably the driver you are using is too old. Sent from my iPhone using Tapatalk Pro

Also people here are helpful so probably if you take it slow and let people ask the questions they need and not rush, then probably if the data is available somehow you will get it back. It sounds super scary but if you are calm this will provide the best chance of success and it sounds like there are certainly some things to try before giving up hope

I must admit I forget the exact option when doing a new config, it could be there is a checkbox to tell it not to format or perhaps its just clearing the new disks, this I am less sure about. Hopefully someone more experienced chimes in but I do think you shouldnt give up on your data just yet.

No worries I believe you should be ok so dont stress too much

Also when you choose new config I think It wont delete data on a disk so if a disk had data on it it will still be available also so probably you are not in such a bad state as you might believe.

I mean you should download a live cd like even ubuntu live cd and then its irrelevant if you boot off that what your OS on a different pc is.

As an aside, since each disk is independent in order to try get data back you can just plug a "failed disk" into another computer and see if any of the data is readable on it. That may help you in getting some data back.

PC is java so incorrect server version

I dont see how that is possible. Are you sure you chose the same type of bios eg: if you chose i440fx and seabios before, then creating a new vm with OVMF and Q35 will render it unbootable. You cant change those once set.

Dont manipulate the qcow image you will damage it if you dont understand what you are doing. Unraid has no issues opening a qcow image it is the default image type. Simply copy the qcow image to your unraid box and create a new vm with manual disk and browse to the disk location that you copied it to. Simple. Converting a qcow to img is not a statement that has any meaning. That is just the extension of the file. An .img can already be a qcow.

I understand you feel comfortable and have various methods that you have used to do this restore procedure and it seems simple. I am simply giving you my feeling as someone who is a non expert and I feel my experience is both valid and possibly even shared with other users who are also in the same non expert position I am in. However I will also leave it at that. If you are happy with how the update rollout is going and that there is no need to improve the situation then I am happy to leave it to you guys and just get the all clear when its safe to upgrade. Not being mean or anything I really am happy to chill out and just get told when to jog on and hit update. It doesnt phase me and I dont feel any need to be combative about any of it if thats what people like. Peace

If the system does not boot it is not as easy as unplugging a stick and plugging in the cloned stick, regardless of how easy it is claimed to be. Unplugging one thing and plugging in another thing is literally going to be the easiest conceivable option in a disaster situation where your entire network is down with no internet because the single device that homes everything is down. Just saying. That is why enterprise equipment has a flash and a backup flash for example and you can select which flash to boot up from when it starts up eg like netgear switches and whatever else has a duel boot type thing. I think even some home motherboards have like a duel boot bios thing. Same reasoning. Its just how other people solve a problem with 100% guarantee rollback since its a different chip being relied upon, or different flash boot. Or different cloned stick. I feel you have to go the extra mile to reassure people that rollback cant fail rather than just be like ‘yeah you read these instructions and its super easy to follow if something breaks’ as this has an element of user needing not to be an idiot like me to complete the task correctly. Its also a time element. Follow instructions = time. Unplug one thing and plug in another thing = 30 seconds. Very different scenario in a time sensitive window.

(Not sure if we can just be candid and post our thoughts but assuming its ok). been thinking that I am unsure if my worries are unfounded but perhaps if people avoid upgrading due to the process being considered a possible risk then it could be the case that not a lot of people actually try the RC versions of releases as a result. This might make limetechs job difficult when releasing a new version. Maybe we as the members in the unraid community should try to form a beta testing task force that would or possibly could assist limetech if it worked within constraints they provided. At the moment my impression (which could be incorrect) is that its more of a passive testing. As in, the RC release is posted to the forum and anyone can feel like trying it out and providing feedback. This passive testing might not be as effective as say a committed group of like 100 people who pledge to update and will email their logs, along with hardware info that is relevant, for limetech to review even if no real issues are detected at all. This provides many different real systems both with or without issues to compare and for them to look at. The other problem is many of us (like me) might not know what errors to really look for even of things appear to be working in the short term but a once over from limetech might uncover inconsistencies in logs we dont fully appreciate and provide a more active ‘search and identify’ type beta testing path. if something like that was desirable then im sure a bunch of us could get together and step up to commit to testing RC versions and giving any info and logs to limetech to review. Pretty sure as long as there was a semi reasonable way to revert in case of a non bootable or unusable system then a lot of people could pledge to commit to testing. Might be like a fun thing for a group of us to get together and do not sure what other people think Im just saying we all hang around the forums anyway. If everyone disagrees thats ok too I was just saying what came into my head. Im not telling anyone what to do.

After reading this forum post I am now too scared to update unraid. Very worrying if we are between no network or possible data loss after an update. The update procedure is already very much a risky process at times since cloning a usb stick means the original is blacklisted so reverting back is not easy (as the cloned stick is useless) and now we are heading into territory where specific hardware can cause catastrophic service impact on things as simple as a NIC. Obviously not trying to say anyone is to blame nor suggest I have a better solution to the problem but as a user of unraid I can see how this would cause reactions I am seeing on the forums. It is very much a product that encourages consolidating many services onto one dedicated box, so when that service is broken, it can be multiple different parts on the network affected, NAS, DHCP, DNS, Web services etc etc etc. I feel like not everyone is a forum user and this could be better communicated or something into the update procedure could be implemented like a "known issues tick this box to proceed the upgrade" type thing where when you update it says "some users may lose connectivity, click I agree here to accept this and continue the update and agree you have read what to do if this affects you (link to instructions here) or something. (Not claiming this is the best solution just saying what came into my head upon reading this).

Not sure if anyne needs to know this but monterey gave me some trouble and I had to edit the XML to change the processor type. My parts I edited before the disk section are: <domain type='kvm' id='24' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>Elendil Macinabox Monterey</name> <uuid>8a8e5ae8-9cce-49e5-b883-e447e7ad0fa4</uuid> <description>MacOS Monterey</description> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="Monterey.png" os="osx"/> </metadata> <memory unit='KiB'>25165824</memory> <currentMemory unit='KiB'>25165824</currentMemory> <vcpu placement='static'>4</vcpu> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-q35-4.2'>hvm</type> <loader readonly='yes' type='pflash'>/mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd</loader> <nvram>/mnt/user/system/custom_ovmf/Macinabox_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> </features> <cpu mode='custom' match='exact' check='full'> <model fallback='forbid'>IvyBridge</model> <feature policy='disable' name='pclmuldq'/> <feature policy='require' name='fma'/> <feature policy='disable' name='pcid'/> <feature policy='disable' name='tsc-deadline'/> <feature policy='disable' name='f16c'/> <feature policy='require' name='hypervisor'/> <feature policy='disable' name='fsgsbase'/> <feature policy='require' name='bmi1'/> <feature policy='require' name='avx2'/> <feature policy='disable' name='smep'/> <feature policy='require' name='bmi2'/> <feature policy='disable' name='erms'/> <feature policy='require' name='xsaveopt'/> <feature policy='disable' name='rdtscp'/> <feature policy='disable' name='fma4'/> <feature policy='require' name='invtsc'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> Parts of interest are the <vcpu> and the <cpu_mode> sections. The reason for the edits is I would just get stuck with the progress bar on boot mot moving at all athe the CPU just consuming 1 core on my unraid box and nothing would happen (just stuck on the apple logo with no progress bar movement essentially). Unsure if anyone else has this issue but that is how I fixed it. This is editing the XML from the VM's page. The thing that fixed it for me was: <cpu mode='custom' match='exact' check='full'> <model fallback='forbid'>IvyBridge</model> and also <vcpu placement='static'>4</vcpu> Both which are defined differently in the template. You can also try <model fallback='forbid'>SandyBridge</model> if you like. Edit: Another thing I forgot to say I did was add to the bootom of the xml a change to mem balloon and some qemu arguments: </video> <memballoon model="none"/> </devices> <qemu:commandline> <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> Also near the top I changed pc-q35-6.2 to: type arch="x86_64" machine="pc-q35-4.2">hvm</type> This also alleviated some crashes I had/ and or stuck on the black apple.

To convert a raw disk you just use the qemu-img command on a linux box eg: qemu-img convert -p -c -O qcow2 originaldisk.qcow2 newdisk.qcow2 Resulting newdisk.qcow2 is in qcow format. You can check with qemu-img info newdisk.qcow2

Very minor, its only change from 65 was: > Improve application stability when using mobile apps. You need to stop the docker container and make a copy of it somewhere so that you can roll back if need be. Then change your tag to unifi-controller:version-7.1.66 and pray it upgrades. It can take like 10 minutes.

Just upgraded to 7.1.66, as with the previous version there is pretty much no risk to upgrade if you are already on the 7 series.

7.1.65 has just minor bug changes so anyone on 7.1.61 should immediately just upgrade (take a copy of your docker obviously first)as there is an almost zero chance of anything going wrong.

All of the 7 series have had no issues whatsoever for me so any of the version 7 versions are totally fine. Only thing I am unsure of is upgrading from an old version if you need to go via certain revisions or if you can just go from say 6.2.26 straight to the latest one.