Re: TW slow to process zypper dup?? (Pablo Sanchez) (Felix Miata)
Subject: Re: TW slow to process zypper dup??
On 2023-03-08 10:57, Fritz Hudnut wrote:
Today happens to be Leap 15.5 day . . . in #screen -L #zypper ref && zypper dup -l showed 289 packages to upgrade or process, including a kernel upgrade to 5.14 . . . ten minutes later the cursor was back. Same machine, possibly same drive or even an HDD compared to the SSD that TW is in . . . . TW took 1.5 hours to process less packages????
Hi Fritz,
Where was most of the time spent for the TW dup?
1. Repository refresh 2. RPM downloads 3. Running the updates
If you didn't capture times, please do so next time. Given the duration, it does not have to be precise.
Thx!
--- Pablo Sanchez - Blueoak Database Engineering
@Pablo: I have a pretty fast internet connection, so it doesn't take any time to refresh the repos and/or download the packages, by far the time is spent installing packages with lots of time on kernel and internet drivers . . . .
TW took 1.5 hours to process less packages????
Leap and TW have different mirror sets. Most contain the "LTS" Leap, with ostensibly slow churn (though not so much for the alphas & betas). A subset contains the rolling release TW, with near daily churn. In US that subset is small, so reliably decent average speed is a mere wish. -- Evolution as taught in public schools is, like religion, based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
@Felix Miata
On 2023-03-09 10:47, Fritz Hudnut wrote:
@Pablo:
I have a pretty fast internet connection, so it doesn't take any time to refresh the repos and/or download the packages, by far the time is spent installing packages with lots of time on kernel and internet drivers . . . .
Hi Fritz, The above is good information. On this last /dup/, did you run it within a Bourne compatible shell as follows? --8-<---8-<---8-<---8-<---8-<---8-<---8-<---8-<-- export ZYPP_MEDIANETWORK=1 export ZYPP_SINGLE_RPMTRANS=1 zypper dup -l --8-<---8-<---8-<---8-<---8-<---8-<---8-<---8-<-- Please note that /zypper dup/ will run a /refresh/ when needed. Also, I'm not sure if your email client is doing it but it keeps adding my name to the Subject (and I keep removing it. :) You might want to investigate why it's doing it. Cheers, --- Pablo Sanchez - Blueoak Database Engineering
et al: Got some coaching from malcomlewis about my thread; and while working through his inquiries I ran another dup -l in TW yesterday and I watched the processing of "150 packages," roughly the same number of packages to upgrade as it was a few days back. Except, this time in watching the console the 150 packages were downloaded and installed in roughly 2 or 3 minutes; then it went to a "post trans script of grub2-i386 xxxx" for what turned out to be roughly 35 minutes . . . . The question mark on that post trans script is, "Why is the i386 package installed in a 64 bit Apple machine at all?" And, then, why does it take so long to process that package?? TW is the distro that handles the grub2 dutiesfor this multi-boot machine . . . before I ran the zypper I was trying to get a new kernel flagged for one of the Gecko rolling installs . . . failing to revive from suspend . . . running that #update-bootloader command also took a very long time to run through . . . with a "failure" error and running a "mkconfig" . . . . New kernel did not improve the failure to revive issue there. For the purpose of this and previous iteration of the thread; seems like issues in and around grub2 are at work??? F
On Sun, Mar 12, 2023 at 8:27 AM Fritz Hudnut
et al:
Got some coaching from malcomlewis about my thread; and while working through his inquiries I ran another dup -l in TW yesterday and I watched the processing of "150 packages," roughly the same number of packages to upgrade as it was a few days back.
Except, this time in watching the console the 150 packages were downloaded and installed in roughly 2 or 3 minutes; then it went to a "post trans script of grub2-i386 xxxx" for what turned out to be roughly 35 minutes . . . .
The question mark on that post trans script is, "Why is the i386 package installed in a 64 bit Apple machine at all?" And, then, why does it take so long to process that package??
TW is the distro that handles the grub2 dutiesfor this multi-boot machine . . . before I ran the zypper I was trying to get a new kernel flagged for one of the Gecko rolling installs . . . failing to revive from suspend . . . running that #update-bootloader command also took a very long time to run through . . . with a "failure" error and running a "mkconfig" . . . . New kernel did not improve the failure to revive issue there.
For the purpose of this and previous iteration of the thread; seems like issues in and around grub2 are at work???
F
Latest update: For those following along with this interesting saga . . . today is "tumbleweed" day, so I thought, "Why not remove grub2-i386 package since I'm running a 64 bit machine?" . . . went to YaSt to make sure of the package name, ran a search, got a few packages to show up, two of them were installed. I tried to remove them, but a number of dependencies, including "grub2" that would have been de-installed as well. I then decided to "lock" the i386 packages and there were "138" packages to install upgrade, including a new kernel. Again, in watching more closely the download and then install of up to roughly 84 packages were done in 2 or 3 mins; then the process "hung" in a dracut line, "option --add-kernel not available for grub2-efi" for what turned out to be approx. 40 minutes . . . . Then, the remaining packages #85 - 138 were installed in a few seconds. So, the culprit continues to be involving "grub2" . . . .
* Fritz Hudnut
On Sun, Mar 12, 2023 at 8:27 AM Fritz Hudnut
wrote: ... For those following along with this interesting saga . . . today is "tumbleweed" day, so I thought, "Why not remove grub2-i386 package since I'm running a 64 bit machine?" . . . went to YaSt to make sure of the package name, ran a search, got a few packages to show up, two of them were installed. I tried to remove them, but a number of dependencies, including "grub2" that would have been de-installed as well. I then decided to "lock" the i386 packages and there were "138" packages to install upgrade, including a new kernel. Again, in watching more closely the download and then install of up to roughly 84 packages were done in 2 or 3 mins; then the process "hung" in a dracut line, "option --add-kernel not available for grub2-efi" for what turned out to be approx. 40 minutes . . . .
Then, the remaining packages #85 - 138 were installed in a few seconds. So, the culprit continues to be involving "grub2" . . . .
fwiw, and this is undoubtedly the incorrect forum for this discussion: I *only* have: grub2-i386-pc-extras-2.06-43.1.noarch grub2-i386-pc-2.06-43.1.noarch and they were automagically installed. and are the *only* 386 packages installed. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 2023-03-14 16:51, Fritz Hudnut wrote:
On Sun, Mar 12, 2023 at 8:27 AM Fritz Hudnut
wrote:
Latest update:
For those following along with this interesting saga . . . today is "tumbleweed" day, so I thought, "Why not remove grub2-i386 package since I'm running a 64 bit machine?" . . . went to YaSt to make sure of the package name, ran a search, got a few packages to show up, two of them were installed. I tried to remove them, but a number of dependencies, including "grub2" that would have been de-installed as well.
I then decided to "lock" the i386 packages and there were "138" packages to install upgrade, including a new kernel. Again, in watching more closely the download and then install of up to roughly 84 packages were done in 2 or 3 mins; then the process "hung" in a dracut line, "option --add-kernel not available for grub2-efi" for what turned out to be approx. 40 minutes . . . .
Then, the remaining packages #85 - 138 were installed in a few seconds. So, the culprit continues to be involving "grub2" . . . .
On Leap, not TW, I have: cer@Telcontar:~> rpm -qa | grep -i grub grub2-x86_64-efi-2.06-150400.11.17.1.noarch <==== grub2-i386-pc-2.06-150400.11.17.1.noarch <==== ruby2.5-rubygem-cfa_grub2-2.0.0-1.55.x86_64 grub2-systemd-sleep-plugin-2.06-150400.11.17.1.noarch grub2-2.06-150400.11.17.1.x86_64 <==== grub2-snapper-plugin-2.06-150400.11.17.1.noarch grub2-branding-openSUSE-15.4.20220322-lp154.2.3.noarch cer@Telcontar:~> On another machine: cer@Isengard:~> rpm -qa | grep -i grub grub2-snapper-plugin-2.06-150400.11.17.1.noarch grub2-branding-openSUSE-15.4.20220322-lp154.2.3.noarch grub2-i386-pc-2.06-150400.11.17.1.noarch <=== grub2-x86_64-efi-2.06-150400.11.17.1.noarch <=== ruby2.5-rubygem-cfa_grub2-2.0.0-1.55.x86_64 grub2-systemd-sleep-plugin-2.06-150400.11.17.1.noarch grub2-2.06-150400.11.17.1.x86_64 <=== cer@Isengard:~> I asked google. https://forums.bunsenlabs.org/viewtopic.php?id=3935 Index » Off Topic » [Now I KNow] Wondering why grub = i386 on 64bit system ... "i386-pc" is what GRUB uses to refer to non-UEFI systems, $DEITY alone knows why hmm -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Sun, 12 Mar 2023 08:27:39 -0700 Fritz Hudnut
"post trans script of grub2-i386 xxxx" for what turned out to be roughly 35 minutes . . . .
Only a tiny part of grub2 is written such that the to be performed task is done in the most efficient way. Try to run 'ps fax' a few times to see what this posttrans script is doing. Most likely something will hang in D state. Olaf
On 2023-03-15 11:59, Olaf Hering wrote:
Sun, 12 Mar 2023 08:27:39 -0700 Fritz Hudnut
: "post trans script of grub2-i386 xxxx" for what turned out to be roughly 35 minutes . . . .
Only a tiny part of grub2 is written such that the to be performed task is done in the most efficient way.
Try to run 'ps fax' a few times to see what this posttrans script is doing. Most likely something will hang in D state.
os-probe can take very long, specially if you have many partitions. And some types makes os-prober to loose its mind. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
participants (5)
-
Carlos E. R.
-
Fritz Hudnut
-
Olaf Hering
-
Pablo Sanchez
-
Patrick Shanahan