Mailing List Archived Message #303

From: "Lewis G Rosenthal" <> Full Headers
Undecoded message
Subject: Re: [eCS-ISP] links in the ticket
Date: Thu, 1 Apr 2021 10:32:52 -0500
To: eCS ISP Mailing List <>


On 03/29/21 10:55 pm, Steven Levine wrote:
In <>, on 03/29/21
    at 11:33 PM, "Lewis G Rosenthal" <> said:


Who is to say that the configuration files were not the cause of the
failure(s) in the first place?
If this is a possibility, the user should be told how to check if this is
the case, assuming we already know how to do this check.

There are  number of things which can break the functionality of yum. As documented in the wiki, an existing Python build which is incompatible and referenced in CONFIG.SYS can do it. I'd have to look at what things in \etc could cause yum not to run, but your point is taken.

Also, while any failure mode is possible, this is not one that I recall
seeing, probably because the configuration files are mostly static.  I
don't include the rpm database here because it is not static and there is
a small window of time where it is at risk when an update is being
applied.  Also, we already have tools that can attempt to repair the rpm
datebase when the symptoms point to it as a problem.


Also, only deleting executable files not in the bootstrap could lead to
inconsistencies between the rpm db and the installed system. IOW, if we
are  replacing the existing rpm db with the one from the bootstrap, then
more  than executables should be removed;
I think if you testcase the process, you will find that the files that my
method would not delete are mostly application specific user files and are
not going to affect whether or not the Package Manager runs correctly.

We are looking at this from a couple of different perspectives. You are approaching this from the standpoint of getting a working YUM/RPM environment to make ANPM work. I am looking at it from the standpoint of getting a clean, fully-functional *nix subsystem. I see your point, however, and extra files are just some additional cruft. The \usr\local tree is the one to be renamed in the process, however, in case the user has populated it with any conflicting versions.

The way I look at it is that these files are there for a reason.  While
reinstalling the bootstrap might not replace them immediately, they will
be replaced, often with he same identical file as the user installs the
packages the the bootstrap reinstall implicitly deleted.


To say it another way, my POV is that the goal of reinstalling the
bootstrap is to put the Package Manager back into a working state while
minimizing the number of files that get deleted which might contain user
specific data.  Any leftover cruft can and will be taken care of as the
packages "lost" by the bootstrap reinstall are reinstalled.

I actually typed the above before I re-read your paragraph, here, but clearly, we're on the same frequency, now.

My needs for doing a clean bootstrap install are unique, in that I need to start with that in order to update it for a new bootstrap release. Thus, 0-cruft-tolerance is the order of the day. This is not the case for users who just need things to work, however, and if disk space is down so low that a few extra MB (in extreme cases) of leftover files would make a difference, there are bigger problems to be addressed than a non-working YUM/RPM setup.

however, if we are keeping the
installed  db,
I never considered doing this.  It's a bad idea.  The bootstrap db will
become the working db.  There may be extra files left in the directories
managed by the Package Manager after the unzip, but the chances of these
files causing the Package Manager to fail is minimal  If it turns out
there are exceptions, then they can be added to a must delete list.


The question that needs to be answered is if I unzip the bootstrap onto an
arbitrary working or broken Package Manager setup and overwrite any
conflicting files with the files from the bootstrap zip, do I get a
working Package Manager.  If I do, then I have accomplished my goal.
Bringing everything else back to the state it was before the bootstrap
reinstall was required will be normal Package Manager operations.

This will require some testing. Again, this does nothing constructive if the cause of the conflicts lies in \usr\local or PATH/LIBPATH settings in CONFIG.SYS. Now, ANPM does offer to set the paths in order at each startup (unless the option is deselected), but \usr\local content will always take precedence, so this tree needs to be clean.

Well, of those, only yum.log is part of the bootstrap itself. The other
files are not touched.
Then they can stay as long as the prior troubleshooting steps have
verified that they are not the cause of the problem to be solved.


See tickets 3112 and 1929.

Thinking about this.
The troubleshooting wiki essentially lists symptoms and solutions.
Re-bootstrapping isn't a symptom but an operation.
True.  The sypmtom is, as you say, every other recovery solution failed.

I'll start my draft from that perspective, then. Thanks.

There are numerous greps around, some pre-klibc (you may recall that our
one  enterprise client had a really, really old one in use), and some
more  functional than others.
Sure, it could be anything, but whatever grep he installed, he installed
only partially.  An normal install of the grep package will result in a
working grep because everything it needs will be installed.


One of my goals in working the stunnel issue with Massimo was to make the
idebug-small package as user-proof as possible.  Roderick and I had
already used an early version of the package to track down a couple of
application failures, but Roderick does not need to be spoon-fed when
doing this kind of stuff.  He recognizes and error message when he sees


Done, for the page title, however, note that the breadcrumbs now read:
Wikis > Package Manager > Package Manager Troubleshooting
I was wondering if you would be forced to do that way or there was way to
override the default bread crumb text.  I suspect most folks will not even
notice the somewhat redundant text.

There is probably some plugin to customize breadcrumbs, which comes along with all of the overhead of every other WordPress plugin - for a trivial pursuit.

Having thought about the bootstrap reinstall issue some more, the curent
processing sequence I envision is:

  - Verify that the user has shut down any non-essential
  - Confirm that the user is really really sure he/she
    wants to do this.
  - Use psfiles to capture a list of open files in the directories
    managed by the Package Manager.
  - Unlock the files.
  - Alert the user if one or more files cannot be unlocked.
    These will be data files.
    Exactly how to handle them is TBD.
    It really depends on the specific locked file.
  - Save any files we decide need to be saved.
    yum.log -> yum.log-orig etc.
  - Download the bootstrap.
  - Unzip the bootstrap overwriting any existing files.
  - Reboot.

I'd probably move the download operation to the top of the list, just after the user confirmation. If we can't download the bootstrap for some reason, there's not much point in continuing the process at this time. That said, yes, the logic works for me.

This should result in working Package Manager.

Yes, it should, previous caveats concerning CONFIG.SYS and \usr\local considered. (I would rename \usr\local in the procedure when we rename the existing yum.log, etc.)

If we want to be really nice, we could offer to convert the saved yum.log
into a list of packages the need to be installed because they were
logically uninstalled during the bootstrap reinstall.  The normal ANPM
update process will take care of the packages known to the bootstrap.

It might be hard to determine the level of detail in yum.log and how to parse it properly for package names as a result. Still, yes, this would be a nice finishing touch to hopefully provide the user with what he/she needs to get the system fully back to a working state.

Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA
Rosenthal & Rosenthal, LLC      
visit my IT blog      

Subscribe: Feed, Digest, Index.
Mail to ListMaster