Opened 7 years ago
Closed 6 years ago
#297 closed defect (no change needed)
YUM install of perl-Git package ends with error
Reported by: | darcio | Owned by: | |
---|---|---|---|
Priority: | Feedback Pending | Milestone: | |
Component: | yum | Version: | |
Severity: | medium | Keywords: | yum git perl-git chmod error |
Cc: |
Description
I'm attempting to install the Git package. Part of this install is the perl-Git package, however this step ends with an error.
Specifically the 'perl-Git-2.11.0-2.noarch' packge is selected however it produces the following error msg:
Error unpacking rpm package perl-Git-2.11.0-2.noarch
error: unpacking of archive failed on file /@unixroot/usr/share/perl5/vendor_per
l/Git.pm;5a6d0b34: cpio: chmod
Failed:
perl-Git.noarch 0:2.11.0-2
Following are the details of my RPM/YUM install:
[G:\]yum --version
3.4.3
Installed: rpm-4.13.0-17.oc00.i686 at 2017-09-06 23:08
Built : None at 2017-07-10 11:59
Committed: Dmitriy Kuminov <coding@…> at 2017-07-10
Installed: yum-3.4.3-11.oc00.i686 at 2017-09-06 23:25
Built : None at 2017-06-05 19:08
Committed: Dmitriy Kuminov <coding@…> at 2017-06-05
I thought that maybe my 'chmod' was the problem, the following is the version info for the currently installed package:
[G:\usr\share\perl5]chmod --version
chmod (GNU coreutils) 8.26
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David MacKenzie and Jim Meyering.
Attachments (5)
Change History (23)
by , 7 years ago
Attachment: | yum_installed added |
---|
comment:1 by , 7 years ago
Added the currently installed package list, along with detailed git and perl information.
comment:2 by , 7 years ago
Which command did you use to install git?
Do you have a clean yum/rpm environment?
comment:3 by , 7 years ago
I installed git from within ANPM. Since one of the dependencies is the 'perl-Git' package the ANPM process then showed an error attempting to install it. I then executed the install through CLI to get better visibility into where things were failing (and why).
Yes, I believe my YUM/RPM environment is clean because I had no problems installing any other packages.
I can certainly go through the maint procedures on my install, purge the cache, etc, etc, although I have already done that as I was attempting to troubleshoot this issue on my own.
Also, if it helps, I am comfortable executing the full install through CLI, no problem there.
comment:4 by , 7 years ago
One other thing, attempting to install just the 'perl-Git' package produces the following log:
Executing: @python G:\UTIL\ANPM\scripts\yum_install.py perl-Git
Running Transaction Check
Warning: RPMDB altered outside of yum.
Found 1 pre-existing rpmdb problem(s), 'yum check' output follows:
git-2.11.0-2.i686 has missing requires of perl-Git = ('0', '2.11.0', '2')
Error unpacking rpm package perl-Git-2.11.0-2.noarch
error: unpacking of archive failed on file /@unixroot/usr/share/perl5/vendor_perl/Git.pm;5a6aab1d: cpio: chmod
comment:5 by , 7 years ago
Priority: | major → Feedback Pending |
---|
please use CLI and do a "yum install git"
does that work?
comment:6 by , 7 years ago
Do you know which chmod is used? you could install which with "yum install which" and use "which chmod" to find it out.
I ask those questions because some developer of us recently installed everything from scratch and he had no issue. So we wonder a bit.
Those issues didn't start happening after you tried to switch from i686 to p4?
comment:7 by , 7 years ago
Hi Diver,
No, the issue was there prior to my attempted move from i686 to p4. In fact, the failure to install Git was one of the issues I was trying to address by moving to p4, really just hoping that something with my i686 platform install was "not right" and a move to p4 might wipe the slate clean.
As that stands, I am now somewhat trapped in the twilight zone it seems...LOL, I could not complete the move to p4. So I have a mix of i686 and p4. I am in the process of gathering some opensource benchmarking programs to understand what performance impact - if any - running a p4 targeted code vs i686 have. Once I have this info I will either go back to i686 (easily doable) or re-start from scratch and do a brand new p4 install.
Now regarding the Git issue. OK, I have the following chmod:
[G:\]chmod --version
chmod (GNU coreutils) 8.26
which produces:
[G:\]which chmod
G:/usr/bin/chmod.exe
..and it is a single install of chmod.exe that is present in the PATH. The other one is FPC (FreePascal) installation, but I have nothing in my environment variables pointing to it.
OK, so next step is the CLI to "yum install git", done, I uploaded the log file, but in this run it seems like yum stops the full install because it finds the previously installed git, even though the perl-Git is where the error occurs.
Doing "yum install perl-Git" shows the following:
[G:\]yum list perl-Git
Loaded plugins: changelog, ps, replace, verify
Available Packages
perl-Git.i386 1.7.6.1-7.oc00 netlabs-rel
perl-Git.i686 1.7.6.1-7.oc00 netlabs-rel
perl-Git.pentium4 1.7.6.1-7.oc00 netlabs-rel
perl-Git.noarch 2.11.0-2 netlabs-rel
...and I believe perl-Git.noarch is the correct version to install, that is certainly what I have tried to install in the past.
Should I go ahead and capture that install log?
comment:8 by , 7 years ago
could you eventually try it again on a fresh ArcaOS? As we have no idea what it could be and we can't reproduce it locally until now.
comment:9 by , 7 years ago
Sorry, I can not. I am not actually using this on ArcaOS, instead this is a Warp4 CP2 FP5 SMP install. No doubt, a very old install that has been progressively kept alive by applying the official updates.
Anyways, for what it's worth, I did completely un-install the i686 platform for YUM/RPM and removed all disk remnants of that install. I then deployed a clean pentium4 platform install. During that installation the tcl package errored out in the very same way, see the yum_tcl_install.log file I attached.
So...I've encountered the same issue with i686 and pentium4 platforms. Presumably the underlying codebase may be different (I have not confirmed this yet, but chmod --version shows the same release).
I also re-tried installing perl-Git with my pentium4 platform, but the result is the same.
At this point in time I have nothing else I can think of, my ultimate worry is that this issue will continue to impact my setups even as I attempt to utilize the YUM/RPM only approach to managing my applications.
If you have any other ideas, no matter what they are, as long as I can handle them on my single system, I am happy to try them.
Thanks!
comment:10 by , 7 years ago
Hey, another idea: how do I decipher what actually happens during RPM package install? I am thinking of literally manually executing the various installation steps in order to understand the CLI that fails...the error message really does not spell it out.
comment:11 by , 7 years ago
the strange thing here is, that on your first log you showed tcl as installed. So I really wonder why it worked then and doesn't now.
IIRC there are some debug possibilities on yum and rpm.
yum --help | less
gives you the options. You might play with --debuglevel=
comment:12 by , 7 years ago
diver: yes, when I opened this ticket I had the i686 platform deployed, at that time tcl installed fine, only this perl-Git was the issue. Since we were unable to debug the perl-Git problem I took the approach of wiping out the i686 platform and re-built from scratch using pentium4, but in that case the tcl failed right off the bat, apparently with the same failure as perl-Git.
I will pursue the --debuglevel= option, is there anything else I can read up on to understand how any given *.rpm package (such as the perl-Git one) is actually unpacked and installed by the RPM/YUM environment on our OS/2 platform? Maybe that will allow me to step through this one transaction at a time until I can find the root cause...Thanks!
comment:13 by , 7 years ago
But still to iron out all possible faults on your side I would do everything on a clean ArcaOS installation. If this is a no go for you I'm out of ideas sorry.
comment:14 by , 7 years ago
Hi diver,
Well, alright, thanks for the assistance. I did try the enhanced debug options, but nothing I tried actually produced any more results to show precisely where and why the failure was occuring.
Unfortunately a move from my current OS/2 install to AOS is simply not in the cards (as long as that requires a NEW install and no migration path exists, which it does not today). Given the challanges that remain the de-facto way of living on the OS/2 platform, should I chose to move away from my current combination I simply would pursue a Linux option instead.
Please go ahead and close the ticket.
comment:15 by , 7 years ago
as long as we don't know why it happens, we will not close the ticket. You never know one day there is a brilliant idea what it could be.
And the ArcaOS installation was not meant as a replacement of yours. It was more to see if you can reproduce this issue there as well.
comment:16 by , 7 years ago
Oh? I understand...alright, I'm in the process of making some hardware changes (deploying a 6TB NAS to off-load the multiple HPFS386 partitions off of my main OS/2 box). Once I have this done I will have a pile of extra disk capacity and should be able to do a test AOS install and re-test the issue there...absolutely happy to do so since you are going to keep the ticket open. This will take me some time though...I'm stuck at the moment on enabling the EAs on the ZyXel NAS...looks like I have to cook up my own config to accomplish this, so it's a bit of trial and error.
comment:18 by , 6 years ago
Resolution: | → no change needed |
---|---|
Status: | new → closed |
no more feedback or lack of interest. So closing it finally.
installed package list