The latest .iso I tested was build 821. It fixes the encryption bug. You are now allowed to encrypt your swap and root partitions.
However I found a new problem after the installation via build 821.
When I start the new installation the software update icon (Black-Up arrow) shows up very quickly in the tool-bar.
Clicking it, opens the update window indicating 51 packages are available for update. When the Update button is pressed, the application crashes and a sad looking square appears in the tool-bar.
Clicking it opens a window titled “Discover” with the bottom line telling:
Executable: plasma-discover PID:5437 Signal: Segmentation fault (11) Time: 2/18/17 20:12:07
Pressing the “Report Bug” button at the bottom opens the Crash Reporting Assistant.
After filling out some forms and pressing the Next button the application complains “The debugger application is missing or could not be launched.”
After installing gdb and pressing the Reload button the application tells me:
Results of the Analyzed Crash Details
This report does not contain enough information for the developers, so the automated bug reporting process is not enabled for this crash.
Did anybody also noticed this behaviour and does a fix exists?
3.02 .iso’s aren’t considered stable, they are as advertised for testing purposes. Latest stable release is 3.01. 3.02 .iso’s tend to have packages from testing repos. To have the latest stable Lx 3 one would install from 3.01 .iso and update without testing repos enabled. At least this is correct as far as I know.
Bug reporting tool doesn’t and hasn’t worked in OM Lx 3 ever as far as I know. Don’t know why it’s included and not removed. In fact I’m not even sure what it’s called. Is it the old ABRT from Fedora or is there also something that comes with Plasma5? Drkonqi?
The latest stable release 3.01 iso doesn’t have the encrypt your swap and root partition fixes as far as I know.
Using the 3.01 iso release will not fix my problem because the encrypt your swap and root partition fixes are part of the iso itself or do I see this wrong?
What is the fix for this problem?
You may try to create one encrypted partition formatted with lvm2, then create volume group an logical volumes inside at your wish. In this way you got the whole disk encrypted with the same password. I’m not sure Calamares can do this (I’ve never tested it) but you may try in vbox with the most recent 3.02 testing release iso first. Also note most recent version of GRUB let you encrypt the whole disk, also the
/boot partition so you don’t need a dedicate one any more.
I know that encryption (swap and /) works fine on 3.02. But as said in the previous replies it is unstable and I need a stable system.
What will be the name of the next stable iso and is there already a release time prediction?
Afaik an updated 3.01 is the same as 3.02. I mean they are the same release (they use the same repos) but 3.02 comes with already updated packages. The big change for you is 3.02 come with a newer version of Calamares supporting encryption. However, if you want be sure, 3.02 is planned to be released in a couple of weeks so you have not to wait so much.
If it’s just for the new calamares feature, I suppose that updating calamares from live before install could work.
Not sure if I have fully understood what’s the issue about though.
Great idea, but there is one problem, build 821 uses calamares 3.0.1 and OpenMandrivaLx3.01 live only allows you to install calamares 2.4.5 via MCC.
How can I install calamares 3.0.1 in live OpenMandrivaLx3.01?
First update urpmi database:
# urpmi.update -a
# urpmi calamares
Build 891 has been released.
The update with urpmi works fine. I get calamares 3.0.1 in the live environment but urpmi complains about possible errors during the calamares 3.0.1 upgrade.
Anyway I can install a new system with encrypted swap and root partitions and boot it.
The trouble is that the system crashes during the updates installation via MCC and becomes un-bootable.
Any suggestions how I can detect the problem packet (the update contains more than 700 packets)?
Where is build 891 situated in the 3.0, 3.01, 3.02 storry?
Are you using latest iso?
I see build 898 is out too (I haven’t tested it yet).
Easiest would be to use Konsole and:
# urpmi -v --auto-update
Of note: The package management utilities in OMCC are replaced by Discover.
vhelmont while it is technically true that 3.02 .iso’s aren’t ‘officially’ stable because 3.02 hasn’t been officially released. In reality they are merely a respin of Lx 3 with updated packages. Ergo if you install one of the known to work 3.02 .iso’s and use your normal repositories you’ll have as stable a system as any user that regularly updates their Lx 3 system. I haven’t tried .iso # 898 yet but I can recommend .iso # 891 as stable and well working on multiple boxes here.
I found the cause of my update problems.
The situation is as follows:
Starting from OpenMandrivaLx.3.01-PLASMA.x86_64.iso, I upgraded calamares in the live version to 3.0.1
I installed OpenMandrivaLx.3.01-PLASMA.x86_64 on /dev/sdc using the Manual Partition option with a luks encrypted swap and root partition. These are the only partitions on the disk. The bootloader is also situated on /dev/sdc
The new installation boots fine.
When I try to upgrade my new installation via MCC, I need to install around 741 packages.
During the upgrade process with plus/minus 183 packages to go I get the error messages:
Is it possible to fix these problems?
Put in ‘/etc/urpmi/skip.list’:
try that and post results here.
Edit: That should allow the other packages to update. Then we can deal with the lxqt package stack.
Update on install of Lx 3.01 (build #720) and then updating system. I just did a fresh install of Lx 3.01 in VBox and updated successfully. I did get the errors about lxqt packages but I restarted ‘–auto-updates’ (twice) and eventually all packages installed. Don’t know if I just got lucky or if this somehow got fixed.
The problem doesn’t change in may case when I adjust nothing and fire up “MCC, Software Packages Update” a few times .
If I understand you correctly you could install everything including the problem packages by starting the command “urpmi -v --auto-update” a few times?
On the other hand when I skip the problem packages by placing
in ‘/etc/urpmi/skip.list’ the rest of the packages install correctly.