[opensuse-factory][42.2] zypper up/dup: Cannot read input: bad stream or EOF
On an alpha on host hpg33 last updated (installed?) in July, after zypper ref I tried to zypper up, and it aborted with $SUBJECT message. I got it to update by using the suggested-by-error-message --non-interactive option. Afterward, I tried to zypper dup, but it produces the same result as before the update. rpm --rebuilddb, zypper clean -a and zypper ref didn't help. Searching for $SUBJECT in boo as comment produces no hits in past 11 months. Rebooting seems to have fixed it. Any ideas what happened, or didn't? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata [27.10.2016 07:55]:
On an alpha on host hpg33 last updated (installed?) in July, after zypper ref I tried to zypper up, and it aborted with $SUBJECT message. I got it to update by using the suggested-by-error-message --non-interactive option. Afterward, I tried to zypper dup, but it produces the same result as before the update. rpm --rebuilddb, zypper clean -a and zypper ref didn't help. Searching for $SUBJECT in boo as comment produces no hits in past 11 months. Rebooting seems to have fixed it.
Any ideas what happened, or didn't?
Maybe this happened during the high load phase on the main repo server, where many people had problems to reach download.opensuse.org at all? --
Werner Flamme composed on 2016-10-27 08:33 (UTC+0200):
Felix Miata composed:
On an alpha on host hpg33 last updated (installed?) in July, after zypper ref I tried to zypper up, and it aborted with $SUBJECT message. I got it to update by using the suggested-by-error-message --non-interactive option. Afterward, I tried to zypper dup, but it produces the same result as before the update. rpm --rebuilddb, zypper clean -a and zypper ref didn't help. Searching for $SUBJECT in boo as comment produces no hits in past 11 months. Rebooting seems to have fixed it.
Any ideas what happened, or didn't?
Maybe this happened during the high load phase on the main repo server, where many people had problems to reach download.opensuse.org at all?
Unless there was another one after the one resolved Wednesday AM, not likely. This only happened in the hour before OP, Thursday AM. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata composed on 2016-10-27 01:55 (UTC-0400):
On an alpha on host hpg33 last updated (installed?) in July, after zypper ref I tried to zypper up, and it aborted with $SUBJECT message. I got it to update by using the suggested-by-error-message --non-interactive option. Afterward, I tried to zypper dup, but it produces the same result as before the update. rpm --rebuilddb, zypper clean -a and zypper ref didn't help. Searching for $SUBJECT in boo as comment produces no hits in past 11 months. Rebooting seems to have fixed it.
Any ideas what happened, or didn't?
Happened again, but on host gx62b last updated 2 Aug. A little more detail this time: I normally don't just zypper up. Instead, I run the following script first (but after zypper ref): #!/bin/sh zypper -v in zypper libzypp libsolv-tools rpm openSUSE-release zypper -v in device-mapper dmraid glibc lvm2 multipath-tools mdadm systemd udev Running the script before zypper up/dup provides me opportunity to check if /etc/zypp /zypp*conf.rpmnew has appeared or changed so I can see if I want to make any adjustment before proceeding. So when the abort occurred trying to zypper up, unlike on hpg33, I rebooted instead of proceeding directly to up. After, zypper up worked as expected. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 29 Oct 2016 08:34, Felix Miata wrote:
Felix Miata composed on 2016-10-27 01:55 (UTC-0400):
On an alpha on host hpg33 last updated (installed?) in July, after zypper ref I tried to zypper up, and it aborted with $SUBJECT message. I got it to update by using the suggested-by-error-message --non-interactive option. Afterward, I tried to zypper dup, but it produces the same result as before the update. rpm --rebuilddb, zypper clean -a and zypper ref didn't help. Searching for $SUBJECT in boo as comment produces no hits in past 11 months. Rebooting seems to have fixed it.
Any ideas what happened, or didn't?
Happened again, but on host gx62b last updated 2 Aug. A little more detail this time: I normally don't just zypper up. Instead, I run the following script first (but after zypper ref):
#!/bin/sh zypper -v in zypper libzypp libsolv-tools rpm openSUSE-release zypper -v in device-mapper dmraid glibc lvm2 multipath-tools mdadm systemd udev
Running the script before zypper up/dup provides me opportunity to check if /etc/zypp /zypp*conf.rpmnew has appeared or changed so I can see if I want to make any adjustment before proceeding.
So when the abort occurred trying to zypper up, unlike on hpg33, I rebooted instead of proceeding directly to up. After, zypper up worked as expected.
THAT has a clear cause: a new glibc/udev was installed by the script, and any program started after that will use the the new ones while the already running programs still use the old ones. That is a surefire way to get a program to crash. So, the logic involved should include a reboot after the script is run if a new glibc/udev was installed, or go the secure way and include a reboot command in the script (if the previous two zypper commands whre run without error) Have a nice weekend - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Yamaban composed on 2016-10-29 12:49 (UTC+0100):
Felix Miata wrote:
Felix Miata composed on 2016-10-27 01:55 (UTC-0400):
On an alpha on host hpg33 last updated (installed?) in July, after zypper ref I tried to zypper up, and it aborted with $SUBJECT message. I got it to update by using the suggested-by-error-message --non-interactive option. Afterward, I tried to zypper dup, but it produces the same result as before the update. rpm --rebuilddb, zypper clean -a and zypper ref didn't help. Searching for $SUBJECT in boo as comment produces no hits in past 11 months. Rebooting seems to have fixed it.
Any ideas what happened, or didn't?
Happened again, but on host gx62b last updated 2 Aug. A little more detail this time: I normally don't just zypper up. Instead, I run the following script first (but after zypper ref):
#!/bin/sh zypper -v in zypper libzypp libsolv-tools rpm openSUSE-release zypper -v in device-mapper dmraid glibc lvm2 multipath-tools mdadm systemd udev
Running the script before zypper up/dup provides me opportunity to check if /etc/zypp /zypp*conf.rpmnew has appeared or changed so I can see if I want to make any adjustment before proceeding.
So when the abort occurred trying to zypper up, unlike on hpg33, I rebooted instead of proceeding directly to up. After, zypper up worked as expected.
THAT has a clear cause: a new glibc/udev was installed by the script, and any program started after that will use the the new ones while the already running programs still use the old ones. That is a surefire way to get a program to crash.
Methinks one of us misunderstands the other. My script only has two executable lines, neither of which is zypper up (or zypper dup). What running program would cause zypper up when run after my script to abort? Last modified time on my script is 18 months ago, so my process has proven reliable up to now (each of TW, 42.1, 13.2, 13.1, and on multiple hosts), and has become a problem only for 42.2.
So, the logic involved should include a reboot after the script is run if a new glibc/udev was installed, or go the secure way and include a reboot command in the script (if the previous two zypper commands whre run without error)
I have to think that were my script were not used, but simply 'zypper ref; zypper up' run that were the up interrupted for any reason after the various package management and fundament packages were installed that a restart of up would fail in same manner as using the script, and a reboot required in order to get up to finish. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-10-29 17:45, Felix Miata wrote:
I have to think that were my script were not used, but simply 'zypper ref; zypper up' run that were the up interrupted for any reason after the various package management and fundament packages were installed that a restart of up would fail in same manner as using the script, and a reboot required in order to get up to finish.
Yes. Which is why I prefer the DVD offline upgrade method. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. composed on 2016-10-29 20:21 (UTC+0200):
Felix Miata wrote:
I have to think that were my script were not used, but simply 'zypper ref; zypper up' run that were the up interrupted for any reason after the various package management and fundament packages were installed that a restart of up would fail in same manner as using the script, and a reboot required in order to get up to finish.
Yes.
Which is why I prefer the DVD offline upgrade method.
Thread is not about "upgrading" (e.g. 42.1 to 42.2). It's about normal updates process via zypper, instead of YaST2 or whatever the GUI update automater of the week happens to be, bringing already existing 42.2 current. I wasn't aware anyone except under unusual circumstances would try to perform normal updating offline. Very rarely do I download any pre-release DVD iso. At lease since SuSE 8.2 I install most times via HTTP started using Grub loading installation kernel and initrd from local disk then everything else via Internet. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-10-29 20:45, Felix Miata wrote:
Carlos E. R. composed on 2016-10-29 20:21 (UTC+0200):
Felix Miata wrote:
I have to think that were my script were not used, but simply 'zypper ref; zypper up' run that were the up interrupted for any reason after the various package management and fundament packages were installed that a restart of up would fail in same manner as using the script, and a reboot required in order to get up to finish.
Yes.
Which is why I prefer the DVD offline upgrade method.
Thread is not about "upgrading" (e.g. 42.1 to 42.2). It's about normal updates process via zypper,
A "zypper dup" is not a normal upgrade, sorry. And you were upgrading a test 42.2 release, for which DVDs were also provided. And you were also jumping several weeks of upgrades. In that time, there were upgrades to glib, it seems, which makes it a non-normal "update". I would expect problems. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. composed on 2016-10-30 23:23 (UTC+0200):
Felix Miata wrote:
Carlos E. R. composed on 2016-10-29 20:21 (UTC+0200):
Felix Miata wrote:
I have to think that were my script were not used, but simply 'zypper ref; zypper up' run that were the up interrupted for any reason after the various package management and fundament packages were installed that a restart of up would fail in same manner as using the script, and a reboot required in order to get up to finish.
Yes.
Which is why I prefer the DVD offline upgrade method.
Thread is not about "upgrading" (e.g. 42.1 to 42.2). It's about normal updates process via zypper,
A "zypper dup" is not a normal upgrade, sorry. And you were upgrading a test 42.2 release, for which DVDs were also provided. And you were also jumping several weeks of upgrades.
It's totally normal here. I have lots of installations. I try to update most no more often than once every 60 days except to do follow-ups to specific bug reports. This thread represents my first significant problem with zypper cmdline in memory, whether in TW or any of the distribution releases. IOW, the process I use for updating has been working well. Plus it's quite a pleasure to use compared to URPM, DNF and Apt and its derivatives.
In that time, there were upgrades to glib, it seems, which makes it a non-normal "update". I would expect problems.
Grepping through /var/log/zypp/history on host hpg33's TW I find glib2 and libglib-2_0 were upgraded today, 24 Sep., 24 Aug., 21 Jul., 28 Jun., 30 Mar., 28 Dec., 29 Oct. On same host's 42.2, an upgrade from 42.1 in June, events were on 27 Oct., 21 Jul. and 24 Jun. It doesn't seem very unusual an event. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 30/10/2016 0:50, Felix Miata wrote:
Carlos E. R. composed on 2016-10-30 23:23 (UTC+0200):
It's totally normal here. I have lots of installations. I try to update most no more often than once every 60 days except to do follow-ups to specific bug reports. This thread represents my first significant problem with zypper cmdline in memory, whether in TW or any of the distribution releases. IOW, the process I use for updating has been working well. Plus it's quite a pleasure to use compared to URPM, DNF and Apt and its derivatives.
Well, maybe you were lucky, but I suffered crashes and heard others having them. You separating the upgrade of zypper itself reduces the danger. -- Saludos/Cheers, Carlos E.R. (Minas-Morgul - W10) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Carlos E. R. -
Felix Miata -
Werner Flamme -
Yamaban