PeteAsking

So how do we add the packages we had in nerd pack? Sent from my iPhone using Tapatalk Pro

Upgraded to 7.2.94 skipping .92 and there are no issues on the .94 version I can see, few issues on the forum. Kind regards Peter

Hi Also noticed this. The fix is to purchase a faster CPU that is of a newer generation to mitigate the newer security requirements performance impacts. Its like running a nested VM inside the VM for CPU processes which is quite taxing, even if security is improved. Kind regards Pete

After reading the bugs on the forum I am skipping 7.2.92 and will check again for the version after this one.

Just saw there was a new version of the controller that might affect docker users so if you update to 7.2.92 take a backup first and check its working. I dont plan to do this myself until the weekend.

Same just changed my tag now to 7.1.68 and also no issues. Seems like unifi is clear sailing these days... I did notice there is now a firmware update for my pros but havent done that yet. However it seems like all the releases of late have been super safe and havent heard of anyone complaining. When I think back to the old version, and now to this new version that we all had to progress to, I do struggle to think of any real benefit. The old system seemed to work fine and have the same sort of options. The only clear benefit is the later versions support their newer AP's. Unsure why we had to all move to the new version though to be honest. I dont think anyone had a problem with how the old versions looked or worked. I guess what I am asking is, did we actually win or gain anything here or what was the reason Unifi wanted to redesign everything? For us or them?

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).