Description of the issue (screenshots if relevant):
It goes through all the way to the “Finish” section, and returns message:
“Installation Failed
Cannot disable root account
passwd terminated with
error code 254”
Relevant informations (hardware involved, software version, logs or
output…):
The machine will boot the live version successfully in basic graphics mode, but will not install. I can access the system logs, and open a console if necessary to obtain additional information.
Hi Rugyada!
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.
I started over fresh by downloading the OpenMandrivaLx.4.3-plasma.x86_64.iso file from the OM website download page
I confirmed that the checksums:
(sha1sum: 08070903464014dbc81094e4cb940ef92d586d36) do match.
I re-created the USB boot drive (PNY 16GB USB 2. FD) using rosa-imagewriter (version 2.6.2.1) included with the distribution release by using another machine
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:
“Installation Failed
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.
As requested, here is the screen text output from pkexec calamares -d: pkexec clamares -d.txt (19.0 KB)
If there are any other pertinent details I have omitted, please let me know.
Thanks for your help.
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.
Almost forgot…
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 am guessing about this. I have never seen this issue before.
It would seem something about the drive being installed to won’t allow it to be written to. Maybe.
You could consider securely erasing or shredding that drive. The KDE Partition Manager will a shred a partition or drive. It is not a quick process. Another article on shredding.
The log does not show that. I am no expert log reader but it appears to the log ends after the installer has preformed pre-installation checks and before partitioning is done.
The log not showing the error produced is not normal.
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.
As requested, here is the screen text output from the above installation: pkexec clamares -d.txt (19.0 KB)
Thanks again to both of you for your help with this.
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.
Ok, guys, here’s what I found.
I don’t know what I can do about it, but it appears critically relevant to me:
Lines 938 thru 974 of the previously uploaded calamares installation log, included here again, relate to this error, particularly at line 966:
13:25:22 [6]: virtual void Calamares::JobThread::run()
Starting job "Set password for user root" ( 23 / 35 )
13:25:22 [6]: static CalamaresUtils::ProcessResult CalamaresUtils::System::runCommand(System::RunLocation, const QStringList &, const QString &, const QString &, std::chrono::seconds)
Running "chroot" ("/tmp/calamares-root-mo9adtp0", "passwd", "-dl", "root")
.. Target cmd: ("passwd", "-dl", "root") Exit code: 254 output:
passwd: Only one of -l, -u, -d, -S may be specified.
pkexec clamares -d.txt (19.0 KB)
Looks like invalid arguments were embedded in the command.
Only ONE of either “d” OR “l” are allowed…
…now what do we do?
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.
