From: "Lewis G Rosenthal" Received: from [72.86.41.184] (account lgrosenthal@2rosenthals.com HELO [192.168.201.141]) by 2rosenthals.com (CommuniGate Pro SMTP 5.4.10) with ESMTPSA id 1770502 for ecs-isp@2rosenthals.com; Mon, 29 Mar 2021 23:33:23 -0400 Subject: Re: [eCS-ISP] links in the ticket To: eCS ISP Mailing List References: Organization: Rosenthal & Rosenthal, LLC Message-ID: <6062AA10.1050101@2rosenthals.com> Date: Mon, 29 Mar 2021 23:33:20 -0500 User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:38.0) Gecko/20100101 Firefox/38.0 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi... On 03/29/21 06:37 pm, Steven Levine wrote: > In , on 03/29/21 > at 03:47 PM, "Lewis G Rosenthal" said: > > Hi, > >> And what would that do in practice? Assuming the system has: >> \etc >> \usr >> \var\cache >> \var\lib >> \var\log\yum.log >> \var\run >> \var\tmp >> would we download the bootstrap, unlock all files in those directories, >> delete them, and then unzip the bootstrap before prompting for a reboot? > Pretty much, although I would do the delete after the unzip and would only > delete executable files that were not in the bootstrap and whatever can be > safely deleted from the cache directories. This would lose less of the > users prior configuration and the retained files are unlikely to break > anything. > Who is to say that the configuration files were not the cause of the failure(s) in the first place? 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; however, if we are keeping the installed db, then the bootstrap would add files potentially not inventoried in the db. From my perspective, this is a one-way ticket: either (re)move all existing content or none of it, and if not removing, the bootstrap content may only serve to make things worse. > I would probably also help the user help themselves by saving copies of > the .rep files and secure.rep and yum.log and exported.yum and such just > in case they were needed after the bootstrap is installed and overlaid > their customized versions. > Well, of those, only yum.log is part of the bootstrap itself. The other files are not touched. > I'd be fine with a standalone script for this, but given that a large > number of our users are command line challenged, doing it from ANPM seemed > to be a better solution for them. Along these lines, rather than a > command line /BOO option, this probably should be an ANPM menu option with > 3 or 4 are you sure prompts. :-) See tickets 3112 and 1929. >> Because re-bootstrapping is potentially a destructive operation, we need >> to be clear as to what we're doing and why. Perhaps the reason that yum >> might not be working is that yum.conf is broken; re-bootstrapping >> becomes great overkill. > Which is why it would be documented as the last item in > > https://www.arcanoae.com/wiki/anpm/troubleshooting/ > > with plenty of warnings as to what to expect and perhaps with a suggestion > to submit a ticket first. Thinking about this. The troubleshooting wiki essentially lists symptoms and solutions. Re-bootstrapping isn't a symptom but an operation. Assigning a single (or group of) symptom(s) leading to this as a possible solution would be nigh on impossible, other than saying "When all else fails, the path remappings have been confirmed, and yum still won't run." (And maybe that's the proper "symptom" to use, with the re-bootstrapping procedure described broadly, followed by a bulleted list of what will be lost from the original setup.) >> That would be my guess. Not many current packages are in the i386 repo. > Well, not quite yet. He still has a broken grep, probably because he > copied grep.exe from elsewhere. An ANPM install of the package should fix > this up. > 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. > The good news is that he has gotten far enough that the debugger starts > properly. Once he gets all the scripts updated to the most recent > versions from 2020 (don't ask), he should be ready to try to replicate the > 100% usage issue under the debugger. Good. > BTW, I think it would be better if the page title was "Package Manager > Troubleshooting.". Just "Troubleshooting" is a bit to generic for my > taste, especially when I have multiple troubleshooting pages open at the > same time. > Done, for the page title, however, note that the breadcrumbs now read: Wikis > Package Manager > Package Manager Troubleshooting which seems oddly redundant to me. Still, the tab title is more easily recognized. ;-) -- Lewis ------------------------------------------------------------- Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA Rosenthal & Rosenthal, LLC www.2rosenthals.com visit my IT blog www.2rosenthals.net/wordpress -------------------------------------------------------------