A recent upgrade (zypper dup) on my OpenSuse 42.1, 64-bit system failed the installation of the package kernel-default-devel-4.1.39-53.1.x86_64 – it just hung at the message “Installing: kernel-default-devel-4.1.39-53.1.x86_64 —”. It hung there for hours. I tried again, repeatedly, then I downloaded the package and tried using rpm by itself – all in vain. The rest of the system upgrade went well, so I now run the said kernel with the earlier version purged, but the source header files haven’t been installed; e.g., the /usr/src/linux-4.1.39-53-obj directory stands empty. As a result, I cannot compile kernel modules for a software I need to use.
uname -a returns:
Linux hostname 4.1.39-53-default #1 SMP PREEMPT Thu Mar 30 06:44:23 UTC 2017 (56cc5a0) x86_64 x86_64 x86_64 GNU/Linux
Repeated experiment with rpm all hang; I have to reboot between in order to release the “shared lock on /var/lib/rpm/Packages”.
Could someone, please, let me know how to overcome this problem?
Yes, I have enough space: my root partition is 45% full, with 26 GB free space still available.
By the way, zypper does’t complain at all, it just hangs – and it does (does not) do it for hours, until I kill it.
In fact, in zypper’s terminal window lines there is a little “propeller” on the right end (brackets with a - or / or | or \ inside, alternating as time passes) that should indicate that something is happening. Well, that “propeller” isn’t turning either.
I didn’t check again what precise symptoms vanilla “rpm” produces (I will have to reboot for that to make the shared lock on /var/lib/rpm/Packages available) but it also fails, I remember.
Are you sure what did you use to view free space?? Snapper hides it’s files and the normal Linux utilities do not report correct space usage use snapper utilities. Assuming BTFS and snapper used
I never used snapper. I now did a 3-minute search on it but didn’t find how I can use it to report free space. Can you, please, quote the command to me? I used df to check available space. The FS on my / is xfs. Is there another way I should try?
In any case, I would be surprised if this were a disk free space problem. Running zypper now a day later, it does successfully download and install a number of other packages… but again hangs on kernel-default-devel-4.1.39-53.1.x86_64.rpm (by the way, at this time, zypper also reported file conflicts on this package, e.g.:
File /usr/src/linux-4.1.39-53-obj/x86_64/default/include/generated/utsrelease.h
from install of
kernel-default-devel-4.1.39-53.1.x86_64 (openSUSE-Leap-42.1-Update)
conflicts with file
/usr/src/linux-4.1.38-50-obj/x86_64/default/include/generated/utsrelease.h
from package
kernel-default-devel-4.1.38-50.1.x86_64 (@System)
But I just asked it to proceed after these messages. (No conflicts were reported when I experimented earlier.) However, asking zypper to proceed despite conflicts on this package shouldn’t hang it (it may cause some system inconsistency problems elsewhere, but on this particular package, I am not sure hos serious they would be).
By the way, before trying zypper this morning, I also tried rpm (could run in a freshly booted system) on the problem package, and this is what happened:
Are you using BTRFS if so the default is using snapper. If you use EXT4 or other file systems snapper is not used. If you do use BTRFS a OS upgrade can cause a large increase in snapper usage because all the files are changed and thus get put into snapshots. df/du do not show snapper usage only snapper and BTRFS commands show true disk usage
However, after further digging, I still suspect that the snapper utilities are not relevant for me. Reasons:
(a) I have an xfs file system for the / mount point (also please see my first response to you, above) – in fact, none of my filesystems are btrfs,
(b) The command “snapper list” from the link you provided produce “The config ‘root’ does not exist. Likely snapper is not configured. See ‘man snapper’ for further instructions.” – so maybe I really don’t have snapper working? My /etc/snapper/configs directory is empty.
Note also that, as I mentioned in my first reply to you, I can still install other packages without hanging the commands.
Also, my system/rpm/zypper doesn’t complain that no space is left on the device. It just hangs.
If you don’t use BTRFS then you do not use snapper. So it must be something else. Since you have chosen your own path it is hard to say. What else may you have done out of the ordinary??
“zypper dup” is what I did: it hung, repeatedly, hopelessly, on that particular package.
in an effort to narrow down the problem, I downloaded the problematic package alone, used “rpm -iv”. As I reported to you, it also hangs: after letting me know that it is “Preparing packages…”
I tried “zypper dup” after some time again, it happily installs other packages and then hung on this one again.
I kept trying and I posted this thread.
I keep trying and see the above (1, 2, 3) repeatedly.
Perhaps answering zypper’s late complaint about a file conflict was “out of the ordinary,” but (a) it made no difference, zypper didn’t install anything in response to my reply (I checked) and (b) I since (half an hour ago) figured out from where that file conflict complaint came. I fixed it, it is irrelevant to this bug: it arose from a symlink I inserted somewhere in order to try to still make kernel modules compile. They didn’t – but I don’t think this is irrelevant to the installation problem itself.
Can you let me know how I can more information out of zypper or rpm, to see where the problem may have arisen?
I keep upgrading within the same release until I have a few days worth of “near free” time without deadlines, etc. – this happens every other year or so. The reason: a system problem is too much of a risk for me. I am not a linux guru and I use my pc in a production environment, with daily deliverables etc. A new release often has some elements that aren’t entirely bulletproof and it also has new features that I have to get used to. That can cost days of precious work time. Like now
In fact, I already tested 42.2 on an another box and although installation went beautifully, the system cannot even boot into X. A little research revealed that the nouveau (?) driver packaged in 42.2 is still not working well for some graphics cards, the user is advised to change the driver if problems happen … Uh. Terrible. I gave up and switched to fedore on that machine. It took me a little time to get used to but at least I can use that box in some way, although not as well as my 42.1 system that started failing now because of the current problem.
Thank you for tolerating my lack of knowledge and pseudo-experience. (By the way, using “zypper dup” so far hasn’t given to me any trouble, and never seemed to be intent to upgrage me to a next OS version…)
I now tried “zupper up” – the result is the same. It downloads all packages all right, starts the installation fine, and then hangs when it gets to"kernel-default-devel-4.1.39-53.1.x86_64"
Using dup instead of up in 42.2 will cause the latest package to come fro where ever it is seen this can and will eventually break things because of mixed package versions. If you us up it uses vendor stickiness to get updates only from the same repo the package was installed from. This assures that all packages are of the same compatible builds and don’t get mixed and thus break.
I see KDE 3 do you try to use this older and much less maintained desktop?? Adobe is not needed the packages are also in Packman and can lead to mixed versions. You have two home/personal repos these can cause problems because they are not official and who know what people will put in them. Fine to get a package from but unless you understand things best not to leave active to have possible random package pulled from them with zypper dup.
In Yast - Software Management find the kernel source package and see where it comes from in the version tab bottom right.
Thank you!
I use the “normal” KDE plasma that came with the distribution (42.1), I included the KDE3 repository because it offers pdfedit. Similarly, I included the home/personal repos for a couple of specific software items there. I will try the Yast / Software management as soon as I can – time has run out on me for now, I am leaving for two weeks now. I will be back afterwards.
Thank you for your help!
G.
I really don’t think the kde3 repo will do any damage with zypper dup
I also use the kde3 repo for some old apps that have been forgotten (I mean how long does it take to update kpoker?)
but some of the other repo’s will
you need to do another zypper dup this time with the --from switch to make sure the kernel and other main bits are from the update repo
you should do
zypper dup --from 20
then do the same with packman, don’t do them together as multimedia might not get fixed if both repo’s are used in a single command
zypper dup --from 4
after this don’t use zypper dup unless you’re doing a full vendor change or upgrading your distro
you also seam to have both the ati and nvidia repo’s do you have some sort of mixed system with 2 graphic cards one amd/ati and the other nvidia what video card and driver do you have?
you really should remove unused repo’s
Thank you all for your help.
The issue got resolved by a fresh system installation, before I could read and then test the “zypper --from” options (I was traveling for a few weeks).
G.
