Hello there.
You can see from my signature what my current OS' are. The quest for Lappy's new OS from Mint 17.3 KDE4 is now resolved, but i've been intensively researching, & testing in many VMs, candidates for Tower. I yearn to retain a KDE DE on Tower, & have tried Mint 18, Kubuntu 16.04, KFedora 24, KDE Neon, & Maui. Of all those, for me, Maui is easily the best... i *really* like it. I won't drag out this post by extolling all its virtues in detail, but suffice to say, from my comparative VM testing Maui is unambiguously the neatest, most featured, & most stable Plasma 5 adoption. Big kudos to the Devs.
However there are two serious issues currently preventing me taking the next step & installing it directly onto Tower's SSD, to replace Mint 17.3:
[1] I have concerns over security. Pls would you sign your ISO & Checksum files with your private PGP key, & post your public key in a top keyserver, so i can then confidently validate the ISO before i install it “for real”. I know your ISO & Checksum are currently on https site, but would prefer better security via PGP... please?
[2] I always partition my drives with separate /, /opt/, /home & swap. I strongly prefer to encrypt /home during installation, via the installer. This always worked nicely on Tower & Lappy with Mints KDE & Xfce. However it seems to be broken for Maui. Over the past 24 hours i've played a lot with this, in two separate Maui VMs:
(a) One was a "pure" Maui installation into a "virgin" VM, without encrypting /home. After the initial reboot, & continuously since, this VM has behaved magnificently. This marvellous experience was precisely what inspired me to favour Maui as my Tower's likely next OS, having already finished testing all the others.
(b) (i) The second was a VM i deliberately cloned from an existing Mint 17.3 KDE4 VM, having lots of pgms already installed & configured [& LOTS of KDE personalisations done], & varying degrees of copies of my real data. This Mint VM had encrypted /home. Following my installation of Maui into it over Mint, by formatting /, putting bootloader in /sda1, reusing /opt & /home [thus retaining its encryption], post-reboot i got to the Maui boot screen, got to the proper log-in screen, but Every Single Time [more reboots than i can count] after that, instead of the Plasma desktop appearing, the screen stays black & completely unresponsive to mouse & keyboard.
(b) (ii) In case the root-cause might have been my KDE4 config files in the reused /home conflicting with new Maui Plasma5 files, i did a reinstallation of Maui but this time formatted both / & /home [ie, blowing away my data], albeit still encrypting /home via the installer. Post-reboot, everything bad that i described above, repeated.
(b) (iii) I've tried rebooting with the ISO back in the virtual drive, accessing the installation's /etc/default/grub file & editing it to replace quiet splash with nomodeset then rebooting, but it did not help.
(b) (iv) I've reinstalled Maui in this VM, this time without encryption, & post-reboot everything was good [like the other VM].
My testing might not be forensically complete, but it does seem to indicate that Maui cannot handle an encrypted /home partition. I hope the root-cause is actually something else, as for me an encrypted partition is not negotiable; if Maui truly can't handle it, then regrettably i'd have to walk away from it.
Ideas anyone, please? Clearly i cannot proceed til these issues are solved.
..........................................................................................
Tower's SSD OS = Linux Mint x64 17.3 KDE 4.14.2... for now...
Lappy's SSD OS = Linux Mint x64 18 Xfce+Compiz [> 18/9/16]
You can see from my signature what my current OS' are. The quest for Lappy's new OS from Mint 17.3 KDE4 is now resolved, but i've been intensively researching, & testing in many VMs, candidates for Tower. I yearn to retain a KDE DE on Tower, & have tried Mint 18, Kubuntu 16.04, KFedora 24, KDE Neon, & Maui. Of all those, for me, Maui is easily the best... i *really* like it. I won't drag out this post by extolling all its virtues in detail, but suffice to say, from my comparative VM testing Maui is unambiguously the neatest, most featured, & most stable Plasma 5 adoption. Big kudos to the Devs.
However there are two serious issues currently preventing me taking the next step & installing it directly onto Tower's SSD, to replace Mint 17.3:
[1] I have concerns over security. Pls would you sign your ISO & Checksum files with your private PGP key, & post your public key in a top keyserver, so i can then confidently validate the ISO before i install it “for real”. I know your ISO & Checksum are currently on https site, but would prefer better security via PGP... please?
[2] I always partition my drives with separate /, /opt/, /home & swap. I strongly prefer to encrypt /home during installation, via the installer. This always worked nicely on Tower & Lappy with Mints KDE & Xfce. However it seems to be broken for Maui. Over the past 24 hours i've played a lot with this, in two separate Maui VMs:
(a) One was a "pure" Maui installation into a "virgin" VM, without encrypting /home. After the initial reboot, & continuously since, this VM has behaved magnificently. This marvellous experience was precisely what inspired me to favour Maui as my Tower's likely next OS, having already finished testing all the others.
(b) (i) The second was a VM i deliberately cloned from an existing Mint 17.3 KDE4 VM, having lots of pgms already installed & configured [& LOTS of KDE personalisations done], & varying degrees of copies of my real data. This Mint VM had encrypted /home. Following my installation of Maui into it over Mint, by formatting /, putting bootloader in /sda1, reusing /opt & /home [thus retaining its encryption], post-reboot i got to the Maui boot screen, got to the proper log-in screen, but Every Single Time [more reboots than i can count] after that, instead of the Plasma desktop appearing, the screen stays black & completely unresponsive to mouse & keyboard.
(b) (ii) In case the root-cause might have been my KDE4 config files in the reused /home conflicting with new Maui Plasma5 files, i did a reinstallation of Maui but this time formatted both / & /home [ie, blowing away my data], albeit still encrypting /home via the installer. Post-reboot, everything bad that i described above, repeated.
(b) (iii) I've tried rebooting with the ISO back in the virtual drive, accessing the installation's /etc/default/grub file & editing it to replace quiet splash with nomodeset then rebooting, but it did not help.
(b) (iv) I've reinstalled Maui in this VM, this time without encryption, & post-reboot everything was good [like the other VM].
My testing might not be forensically complete, but it does seem to indicate that Maui cannot handle an encrypted /home partition. I hope the root-cause is actually something else, as for me an encrypted partition is not negotiable; if Maui truly can't handle it, then regrettably i'd have to walk away from it.
Ideas anyone, please? Clearly i cannot proceed til these issues are solved.
..........................................................................................
Tower's SSD OS = Linux Mint x64 17.3 KDE 4.14.2... for now...
Lappy's SSD OS = Linux Mint x64 18 Xfce+Compiz [> 18/9/16]
home was still encrypted [yes] & opt still contained my pgms from previously [yes], & these pgms still correctly launched when i used their respective opt executables. Once again the menu had no items for them, but that's easily fixed manually.
