It’s an official release downloaded from SourceForge running on real machine.
(Don’t have the check sums but I downloaded it when it 1st became available from Source Forge and I’ve used it on several machines and it’s worked perfectly.)
The problem is that I can only access the system logs after I successfully boot the live system… the system hangs after the installation failure, so the logs of the failed attempt are not accessible, and since they’re volatile, they disappear so I can’t recover them on the next live boot.
Do you think that there might be any worthwhile information in the successful live boot logs?
Or maybe some other way to capture the logs in some kind of parallel off-system dual process that I could initiate and have running for the installation?
Checksums are still present on SourceForge. Checking these is to easy to not do it.
Another good problem solving step is to copy the exact error and paste it in an internet search . Or copy the pertinet part or error and search that. It can be helpful to preface such a search with the work Linux.
Installing to a clean partition (erase & format entire drive as a single partition with swap & hibernate)
If I boot the live session using the default menu selection, there are intermittent display irregularities resembling jagged “fractured glass” appearing screen images.
Selecting the “basic graphics” boot option under “troubleshooting” does not produce that problem.
12.Neither boot option will complete the installation, failing at the same point in the install process, and generating the same message and error code:
It goes through all the way to the “Finish” section, and returns the message:
Cannot disable root account
passwd terminated with
error code 254”.
(I had done an internet search for the error message, but no help.)
I can access logs either way as long as I remain in a live boot session; once I attempt installation and it fails, the system hangs and nothing is retrievable. So I can access the /var/log directory before attempting the install, but there will be no installation log created yet, and I can’t access anything once the system hangs.
Calamares, by its own, can’t modify any partitions filesystem (if it was the case) while it installs;
IMHO the best move (as you are ready to wipe whatever data in your HD) is to clear the HD completely.
Then reboot the ISO in live mode and try again, either with automatic partitioning or manual partition at your choice/need. You should see your HD clean and empty
I’ve currently started a new 4.3 ISO build for testing. Provided it builds successfully you may try this snapshot. I will edit the present post adding the link for download later.
For what concerns the calamares log, please apply a slight modification and run instead:
pkexec calamares -d |tee /home/live/cala-install.log
This way you will find the full log in your live user home, more easy to c/p and to attach. Be sure to close the calamares window, or the log will be trunked of the last bits.
You may also try one of the latest snapshot of the rolling flavor.
Rolling is way more up-to-date with packages and all the rest. And at this time way more reliable.
I have attempted over a dozen installations at least, and every time, I chose “erase entire drive” option.
KDE partition Manager (ver. 21.12.2) shows the unmounted drive currently has 6.94GB used of 29.09GB total in an EXT4 partition.
Booting PartedMagic 5.7 and exploring with GParted (ver. 0.16.1) confirms same.
I personally removed this drive from a confirmed working Windows machine immediately prior to installing in the current machine, and was subsequently able to successfully boot Windows in the current machine, so I know that the present EXT4 partitioning, formatting, and data could only have come from the OM Lx 4.3 installation attempts.
SMART status: good
Shredded the partition via KDE Partition Manager (ver. 21.12.2)
Confirmed successful partition shred via KDE Partition Manager (partition type unknown)
Ran pkexec calamares -d |tee /home/live/cala-install.log from Konsole.
I immediately noticed that this installation is taking a lot more time, progressing noticeably slower than the others, and the disk access light is constantly flickering, unlike previous attempts.
You probably already know I am not an expert on this. So for 1 I would go on IRC and ask someone like @bero or @TPG. They have slightly different handles on IRC. This might get to an answer the fastest.
Since my previous reply, I have replaced the drive with another in the same machine, and I’m running the installation program now.
Maybe the outcome will help to narrow things down…
…might even be successful, who knows?
Thanks for your help, and the contact recommendations.
If necessary, I will contact them.
In order to be very sure nothing untoward has happened to our .iso file on SF I downloaded it today and checked checksums. All OK, then did a test install on a hw system. Again no problem. Everything seems normal.
@deltakprime we need to figure out why on that computer or on that hd this error is happening? What is provoking that apparently incorrect command? And that will probably need the help of gurus on IRC.
It is a mystery to me.
This is the install log of that test installation:
Thanks Ben. I appreciate your efforts, and I’m really looking forward to finding out what’s going on with this situation.
As a curiosity, I would wonder what that segment of the code revealed through the calamares installation log on the computers that you have successfully installed Lx 4.3 on. Is there a similar reference to the passwd command arguments? Are the same arguments all there and acceptable, or are the number of arguments different in your version? Or maybe that line does not appear because the code branches off differently based on something different about your situation from mine.
I’m eager to find out.