"zypper dup" wants to downgrade 25 pkgs on a new Leap 15 install

English Install/Boot/Login
1

I did a clean install of Leap 15.0, 2018.06.06 release, on a Raspberry Pi 3B+ (again) yesterday, then did a “zypper dup” and let it reinstall “openSUSE Leap 15.0”, which cured the networking problems. I find it to be a stable and reliable system, with only a few things that don’t seem to be working yet (Firefox, for example; but Chromium is just fine). I’m on

4.12.14-lp150.11-default #1 SMP Fri May 11 08:28:30 UTC 2018 (a9fee09) aarch64 aarch64 aarch64 GNU/Linux

now.

I routinely check to see if there’s anything new, particularly on a newly-installed system where there might be major new updates, so I just did a “zypper dup” and zypper says

The following 25 packages are going to be downgraded:  autoyast2-installation exo-branding-openSUSE libgarcon-branding-openSUSE
  libstorage-ng-lang libxfce4ui-branding-openSUSE midori-branding-openSUSE
  openSUSE-xfce-icon-theme psmisc-lang python3-bind snapper-zypp-plugin
  systemd-bash-completion thunar-volman-branding-openSUSE timezone-java
  util-linux-lang xdg-utils xfce4-notifyd-branding-openSUSE
  xfce4-panel-branding-openSUSE xfce4-power-manager-branding-openSUSE
  xfce4-session-branding-openSUSE xfce4-settings-branding-openSUSE
  xfdesktop-branding-openSUSE xfwm4-branding-openSUSE yast2-installation
  yast2-nfs-client yast2-proxy


25 packages to downgrade.
Overall download size: 3.1 MiB. Already cached: 0 B. After the operation, 22.2
KiB will be freed.

That was a surprise. I see that it’s not upgrading anything, just downgrading, and some of those I think I use. It didn’t say “remove”, just “downgrade”, but I’m uncertain what that means since they’re not being replaced. “zypper up” says “nothing to do”.

Could anyone clarify what it’s preparing to do? I said “n” for now 'til I figure it out.

2

Hi
If you run with some verbosity (I use three v’s), I suspect it’s switching from the update repo to the install repo…


zypper -vvv dup

Only Tumbleweed needs zypper dup, all others just a zypper up, since it doesn’t switch…

3

Thanks for the “-vvv” reminder, Malcolm. I tried it and here are the first three responses:

  
Checking whether to refresh metadata for openSUSE-Ports-Leap-15.0-repo-oss
Retrieving: http://download.opensuse.org/ports/aarch64/distribution/leap/1[done]
...
  autoyast2-installation                   4.0.55-lp150.2.3.1 -> 4.0.53-lp150.1.1      noarch
    openSUSE-Ports-Leap-15.0-repo-oss  openSUSE
  exo-branding-openSUSE                
    4.12.0-lp150.5.3.1 -> 4.12.0-lp150.4.3      noarch
    openSUSE-Ports-Leap-15.0-repo-oss  openSUSE
  libgarcon-branding-openSUSE          
    4.12.0-lp150.5.3.1 -> 4.12.0-lp150.4.3      noarch
    openSUSE-Ports-Leap-15.0-repo-oss  openSUSE

I think you’re right about what it’s preparing to do. It doesn’t seem to say that it’s switching from the update to the install repo, but then I couldn’t see the update repo referenced anyway. “zypper lr” gives just one entry

1 | openSUSE-Ports-Leap-15.0-repo-oss | openSUSE-Ports-Leap-15.0-repo-oss | Yes     | (r ) Yes  | Yes

, and I haven’t changed the repository list since I initially installed.

So here’s how I feel stuck: I needed to do the “zypper dup” after the initial install to get the OS “reinstalled”, which fixed the networking problem even though there was no version change in the updated OS. I knew that I needed “zypper dup” for TW and (usually) just “zypper up” for Leap, but in this case I needed the dup to get things working.

The system seems stable and quite functional. But, for example, Firefox and Thunderbird crash on startup. Haven’t tried everything so there may be others. Will “zypper up” fix them when new updates are available for them, or do I need “zypper dup”; and if I need “zypper dup”, then it looks like I will downgrade (and maybe break) some of the other things I use.

Is there some way I can specify that I want to use the update repository for “zypper dup” … oh, wait, it must already do that since it did after the initial install. So why is it wanting to revert to the install repo now? How can I disable the install repo and just use the update repo now?

Coming to you via Chromium on my bright shiny new Leap 15.0 install on Raspberry Pi-3B+. :wink:

4

Hi
I believe since the initial install is an extracted image, is rolling back to this stage (@system), hence only a zypper up is needed to update. Now if you add --no-allow-vendor-change to your dup what happens… add another v to se even more verbosity.

5

Shouldn’t “zypper dup” upgrade using all the configured repositories?

In any case,
I don’t know that a proper understanding of the situation can start without knowing exactly what repositories are configured.
And, I wouldn’t exclude the possibility that someone may have intentionally downgraded some packages after finding the versions in the original image might have issues. In general, I assume that “zypper dup” should always prefer latest available packages no matter where it might be from so I wonder if the downgrading might be intentional. As Malcom says though, you should run “zypper up” if for no other reason than compare with “zypper dup”

So, Pls post your

zypper lr -d

TSU

6

Hi
It’s a pre-loaded image install on the RPI’s, and only one repository after it’s up and running, the ports oss one.

7

Malcolm, added another v and --no-allow… and got the same result: wants to downgrade 25 pkgs.

What’s confusing me is that I would have thought that a “zypper dup” would have pulled from an update repository, and if there had been updates to the packages (which it appears there have been for these 25 at least), a subsequent “zypper dup” would have referenced the same update repository and not done anything. I don’t understand why doing the same thing would result in a different action (regressing) if there are no changes to the update repository – and if there have been changes, why would the update want to regress the version levels?

Something odd going on here. I surely “pay no attention to the man behind the curtain”, so there may have been changes to the update database that I wouldn’t have known about (and shouldn’t have), but why would the version levels regress when I’m just doing the same operation to make sure there are no NEW updates I’m missing?

8

Good Evening, Tsu,

“zypper lr -d” gives

1 | openSUSE-Ports-Leap-15.0-repo-oss | openSUSE-Ports-Leap-15.0-repo-oss | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/ports/aarch64/distribution/leap/15.0/repo/oss/ |

which is the same as zypper -lr.

As I mentioned earlier, “zypper up” says “nothing to do”.

I’m thinking you’re right, that someone regressed some of the packages in the update from the original update configuration, but there’s no communication about it.

As a reminder of the sequence I followed:

  • download the 06.06 distribution; boot; let it resize; all works well except no eth0 and wlan0 is unreliable
  • “zypper dup”, which “reinstalls” (as zypper calls it), but the network now works, so something was actually changed by the update
  • run it for 18 hours, then do a “zypper dup” and get the response that it wants to downgrade 25 packages.
  • During this time, the repository zypper is referencing has not been changed.

So I don’t know how to adapt to this behavior. I really don’t want to regress those packages at this point for fear that would screw something up. But if other package UPDATES really do come out, I think I’ll really need to accept the updates of those and reject the downgrades of these 25.

I’d welcome any other thoughts about how to handle this.

9

That’s expected.
Perhaps the image is built with newer sources/packages than what is available in the ported oss?

Else,
As I speculated perhaps a decision was made to purposefully downgrade. Are all such version changes documented? - I wouldn’t know.

AFAIK packages wouldn’t be downloaded just because they’re part of an image… But then, the few images I’ve built using Kiwi use same sources as online so shouldn’t be inconsistent.

Out of curiosity,
I ran “zypper up” and “zypper dup” against a LEAP 15 and saw something similar but I’d guess for another reason…
That LEAP has a game installed from the Games repo, and “zypper dup” wanted to downgrade it while “zypper up” was silent.
Am speculating in that case it’s an error in the package manifest.
Did not see any recommendations for downgrading otherwise.

TSU

10

Malcolm & Tsu, in particular,

So I had started a different thread about networking problems with Leap 15.0 on RPi-3B+ (which didn’t occur on RPi-3B). jarrodholder and I exchanged info, since he was getting different results than I was, and in particular, was getting 06.06 updates that I wasn’t getting, and those fixed the problem. So I asked what repository he was using (he uses yast2 and I use zypper, but I believe that’s not supposed to make a difference).

Turns out he is using http://download.opensuse.org/ports/update/leap/15.0/oss/

I’m using http://download.opensuse.org/ports/aarch64/distribution/leap/15.0/repo/oss/

When I look at the “update” directory, I see NO overlap with the packages that “zypper dup” wants to downgrade. I take that as an indication that my earlier “zypper dup” did not mysteriously use that update directory as its reference.

However, I DO see that the versions of several of the packages in that update directory are a major or minor version level LATER than what I have installed. For example, my installed firefox is “Mozilla Firefox 59.0.2” and that update directory offers MozillaFirefox-60.0.2-lp150.3.6.1.aarch64.rpm. My installed firefox crashes on startup; I’d hope that the update might fix that.

So my question is: should I replace my current repo with the update URI that Jarrod is using, or should I just add it to the list of repos (which is a list of 1 right now), or do neither.

I’m a little confused about how the repo list gets modified from the distribution repo, if it does at all. Does the distribution repo itself get modified as updates become available (which I didn’t think was the case) or do the updates just go into the updates repo – which means I would need to know that, and what the URI is, and how to add the update URI to the zypper repo list, in order to keep my system up to date. That doesn’t seem reasonable for those of us who are pretty novice, but it does seem to be the way it’s working.

Or did I just do something (or fail to do something) after the initial install in order to get this right?

11

I should have said that while Jarrod is using the URI that I cited above, there’s an “aarch64” subdirectory under that one, and I presume that the system is using that subdirectory as its update reference.

I find it odd – and confusing – that the “aarch64” reference is in the middle of the distribution URI but at the end of update URI. I know it’s just the directory structure, but the asymmetry of those makes it hard to “guess” the right URI for updates (which I had tried, unsuccessfully, to do).

12

Hi
Resist the dup urge… :wink:

OK, Have a look through this output;
http://paste.opensuse.org/77e718fd

For releases patch and/or up, dup is for tumbleweed use or upgrading to the next release, eg Leap 15.1, that’s just how zypper is intended to work… unless your switching to a non-standard repo (switch being the operative word) if your just installing a package that doesn’t exist there is no need to dup, just install and zypper will find it and always use that repo for that package.

Now… up, patch and dup both pull in 35 updates, but dup/patch will pull in extra based on the patterns (I have no need for some on JeOS…). The downgrades occur because the ones used on the image where newer, but dup forces a switch, hence the downgrade (may break something).

With respect to the URI’s, aarch64 component is specific to the hardware, the update is generic across all hardware…

I would suggest always using verbosity 3 as is shows additional info on what is/will occur…

So I did the patch update with following output on completion;


......
Executing %posttrans scripts .......................................................................................................................................................[done]
CommitResult  (total 74, done 74, error 0, skipped 0, updateMessages 0)
Warning: One of the installed patches requires a reboot of your machine. Reboot as soon as possible.
Checking for running processes using deleted libraries...
Skip check: Please install package 'lsof' first.

zypper -vvv up
Verbosity: 3
Initializing Target
Checking whether to refresh metadata for openSUSE-Ports-Leap-15.0-repo-oss
Retrieving: http://download.opensuse.org/ports/aarch64/distribution/leap/15.0/repo/oss/repodata/repomd.xml .........................................................................[done]
Retrieving: http://download.opensuse.org/ports/aarch64/distribution/leap/15.0/repo/oss/media.1/media ...............................................................................[done]
Checking whether to refresh metadata for openSUSE-Ports-Leap-15.0-repo-update-oss
Retrieving: http://download.opensuse.org/ports/update/leap/15.0/oss/repodata/repomd.xml ............................................................................................[done]
Loading repository data...
Reading installed packages...
Force resolution: No

Nothing to do.

zypper in -n lsof
systemctl reboot

All is good (well almost no serial connection) via ssh…

13

Your pasted transcript was VERY helpful. Thanks!

I think the key part was to add the update repository with

zypper ar -f -g -n "openSUSE-Ports-Leap-15.0-repo-update-oss"  http://download.opensuse.org/ports/update/leap/15.0/oss/  openSUSE-Ports-Leap-15.0-repo-update-oss

Your explanation of dup vs up confirms my prior understanding of the two. BUT, the reason I did a dup was that after the fresh install, with networking not working, a “zypper up” did nothing but a “zypper dup” did a reinstall and that made the networking function. But also recall that at that time, I only had one entry in the repo list (…-update-oss was not there).

So I would have thought that, as distributed within the initial install, the repo list would include both the original distribution repo and the update repo, so that “zypper up” would automatically pick up the updates to that repo. That seems not to be the case, and that seems to me to be a mistake. Most novices (like me) would not know what URI to add (my guesses were wrong), even if we could figure out how to add it (which I did).

I understood the distinction between zypper dup and up, but in the absence of up doing anything and dup fixing the problem … I chose to fix the problem (for the short term and in the wrong way! lol!).

I’ve just done a “zypper -vvv -t patch”, allowed it to do the downloads and installs of the update packages and patches, and I got the result

...
Executing %posttrans scripts .................................................................................................[done]
CommitResult  (total 91, done 91, error 0, skipped 0, updateMessages 0)
Warning: One of the installed patches requires a reboot of your machine. Reboot as soon as possible.

Did the reboot and it came up successfully :wink: ]; zypper up says

The following 5 packages are going to be upgraded:
  firewall-macros firewalld firewalld-lang libgeotiff2 python3-firewall
5 packages to upgrade.

to which I said “y”. Subsequent “zypper -vvv up” says “nothing to do”. A “zypper -vvv -t patch” then says “nothing to do”. I see that both eth0 and wlan0 are still working, so the patches/updates didn’t break those.

Logging in on the XFCE window on the console, everything seems normal. But now, Firefox and Thunderbird both work! So the update (which listed those among the packages to be updated) really did fix that problem.

Thanks SOOO much for your patience on this, Malcolm. If you have any contact with the folks who do the Pi package, congrats to them on getting a stable package out and updated so quickly … it’s really a lovely implementation, and my Pi-3B+/USB3-SSD combination just hums on Leap 15.0!

Now … back to playing with floating-point parallel processing algorithms in ARM assembly language on the aarch64 system!

David

14

Hi David
All good, do you have a serial cable handy to test? Oh and if you add a --no-recommends it won’t pull in the extras from the update repo…

I have a feeling the update repository wasn’t present with the earlier images, hence it not being added. It should with the later images add it in, but need to test…

15

No, I don’t have a serial cable. There are a few times I could have used one, but not often enough to bother getting one. Sorry I can’t help with the serial testing now that I have this really spiffy Leap 15.0 running :-)]. I presume that you mean testing through the serial port pins, not testing through the USB port. I’ve got enough Pi’s lying around :slight_smile: ] that I could lash a couple together with USB, as I do between Arduinos and Pi’s, but I think that’s not what you’re looking to test, right?

I’ll keep the --no-recommends in mind, too, though I generally haven’t seen any nuisance from those.

I’d have thought that the …update-oss repo URI would be built into the repo list at the time of initial creation of the distribution, along with the distribution repo URI, even if the update repo didn’t exist at the time, so that subsequent "zypper up"s would start picking up the updates as soon as the update repository was created. Just a thought.

16

Hi
Well anything to the Tx and Rx ports that works with minicom as the client… but yes, the serial USB cable is what I use…

No worries I will jump on IRC and see if folks are around…

17

Malcolm,
Well, now I think I may be able to help!

For my weatherstation project (GitHub - hdtodd/WeatherStation: Raspberry Pi / Arduino Weather station and weather probe) I have a Pi-1B talking with an Arduino over a USB connection. For debugging the Arduino, I used minicom from the Pi-1B (Raspbian) to give commands to my data collection program on the Arduino to make sure it worked correctly.

So if the question is: can I see if my Pi-3B+ running Leap 15.0 XFCE will talk to that Arduino, the answer is “yes”. They’re sitting right next to each other. I’ll need to download and configure minicom on Leap, but if that would help, I’ll give it a try.

And if it works, I have spare µSD cards and a downloaded image of JEOS Leap 15.0, so I could try that, too.

I’ll look on IRC.

18

Hi
If you could, just need to add your user to dialout group…

19

Malcolm, We’ve gotten of the tread topic, but I wanted to bring this to closure here as we continue through IRC.

My Arduino code is prepared to accept serial-line input through the USB connection (which also supplies power in this case) and respond to commands from the controlling terminal or remote computer. I’ve got it connected to a RPi-1B for meteorological data collection. For testing the Arduino code, I connected the Arduino to the Pi and used minicom on the Pi to communicate, so I could see what was going on. I’ve got the speed set low (9600) because the Arduino can’t keep up at high speeds.

So I disconnected the Arduino from the Pi-1B, connected it via USB-USB into the Pi-3B+ running Leap 15.0, installed minicom, and was able to communicate with the Arduino using device /dev/ttyACM0 on the Pi (again, at 9600, which the Arudino can process). It did NOT work with minicom using devices ttyS0, ttyS1, or ttyAMA1.

So the good news is that, at least for Leap 15.0, XFCE, on RPi-3B+, serial communication through the USB port works. (I understand from lurchi on IRC that internally, the USB port is wired to the Pi’s serial line, so if that’s right, then serial functions fine.)

The bad news is that when I started minicom on an RPi-3B running TW, and linked the two Pi’s together with USB, and set the minicom parameters to be the same on both systems, I could not get them to see each other. The Pi-3B/TW system didn’t even have a ttyACM0 device. I tried ttyS1 and ttyAMA0 on them as well with no luck. This one’s got me a little puzzled (what, again!?) since the Pi-3B/TW system doesn’t even have the ttyACM0 device.

I did check the /boot/efi/config.txt files of both systems, and they both enable the UART. I also checked the /etc/default/grub file and they both referenced /dev/ttyS1 as consoles, so I’d have expected to see something come out of the pipe as it boots up.

I’ll fiddle with this a bit more to see if I can get them to work Pi-to-Pi. Meanwhile, if you see me doing something in all that that just doesn’t make sense, let me know.