[SOLVED] slackpkg/pkgtools upgrade issue on -current

upnort · 11-22-2019, 11:04 PM

Possible test scenario:

* Modify installpkg/upgradepkg/slackpkg with set -e.
* Fill the system partition: dd if=/dev/zero of=/bigfile
* Attempt to install and update packages.
* When finished testing: rm -f /bigfile.

Using set -e might be a sledge hammer? Perhaps fail more gracefully with informative messages?

chrisretusn · 11-23-2019, 02:00 AM

As I read the first post again. It is very clear to me that the upgrade was NOT successful. Just because the last line says "Package bla-bla upgraded with new package bla-bla" does not make it so, given the errors shown immediately preceding that line.

Having said that, I see nothing wrong with adding some sanity check code to the script as upnort suggest. This is not hand holding. While I have never encountered this type of issue when upgrading, it can happen. Drive space can get clobbered for a variety of reasons.

gus3 · 11-23-2019, 05:06 AM

Looking through the Bash info pages, I find an alternative to "set -e" might be to set a trap on ERR. It uses the same rules as "set -e" for detecting a non-zero exit code, but it provides the chance to respond to said code within the script. In this case, to report that an upgrade has probably failed.

Richard Cranium · 11-23-2019, 08:13 PM

Quote:

Originally Posted by upnort

A note: my proposed patch was created in 14.2. The patch needs massaging for Current.

If deemed important, a disk partition sanity check could be added. The package compression needs to be pierced to obtain true file size requirements. If multiple packages are being installed/updated, then the sanity check should loop through all packages before comparing to the remaining disk space.

A simple test might be to grab the /bin/df percentage output and if greater than, say, 95%, post a warning message and ask the user whether to continue.

The problem is that people (such as myself) may well have an insane number of mount points; some of them applicable, some of them not. For example...

Code:

# df -h
Filesystem                      Size  Used Avail Use% Mounted on
tmpfs                            32M  1.3M   31M   4% /run
devtmpfs                        8.0M     0  8.0M   0% /dev
/dev/dm-13                      7.0G  3.2G  3.9G  45% /
tmpfs                            16G  292K   16G   1% /dev/shm
cgroup_root                      16G     0   16G   0% /sys/fs/cgroup
/dev/md0                        496M   92M  379M  20% /boot
/dev/mapper/mdgroup-qemulv       47G   22G   26G  47% /spare/1
/dev/mapper/mdgroup-archstore   4.0G  2.7G  1.1G  72% /spare/5
/dev/mapper/mdgroup-extraslv    4.5G  3.6G  928M  80% /extras
/dev/mapper/mdgroup-homelv      127G  117G  4.5G  97% /home
/dev/mapper/mdgroup-varlv        16G   15G  1.2G  93% /var
/dev/mapper/mdgroup-dockerlv    6.0G  3.6G  2.5G  60% /var/lib/docker
/dev/mapper/mdgroup-java         13G  6.0G  6.6G  48% /spare/4
/dev/mapper/mdgroup-junk         57G   50G  4.2G  93% /spare/6
/dev/mapper/mdgroup-xconqlv     4.0G  496M  3.6G  13% /var/mcp
/dev/mapper/mdgroup-slaptlv     7.5G  5.6G  2.0G  75% /var/slapt-get
/dev/mapper/mdgroup-tmplv       8.0G  2.9G  5.2G  36% /var/tmp
/dev/mapper/mdgroup-newhomelv    10G  8.6G  1.5G  86% /newhome
/dev/mapper/mdgroup-newroot      30G   28G  2.8G  91% /newroot
/dev/mapper/mdgroup-opt          17G   16G  1.4G  92% /opt
/dev/mapper/mdgroup-newmusiclv   20G   19G  1.4G  94% /opt/music
/dev/mapper/mdgroup-sourcelv     28G   27G  1.8G  94% /source
/dev/mapper/mdgroup-usr          31G   28G  3.0G  91% /usr
/dev/mapper/mdgroup-usrlocal     12G   11G  609M  95% /usr/local
/dev/mapper/mdgroup-winimage     30G   44M   28G   1% /usr/local/winimage
/dev/mapper/mdgroup-libvirtlv   191G  107G   85G  56% /var/lib/libvirt
/dev/mapper/mdgroup-pgsqllv     2.0G   71M  2.0G   4% /var/lib/pgsql
/dev/mapper/mdgroup-mongostore   80G  6.0G   75G   8% /var/lib/mongodb
/dev/mapper/mdgroup-tacllv      2.0G  1.3G  613M  68% /mnt/backups
/dev/mapper/mdgroup-slackroll   4.0G  704M  3.3G  18% /var/slackroll
tmpfs                            16G   72K   16G   1% /tmp
cgmfs                           100K     0  100K   0% /run/cgmanager/fs

I could wake up tomorrow and decide that /lib and /lib64 need their own logical volumes or that /usr/lib64 does. (That would be insane as things are, but I could patch initrd's init script to handle those scenarios; I more-or-less did so for the /usr mountpoint.)

I'm all for scripts that prevent a system admin from shooting him/her/itself in the foot. I just think the system admin should be the one to write them.

HQuest · 11-29-2019, 09:13 PM

Quote:

Originally Posted by Lysander666

Anyway, the OP was edited a couple of days later so I'm not 100% sure [and I can't be bothered to check since I'm going to cook supper].

The post was edited to add the words "Bug report:" to its first sentence. See attached picture.

Quote:

Originally Posted by Richard Cranium

When I submit a bug report, I attempt to provide the information required to reproduce the problem that I encountered as well as any specific hints that might help solve the problem.

Apparently without stating the obvious, one has to assume 1) people are amateur, 2) everybody wants to have their own problems solved and 3) we only insult others by stating the truth.

It seemed pretty clear to me the error, caused by a full volume, had to be resolved by resuming the process with enough free space. This is no rocket science to me, to you and others, but I learned to see things from a less than average person. I could write something by myself, sure. More likely I would be adding a ton of "[ $? -ne 0 ] && exit" code, whereas others already pointed "set -e" is a far more elegant solution. Yet, because I opted to be minimalistic and understandably I went too minimalistic without even writing enough verbiage, I ended causing more discord than helping the community out.

Quote:

Originally Posted by Richard Cranium

To the best of my knowledge, none of us here are paid to post responses to anything. To the best of my knowledge, Mr. Volkerding's income from Slackware is orders of magnatude less than RedHat's market cap of ~$20B.

And that's exactly my point by calling Slackware an amateur distro. It is irrelevant my first Slackware CDs were the 2-disc Slackware 3.0 CD with the platypus on the front cover back in the early 90's and I've been using it amongst a ton of other Linux and Unix systems for the past 27 years, but yes, I'm an amateur. And so is Slackware. Being an amateur, however, it is not an offense IMHO - more below. I know a ton of "amateur astronomers" which are pretty happy being "amateurs" and are all proud of their achievements, and so it is Pat Volkerding: he has THE oldest Linux distro of all, that alone is an amazing achievement he should be proud of. Yet, he is not even close of RedHat or SuSE market share, revenue or popularity on neither enthusiast or corporate worlds. Choices he made for reasons that are not to be discussed here.

A little finesse, as I lacked, could be appreciated on the distro too. You see, if all that it takes to avoid such "amateur" error of not checking for a disk space prior to begin a file download is a 6 byte long string, does it truly warrant going the rage road on users?

Quote:

Originally Posted by Richard Cranium

If English is your native language, you should be a little less insulting the next time you post.

https://www.merriam-webster.com/dictionary/amateur

"amateur", first definition of the noun word, according to Merriam-Webster: one who engages in a pursuit, study, science, or sport as a pastime rather than as a profession.

If you only consider this word as of its second definition, I repeat: work on your anger management, and thank me later. Or maybe learn some English.

Richard Cranium · 11-30-2019, 07:22 PM

You do know, don't you, that Mr. Volkerding's income is from Slackware and nothing else?

But don't let me stop you from molesting that chicken.