Subj : Remmina RDP To : Mike Powell From : Barry Martin Date : Thu May 16 2024 07:40:00 Hi Mike! > As far as upgrading to the new version, I've also had problems. Seems > to be a lot smoother with the current versions but the older > versions..... Maybe around 20.04 they figured things out. I also could > have complicated things by trying to upgrade a computer near the bottome > of the minimum hardware requirements (like my computer which says will > take 8 GB but it won't boot if more thna 6 GB). MP> IIRC, the issue I last ran into -- I suspect -- had something to MP> do with how they have moved some "parts" of the OS and MP> accessories from the completely free version to one that maybe MP> involves paid support, or at least some level beyond what just MP> the FOSS version I was using. apt threw some messages I am not MP> used to seeing with other debian variants that lead me to believe MP> as much. MP> Whatever packages I had that they had since "decoupled" left the MP> system unstable. They were not familiar to me or I might have MP> realized what was going on sooner. I'll admit to kind of starting at the "I'm not familiar" step because I generally don't deal with the hardware and Operating System levels all that often -- no need to. I have noticed they do move things around: Swap File came to mind and the why magically disappeared. %) ...Well, in the Raspberry Pi OS the boot configuration file was move to the firmware subdirectory; if a piece of software doesn't update that during an upgrade I would image things can break -- sort of your 'decoupling'. MP> Previous times that was not the issue, and I would still wind up MP> with a system that was not at the same level of "useability" as MP> it was before the upgrade. I've sort of had that issue also but I can't always point to the upgrade process: some of the failure/instability could be attributed to me swapping/adding/other changing of the hardware, being unfamilar with UEFI, and the like. ...Had one brand new installation and the system was unstable: ended up the problem was faulty RAM (freshly unpacked). MP> IMHO, it probably has something to do with them mixing in things MP> from debian stable along with things from other branches MP> (testing, unstable) that screws it up. Or maybe it is just some MP> other ubuntu-specific modifications that they make. I'd guess a mix of all that! I'm sort of learned to test new stuff on a Virtual Machine because if don't like it or misconfigured easier to blast the VM -- the uninstall, purge, etc., processes don't always remove all traces. > Anyway, the problems seem to be resolved by installing using the nomodeset > option (the editing it out when things work properly). There's also an > option is some BIOSs/UEFI's which has to be turned off to install a > non-Windows OS. MP> I have run into some issues when installing debian/devuan while MP> being near the bottom of the minimum requirements. I usually go MP> with the non-graphical install option and that seems to get me MP> around the issues. I haven't learned to do that yet! > One little problem is MythTV requires the Frontend (viewing) and Backend > (recording) versions to match, so I have to have at least two computers > upgraded. The good news is now I should be able to use Raspberry Pi 4 > or 5 for the new Frontend, making the physical swap a lot easier. (The > old computers are big and have to fit the available space: a tower > format won't fit a desktop cubbyhole.) MP> Sounds complicated, but it also sounds like you have a good MP> process in place for making it work. ;) It is also good that MP> you can use a Pi. Not only do they require less space but they MP> should also draw less power. Yes, the 'rolling upgrade process' can be a litte detail-filled! ¯ ® ¯ BarryMartin3@MyMetronet.NET ® ¯ ® .... Powered by Miracle Software; our motto: "If it works, it's a Miracle!" --- MultiMail/Win32 v0.47 þ wcECHO 4.2 ÷ ILink: The Safe BBS þ Bettendorf, IA --- QScan/PCB v1.20a / 01-0462 * Origin: ILink: CFBBS | cfbbs.no-ip.com | 856-933-7096 (454:1/1) .