[SOLVED] slackpkg/pkgtools upgrade issue on -current
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Bug report: When the disk is full and slackpkg tries to upgrade a package that fails one of its internal steps, it still reports upgrade as successful:
Code:
+==============================================================================
| Upgrading kernel-modules-4.19.82-x86_64-1 package using ./kernel-modules-4.19.84-x86_64-2.txz
+==============================================================================
Pre-installing package kernel-modules-4.19.84-x86_64-2...
cp: error writing '/var/lib/pkgtools/scripts/kernel-modules-4.19.84-x86_64-2': No space left on device
Removing package: kernel-modules-4.19.82-x86_64-1-upgraded-2019-11-17,00:56:54
sort: write failed: 'standard output': No space left on device
sort: write error
sort: write failed: 'standard output': No space left on device
sort: write error
sort: fflush failed: 'standard output': No space left on device
sort: write error
sort: write failed: 'standard output': No space left on device
sort: write error
comm: file 1 is not in sorted order
comm: input is not in sorted order
comm: file 1 is not in sorted order
comm: input is not in sorted order
comm: write error
Verifying package kernel-modules-4.19.84-x86_64-2.txz.
Unable to install ./kernel-modules-4.19.84-x86_64-2.txz: tar archive is corrupt (tar returned error code 2)
Package kernel-modules-4.19.82-x86_64-1 upgraded with new package ./kernel-modules-4.19.84-x86_64-2.txz.
I think the OP is querying if the kernel has actually been upgraded and/or why slackpkg reports such if it hasn't been due to the root partition being full.
Last edited by Lysander666; 11-17-2019 at 05:52 AM.
Linux may be different, but my experience with Unix-like operating systems over the years has taught me not to troubleshoot with a full disk. The failure symptoms are typically inaccurate and won't lead you to a solution.
You should resolve the full disk problem before rerunning the slackpkg process(es).
Last edited by TracyTiger; 11-19-2019 at 12:09 PM.
Well, seems I should definitely word better my post. Yes, this was supposed to be a bug report. Yes, I know one should not run on full disks but incidents happens - just as it happened on this test setup, a process stored some large amount of data and died, but the OS was still alive and kicking, with room just enough to run the slackpkg tool and download a few files.
As I (poorly) wrote, even while the disk was full and clearly errors were reported by multiple commands through the upgrade process, it was still reported as a successful upgrade. Which should not, for many reasons, ranging from a novice user not sure what the impact of a half upgrade could bring, to someone not paying attention in full, or with automated scripts calling these apps in between.
So that’s the story. Yes, housekeeping is still a thing on any OS (which cron is already taking care of mine), but some sanity checks at tools so critical as system upgrades can make a difference on how robust or how amateur is the distribution.
And yes, I likely got sidetracked during OP and didn’t wrote much more details, as I just did it again on this one.
Well, the problem is that (from my experience anyways) a unix system with a full filesystem will be insane. You won't know what successfully made it to disk and what didn't.
If you use LVM and have multiple logical volumes, it could very well be the case that some (or most) of the upgrade made it but other important bits did not.
Been there, done that, bought the T-shirt, and bought an additional number of T-shirts (to my chagrin).
The fix is to reinstall the software that you thought you were upgrading, after you've ensured that there's plenty of room for the updates.
If English is your native language, you should be a little less insulting the next time you post.
Quote:
[...] how robust or how amateur is the distribution.
Am I missing something? Is it not reasonable to expect that upgradepkg not report that an upgrade occurred when there were several errors during the upgrade process? Just because we've gone years and/or decades without this issue being brought up doesn't mean that it shouldn't be considered a bug.
Quote:
Originally Posted by HQuest
Code:
Package kernel-modules-4.19.82-x86_64-1 upgraded with new package ./kernel-modules-4.19.84-x86_64-2.txz.
This final output of upgradepkg is a little deceiving considering how many errors were thrown during the upgrade process. Even saying something like "There were errors during the process. Upgrade may have failed." or something seems better than just saying "old-package upgraded with new package".
Yes, it is obviously better to not have a full system partition, but error messages that cover various issues like filling up the partition (many have had that rogue logfile get spammed and fill their filesystem) seem better than just saying "keep enough space on your system" and you won't run into the problem you just did.
Unable to install ./kernel-modules-4.19.84-x86_64-2.txz: tar archive is corrupt (tar returned error code 2)
Package kernel-modules-4.19.82-x86_64-1 upgraded with new package ./kernel-modules-4.19.84-x86_64-2.txz.
I agree this is an informational bug. The Unable to install message is from installpkg and the upgraded with new package message is from upgradepkg.
While the stdout provides plenty of clues, after the Unable to install message, the process should terminate with no additional messages or present a different message rather than upgraded with new package.
Past my bed time, but perhaps something like:
Code:
--- installpkg 2016-03-19 14:45:39.000000000 -0500
+++ installpkg.new 2019-11-19 22:22:08.881476067 -0600
@@ -378,9 +378,9 @@
cat $package | $packagecompression -dc | dd 2> $TMP/tmpsize$$ | $TAR tf - 1> $TMP/tmplist$$ 2> /dev/null
TARERROR=$?
if [ ! "$TARERROR" = "0" ]; then
- EXITSTATUS=1 # tar file corrupt
+ EXITSTATUS=1 # Unable to extract the tar archive
if [ "$MODE" = "install" ]; then
- echo "Unable to install $package: tar archive is corrupt (tar returned error code $TARERROR)"
+ echo "Unable to install $package: Unable to extract the tar archive (tar returned error code $TARERROR)"
fi
rm -f $TMP/tmplist$$ $TMP/tmpsize$$
continue
Code:
--- upgradepkg 2015-10-01 12:55:34.000000000 -0500
+++ upgradepkg.new 2019-11-19 22:24:52.360432298 -0600
@@ -335,10 +335,16 @@
# shift location, so we should always reinstall as the final step:
if [ ! "$NOT_PARANOID" = "true" ]; then
/sbin/installpkg $INCOMINGDIR/$NNAME
+ INSTALLPKG_EXITSTATUS=$?
fi
- echo "Package $OLD upgraded with new package $INCOMINGDIR/$NNAME."
- ERRCODE=0
+ if [ $INSTALLPKG_EXITSTATUS -eq 0 ]; then
+ echo "Package $OLD upgraded with new package $INCOMINGDIR/$NNAME."
+ ERRCODE=0
+ else
+ echo "There was an error installing $INCOMINGDIR/$NNAME."
+ ERRCODE=1
+ fi
done
if [ ! "$DRY_RUN" = "true" ]; then
The fix is to reinstall the software that you thought you were upgrading, after you've ensured that there's plenty of room for the updates.
If the fix is to ensure there's room for updates (and we are in an agreement in here) because the root cause was a full volume, and one or more intermediate processes failed, why the tool still reported success, then? That looks like a bug to me (and not a cosmetic one since files were modified on the disk). More so as each and every scripts and commands returns an exit code one should use to ensure no failure in the entire process chain is reported as "all good".
Adding to the fact Slackware's original package management was never the most robust of its features (no dependency check, no automatic download and no pre-requisites verification), this (and likely other scenarios as well) was an incident just waiting to happen.
Thanks @upnort for taking your time to look at the code.
And @Richard, improve your angry management skills, then thank me later.
If the fix is to ensure there's room for updates (and we are in an agreement in here) because the root cause was a full volume, and one or more intermediate processes failed, why the tool still reported success, then? That looks like a bug to me (and not a cosmetic one since files were modified on the disk). More so as each and every scripts and commands returns an exit code one should use to ensure no failure in the entire process chain is reported as "all good".
You can see the fix above posted by upnort. Not a check for required disc space, but a clean script exit.
Read the code...
Quote:
Originally Posted by HQuest
Adding to the fact Slackware's original package management was never the most robust of its features (no dependency check, no automatic download and no pre-requisites verification), this (and likely other scenarios as well) was an incident just waiting to happen.
Through +30 years never allowed free disc space to dive below 25% disc size, so such an "incident" has never occured.
Btw. Slackware package management I would very much like to *not* dependency check or auto-download anything. If Slackware did this, it would in my book violate the basic philosophy of the distro...
Friendly reminder, my patch is not robust and only addresses the immediate quirk of the OP. There are three additional places where installpkg is run in upgradepkg. In installpkg there are four additional places where EXITSTATUS= is used, which affects how upgradepkg might be patched with more informational or technically correct messages. A robust patch would evaluate all of those instances.
Adding informational or technically correct messages does not include any kind of sanity check for disk space. I think a basic sanity check would be useful -- that way the script terminates without all of the stderr spew shared by the OP.
Through +30 years never allowed free disc space to dive below 25% disc size, so such an "incident" has never occured.
"Through my +30 years flying my plane never crashed." That's how all these arguments about "do proper maintenance" sounds like. Yet, planes do crash, and their makers look at all the small details so one failed part doesn't cause the entire plane to crash "successfully".
Sorry for reporting what I thought would be a bug and causing this whole confusion. Enjoy your days.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
