Can I transfer a 42.3 aarch64 environment to a Leap 15.0 aarch64 clean install on Raspberry?

English Install/Boot/Login
1

We’re often advised to do a clean installation of a major new OS version rather than try to do an upgrade over an existing one. Makes sense to me to do so.

But what if I have accounts, projects, and applications that I built up over a year or more on the old system? Is there a systematic way of moving that “stuff” from an old drive to a newly-installed OS?

A few months ago, after having had trouble with an upgrade over an old version of Raspbian, I did a clean install on a new drive and then transferred the old environment to the new – successfully – following the guidelines here: https://www.raspberrypi.org/forums/viewtopic.php?p=117665
Accounts, passwords, user files, etc. all moved successfully.

I’ve done a couple of clean installs of Leap 15.0 aarch64 on Raspberry Pi 3B (and B+) in the last day or so, and I hoped that I could move my 42.3 environment to one of those installs. I tried the following (UNSUCCESSFULLY – this is not a how-to, it’s a how-to-screw-it-up! lol!):

  1. dd a fresh install of Leap 15.0 onto a µSD drive following openSUSE guidelines
  2. Boot that 15.0 and do “zypper dup” (which “reinstalls” openSUSE Leap 15.0, but mostly I wanted to make sure I had everything updated on that new install)
  3. Reboot that 15.0 install and verify that the new 15.0 install boots properly, connects to the network, supports ssh in, etc.
  4. Power off the Pi; insert the older 42.3 working µSD; reboot into 42.3; “zypper up” to make sure all is up to date; reboot into that up-to-date 42.3 environment
  5. Insert the 15.0 µSD into a USB adapter and insert it into a USB slot on that running instance of 42.3
  6. Mount the “/” partition of that 15.0 install (now seen as /dev/sda2) as “/mnt/tgt”
  7. Execute the following command, adapted from the Raspbian example cited above:
Pi-6:/mnt # rsync -av \
> --exclude="/proc/*" \
> --exclude="/lost+found/*" \
> --exclude="/dev/*" \
> --exclude="/mnt/*" \
> --exclude="/media/*"  \
> --exclude="/sys/*" \
> --exclude="/tmp/*" \
> / /mnt/tgt
  1. poweroff, remove the 42.3 µSD, insert the 15.0 install with transferred 42.3 environment into the µSD slot, and reboot
  2. On boot, openSUSE splash screen comes up and offers a choice of 42.3 or 15.0, but neither one succeeds in booting – they both result in a black screen and no further information

So I’m guessing that I missed a few directories in that list of excludes, and some things got copied over that I really didn’t want.

Has anyone got a recipe for doing this transfer (old Leap working environment to new Leap install)?

Or can anyone suggest other things I ought to include in that “exclude” list that would make this successful?

I still have my 42.3 working drive, and I’m dd’ing a new install of 15.0 as I write, so I’m ready to give it another try if I get some ideas.

Thanks for any advice you can offer.

2

Hi
But why not just add the leap 15.0 repository and dup like a normal openSUSE system?


zypper -ar -f -g -n "Leap_15.0-oss" https://download.opensuse.org/ports/aarch64/distribution/leap/15.0/repo/oss/ Leap_15.0-oss
zypper ref
zypper -vvv dup --from Leap_15.0-oss

Any self compiled stuff will likely need rebuilding anyway (you should use OBS and rpm) for newer libraries etc.

You might also want to look at where files are, there are changes in where things exist, eg sysconfig templates, this also applies to some ~/ file locations.

Then there are the OBS tools to build your own images :wink:

3

Hi, Malcolm!

The usual advice I see for major OS version changes is “do a clean install”. In fact, I usually do try to update over the old version: some times it works, but just as often it fails. When it fails, it usually results in the loss of that original working environment. In this case, I didn’t want to lose what I had, and I didn’t want to try to rebuild it all, so I thought I’d try this approach. Didn’t work, but it was worth a try. :sarcastic:

However, having tried unsuccessfully to transfer, I’ll try this. Very much appreciated, since I wouldn’t have known quite what to do at the outset. So this is my next step.

Wish I’d thought this through a little more carefully before blowing away the 42.3 installation on my SSD with a fresh install! :wink:

Good points … I did notice some changes in locations as I was browsing afterward, and that couldn’t have worked right in the first place. Good learning experience, though. lol!

I’ll follow up with the result of my in-place upgrade attempt.

David

4

Good Morning, Malcolm (yes, in Bozeman again),

I thought I should issue a caution for any others following this thread: The update to 15.0, installed over the 42.3 environment, fails to boot. Comes up with the big rainbow square on the screen right away. This may be a problem I caused by things I’ve done in the past in configuring that 42.3 installation, but if you’re working from a moderate-sized µSD, I’d advise using dd to make an image copy of it before attempting the in-place upgrade to 15.0 (advice I thought of after I’d already created a non-booting µSD lol!).

I used your code, Malcolm, in the posting above (but note that the first zypper should be “zypper ar …” rather than “zypper -ar”). It worked very smoothly. It downloaded 2269 packages, about 1GB, and ran through them without incident EXCEPT that at the start there were a number of Ruby-related packages for it complained about being unable to load packages they depended on – I told it to uninstall those. I think those were related to a project I looked at last year, but I otherwise don’t use Ruby.

Otherwise, downloads and installs went without errors. I’ve mounted the drive on a running new 15.0 install and looked at the logs, and I see no signs of problems being reported.

I’m thinking that I should run through the process I documented last year of doing a chroot to the root of that upgraded drive, from this working 15.0, check the grub config, and rebuild the image. I left my notebooks in VT, but I think there may be enough detail in my posting last year to reproduce the process.

Any other suggestions?

5

Hi
I’m confused (That’s easy done :wink: ), so it did upgrade and boot, or the rainbow screen and doesn’t boot?

I tried the openSUSE Leap 15.0 JeOS image, it boots, but no working serial, just ssh…

The only suggestion I have is consider changing your workflow, as in consider OBS/Studio Express?

I always do fresh installs, it’s so much quicker, then I have scripted out specific user stuff and root configs, the rest I build as rpms.

I’ve pretty much converted to Tumbleweed these days (One RPI3 and a Laptop) for all my building/testing. Day to day stuff is on SLES/SLED, laptop(s) and RPI’s.

Building images (SLE examples links follow) is pretty straight forward, then if you had stuff for compiling could build as rpm’s and add as required?

6

I booted 42.3 on the RPi-3B; did the upgrade using the script you provided, with no complaints and reporting success; I rebooted with the µSD still in the MMC slot and it came up with the rainbow. Power-cycled just to be sure, and it still comes up to the rainbow and stops. No messages. I’m pretty sure it thinks it can’t find a boot image. That’s why I think if I went back through the process, from a working 15.0 installation, I might be able to resurrect it.

Interesting. A 15.0 XFCE new install boots and seems to work just fine on Pi-3B (but I don’t use the serial port), with both eth0 and wlan0 working fine; ssh in and out; Logitech wireless kbd and HDMI display as console working; etc. But on Pi-3B+, wlan0 works (and at high speed!) but eth0 is reported alive but doesn’t get an IP (haven’t tried static assignment). And a 15.0 new install on 3B+ only stays up for a little while … either a reported bus error and screens freeze, or the screen just goes black. So 3B+ implementation needs a little more work, but it’s close.

So there are still some potholes in the road, but it basically works well – and surprisingly smoothly – as a new install.

Do you have a pointer to what I would do? I’ve seen OBS references but don’t know anything about it. I’ve seen warnings about mixing up repositories and so have tried to avoid getting myself into (more) trouble.

Well, you’re much better organized than I am. I do fresh installs, but then I have to reconstruct exactly what I did to get the old system adjusted the way I want it (panel applets, UID/GID assignments, etc.). I was hoping that the update over the old system would work and spare me that: instead it just introduced a different kind of headache.

I had stopped working on 42.3 and switched my routine work to Tumbleweed because I found TW so much more tunable to my preferences. But I wanted to run one of the SUSEs from a Pi-3B+/USB3/SSD system. Raspbian running on that combination is really smooth, and I wanted an aarch64 environment running like that. Hence the attempt to convert 42.3–>15.0. I think I’d have been better off waiting for TW to get there!

Thanks for the links: I’ll go give them a look – anything from Alex is usually worth studying carefully.

I’ve rather backed off SLES in favor of TW first, or Leap. But those links may help me set up a more systematic approach to reconstructing my working environment on top of a clean new install, which is likely to be a more stable approach in the long term.

I’ll let you know if I figure my way through my current conundrum.

7

On Fri 08 Jun 2018 07:56:03 PM CDT, hdtodd wrote:

malcolmlewis;2868851 Wrote:
> The only suggestion I have is consider changing your workflow, as in
> consider OBS/Studio Express?

Do you have a pointer to what I would do? I’ve seen OBS references but
don’t know anything about it. I’ve seen warnings about mixing up
repositories and so have tried to avoid getting myself into (more)
trouble.

Hi
Well it all depends on what your building from source?
First off you need an account…

Down at the bottom of the page are links to documentation etc… but
there are also Mailing Lists and IRC channels…

On Fri 08 Jun 2018 07:56:03 PM CDT, hdtodd wrote:

malcolmlewis;2868851
Wrote:
> I always do fresh installs, it’s so much quicker, then I have scripted
> out specific user stuff and root configs, the rest I build as rpms.

Well, you’re much better organized than I am. I do fresh installs, but
then I have to reconstruct exactly what I did to get the old system
adjusted the way I want it (panel applets, UID/GID assignments, etc.).
I was hoping that the update over the old system would work and spare me
that: instead it just introduced a different kind of headache.

So I’m guessing XFCE must save it’s changes somewhere in your user
directory?

Maybe a read here may clarify;
https://forum.xfce.org/viewtopic.php?id=9133

I have a /data directory and just use softlinks where required. Here is
a sample of my user configuration script;
http://paste.opensuse.org/368a9fc6

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-23-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

8

Good Morning, Malcolm,
… and, as always, thanks for your helpful insights.

I did look at Alex’s documentation about OBS and decided that that was overkill for what I wanted to accomplish. I really want to run on standard distributions, but I want the ability to migrate to new releases by doing clean installs and then migrating my working environment. I think you hit on those points below.

Yes, that was very helpful! I’m going to see if I can migrate my working environment from one of my older (now non-booting) 42.3 installs to a clean 15.0 install using the documentation there.

And this was particularly helpful. It’s an approach I hadn’t considered, but I think it would be worth my time to craft something like this for my systems. This is an issue that isn’t going away … as I tailor an environment to my own tastes, I risk losing all that when the next major OS version is inevitably released. A systematic approach to preparing for that would be smart (see, I told you that you were more organized!).

For now, I’m giving up on using either Leap 15 or TW (currently 4.16.6) on the Pi-3B+. The network drivers, in particular, just aren’t ready to work with wicked, it seems, and there appears to be some other issue causing “bus error” conditions on Leap (which at this point is otherwise a more promising candidate than TW).

So I got myself into this mess for what appears now to have been no good reason – can’t run on 3B+ yet anyway!

But I do have Leap 15.0 and TW running nicely on 3B, and I can switch to 3B+ in about 4 minutes when major updates are available. So I’ll keep the OSes up to date on 3B and occasionally try them out on 3B+ with major updates.

Again, thanks for all your help and ideas. Very much appreciated!

9

I’m with Malcolm here. Using OBS allows you to have your own apps rebuilt before upgrading and see if they will compile. The learning curve is mainly in the beginning. The rest is adding a repository to your home project, sometimes some minor changes to a spec file and that’s it.