Page 1 of 2 12 LastLast
Results 1 to 10 of 20

Thread: Tumbleweed aarch64 on Raspberry Pi-3B: update strategy advice

  1. #1
    Join Date
    Feb 2017
    Location
    Montana, USA & Vermont, USA
    Posts
    134

    Default Tumbleweed aarch64 on Raspberry Pi-3B: update strategy advice

    I've been running Leap 42.3 on a Raspberry Pi-3B and have found it to be stable and reliable. I boot off a USB/SSD drive and it performs fairly well (aside from a flaky USB/SATA interface device).

    I had run Tumbleweed last year in a similar way but after an update caused it to stop booting, I switched to Leap.

    After 6-8 months lapse, I thought TW on RPi might be more stable and so downloaded and installed openSUSE-Tumbleweed-ARM-XFCE-raspberrypi3.aarch64-2018.02.02-Build1.2.raw.xz . It worked like a charm: booted from USB, responsive system, working WiFi, and stable GUI (with just limited testing). Then I did my usual process of updating software. Bad mistake. "zypper up" wanted to do a "dup" and install the 2018.02.18 version of the kernel (plus lots of other updates). So I did a "zypper dup", and the update installs failed in the dracut step -- system had misplaced /proc and friends. Couldn't get any apps to instantiate, so rebooted and it failed to load anything. Recreated the USB/microSD from the link above, this time did a "zypper up" (which omitted about 13 packages out of 600+ but DID install the 2018.02.18 kernel update). Got the same result.

    Now, I don't think there's anything in TW that I desperately need, so I'm OK working with aarch64 Leap 42.3. But I'm now thinking that I'm just approaching this wrong. While I understand that TW is pretty rough around the edges relative to Leap, I thought that updates would make incremental improvements and that if the base installation was working, updates would only get better.

    But now I'm thinking I got it exactly wrong. I see that the distribution repository is still 2018.02.02, not the 2018.02.18 version that zypper installs on update.

    So is it the case that the update installed by "zypper dup" is the result of whatever the latest build created (not tested; working or not), and only when one really seems after testing to be stable is it put into the repository for downloading? That is, I should wait until the version in the repository is updated before I do a "zypper up" or "zypper dup"?

    I don't see much Raspberry Pi stuff here ... am I in the wrong place?

    Thanks for any advice you can offer. I'm installing the 2018.02.02 TW aarch64 version (link above) and will leave it without updating for a while to get a feeling for its performance and stability.

  2. #2

    Default Re: Tumbleweed aarch64 on Raspberry Pi-3B: update strategy advice

    Hi! My experience with TW on Raspi 2 and 3: Don't update. If you have a running system, use it. Will break after 1-2-3 updates, so don't update. Lately after only 1.5 years my last RAID1 NAS with Raspi 2 and TW broke (SD-card went into read-only). Never had something like that with Raspbian (running on about 10 raspi 1, 2 and 3). I use the TW on raspi 3 only for my Wireshark machines described in other threads, but recently the networking broke, so that an IPv6 address is added to the network bridge, causing IPv6 chatter. So basically: TW on raspi is broken for me...
    Kind regards

    raspu

  3. #3
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    32,320
    Blog Entries
    15

    Default Re: Tumbleweed aarch64 on Raspberry Pi-3B: update strategy advice

    On Sat 24 Feb 2018 02:46:02 AM CST, hdtodd wrote:

    I've been running Leap 42.3 on a Raspberry Pi-3B and have found it to be
    stable and reliable. I boot off a USB/SSD drive and it performs fairly
    well (aside from a flaky USB/SATA interface device).

    I had run Tumbleweed last year in a similar way but after an update
    caused it to stop booting, I switched to Leap.

    After 6-8 months lapse, I thought TW on RPi might be more stable and so
    downloaded and installed
    'openSUSE-Tumbleweed-ARM-XFCE-raspberrypi3.aarch64-2018.02.02-Build1.2.raw.xz'
    (http://tinyurl.com/ybh6p5ov) . It worked like a charm: booted from
    USB, responsive system, working WiFi, and stable GUI (with just limited
    testing). Then I did my usual process of updating software. Bad
    mistake. "zypper up" wanted to do a "dup" and install the 2018.02.18
    version of the kernel (plus lots of other updates). So I did a "zypper
    dup", and the update installs failed in the dracut step -- system had
    misplaced /proc and friends. Couldn't get any apps to instantiate, so
    rebooted and it failed to load anything. Recreated the USB/microSD from
    the link above, this time did a "zypper up" (which omitted about 13
    packages out of 600+ but DID install the 2018.02.18 kernel update). Got
    the same result.

    Now, I don't think there's anything in TW that I desperately need, so
    I'm OK working with aarch64 Leap 42.3. But I'm now thinking that I'm
    just approaching this wrong. While I understand that TW is pretty rough
    around the edges relative to Leap, I thought that updates would make
    incremental improvements and that if the base installation was working,
    updates would only get better.

    But now I'm thinking I got it exactly wrong. I see that the
    distribution repository is still 2018.02.02, not the 2018.02.18 version
    that zypper installs on update.

    So is it the case that the update installed by "zypper dup" is the
    result of whatever the latest build created (not tested; working or
    not), and only when one really seems after testing to be stable is it
    put into the repository for downloading? That is, I should wait until
    the version in the repository is updated before I do a "zypper up" or
    "zypper dup"?

    I don't see much Raspberry Pi stuff here ... am I in the wrong place?

    Thanks for any advice you can offer. I'm installing the 2018.02.02 TW
    aarch64 version (link above) and will leave it without updating for a
    while to get a feeling for its performance and stability.


    Hi
    Well no issues here to date with JeOS via zypper dup, (well just make
    sure you update /etc/default/grub to point at ttyS1 for the serial
    console, it's fixed for initial install).

    Code:
    cat /etc/os-release
    
    NAME="openSUSE Tumbleweed"
    # VERSION="20180218 "
    ID=opensuse
    ID_LIKE="suse"
    VERSION_ID="20180218"
    PRETTY_NAME="openSUSE Tumbleweed"
    ANSI_COLOR="0;32"
    CPE_NAME="cpe:/o:opensuse:tumbleweed:20180218"
    BUG_REPORT_URL="https://bugs.opensuse.org"
    HOME_URL="https://www.opensuse.org/"
    
    uname -a
    
    Linux statler3 4.14.15-2-default #1 SMP Mon Jan 29 08:15:43 UTC 2018 (9a6fca5) aarch64 aarch64 aarch64 GNU/Linux
    --
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    openSUSE Leap 42.3|GNOME 3.20.2|4.4.114-42-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!


  4. #4
    Join Date
    Feb 2017
    Location
    Montana, USA & Vermont, USA
    Posts
    134

    Default Re: Tumbleweed aarch64 on Raspberry Pi-3B: update strategy advice

    Quote Originally Posted by malcolmlewis View Post
    Hi
    Well no issues here to date with JeOS via zypper dup, (well just make
    sure you update /etc/default/grub to point at ttyS1 for the serial
    console, it's fixed for initial install).
    Hi, Malcolm!

    Well, after the first failed update, I tried to figure out how to go in and check /etc/default/grub, /etc/dracut.conf, and /etc/dracut.conf.d/raspberrypi_modules.conf , but I don't get the chance. The install loses /proc (at least ... not sure what else is missing) and no programs will instantiate, so I can't go check/edit things.

    I recalled that you use JeOS reliably, and for what I'm doing the CLI would be just fine. But I really rather like the XFCE interface and would like to use it if I could.

    Are you suggesting that I need to edit /etc/default/grub myself, after the initial install and before trying the update? It's not fixed by the update?

    So I've been running the 2018.02.02 version of Tumbleweed -- un-updated install -- of XFCE aarch64 for a couple of days now. This is coming to you from Firefox on that system, in fact. I've installed and run the DEC20 simulator (10's of 1000's of lines of C code) and my chemistry research programs, and they all run fine. Fired up Facebook in Firefox and performance is a bit slow ... probably first-time initing of the system, but I expect graphics to be slow anyway. And some touchiness with dynamic plugin of USB drives into a running system -- tried it once and it crashed, so I haven't tried it again yet.

    But generally an acceptably stable and responsive XFCE system. Except that I can't figure out when I can risk an update! :-)

    So here is my release info. Curious that the 2018.02.02 release and your 2018.02.18 updated version both register the same kernel version. That would seem to be a mistake.
    Code:
    hdtodd@Pi-6:~> cat /etc/os-release
    NAME="openSUSE Tumbleweed"
    # VERSION="20180202 "
    ID=opensuse
    ID_LIKE="suse"
    VERSION_ID="20180202"
    PRETTY_NAME="openSUSE Tumbleweed"
    ANSI_COLOR="0;32"
    CPE_NAME="cpe:/o:opensuse:tumbleweed:20180202"
    BUG_REPORT_URL="https://bugs.opensuse.org"
    HOME_URL="https://www.opensuse.org/"
    hdtodd@Pi-6:~> uname  -a
    Linux Pi-6 4.14.15-2-default #1 SMP Mon Jan 29 08:15:43 UTC 2018 (9a6fca5) aarch64 aarch64 aarch64 GNU/Linux
    and here is my /etc/default/grub file
    Code:
    hdtodd@Pi-6:~> cat /etc/default/grub
    GRUB_DISTRIBUTOR=openSUSE
    GRUB_DEFAULT=0
    GRUB_HIDDEN_TIMEOUT=0
    GRUB_HIDDEN_TIMEOUT_QUIET=true
    GRUB_TIMEOUT=10
    GRUB_CMDLINE_LINUX=" root=/dev/disk/by-id/usb-Lexar_uSD_UHS2_RDR_GLI888888888-0:0-part2 disk=/dev/disk/by-id/usb-Lexar_uSD_UHS2_RDR_GLI888888888-0:0 resume=/dev/disk/by-id/usb-Lexar_uSD_UHS2_RDR_GLI888888888-0:0-part3 quiet splash=silent plymouth.enable=0  swiotlb=512 cma=300M console=ttyS1,115200n8 console=tty quiet"
    GRUB_TERMINAL=gfxterm
    GRUB_GFXMODE=800x600
    GRUB_GFXPAYLOAD_LINUX=keep
    GRUB_THEME="/boot/grub2/themes/openSUSE/theme.txt"
    GRUB_BACKGROUND="/boot/grub2/themes/openSUSE/background.png"
    See anything obvious I would need to fix before doing the "zypper dup"? I think console is set the way you're suggesting it needs to be, so I'm not sure what else I could do there (I don't use the serial port, as you may recall).

    Good chatting with you again!

    David

  5. #5
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    32,320
    Blog Entries
    15

    Default Re: Tumbleweed aarch64 on Raspberry Pi-3B: update strategy advice

    Hi
    Well the cma=300 is only for initial boot/install/expand, so looks like something may be up there. It's almost like it's not updated....

    Mine is;
    Code:
     cat /etc/default/grub
    GRUB_DISTRIBUTOR=
    GRUB_DEFAULT=0
    GRUB_HIDDEN_TIMEOUT=0
    GRUB_HIDDEN_TIMEOUT_QUIET=true
    GRUB_TIMEOUT=0
    GRUB_CMDLINE_LINUX=" root=/dev/sda2 disk=/dev/sda quiet splash=silent plymouth.enable=0 swiotlb=512,force cma=384M console=tty0 console=ttyS1,115200n8"
    GRUB_TERMINAL=gfxterm
    GRUB_GFXMODE=800x600
    GRUB_GFXPAYLOAD_LINUX=keep
    GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
    GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png
    GRUB_DISABLE_OS_PROBER="true"
    So, let me grab the xfce image and pop onto a USB device and see what I get....

    Kernel is fine, I think it came through at an earlier update.
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  6. #6
    Join Date
    Feb 2017
    Location
    Montana, USA & Vermont, USA
    Posts
    134

    Default Re: Tumbleweed aarch64 on Raspberry Pi-3B: update strategy advice

    Quote Originally Posted by malcolmlewis View Post
    Hi
    Well the cma=300 is only for initial boot/install/expand, so looks like something may be up there. It's almost like it's not updated....
    "... it's not updated": I'm running the repository download, 2018.02.02, not the updated version from 2018.02.18. Was the initial install supposed to update that grub cma parameter to 384 as it was resizing partitions and doing its initial execution of dracut? I could easily edit the grub file, rerun the grub-mkconfig and mkinitfs, and then "zypper dup", but if it hangs again I'd need to start from scratch since I can't figure out how to recover it.
    So, let me grab the xfce image and pop onto a USB device and see what I get....

    Kernel is fine, I think it came through at an earlier update.
    Thanks for that ... I know that you don't normally run with a GUI interface so this is a bit of a sidetrack for you.

    Again, my sequence was pretty simple:
    1. Install with dd from the XFCE .xz file to a USB-mounted microSD card on the RPi-3 (running a Leap 42.3 host)
    2. Poweroff, remove the original boot medium (Leap 42.3) USB drive from the RPi-3, and reboot from that USB/microSD: system resizes and eventually brings up the GUI login screen
    3. Log as root, connected to eth0, and "zypper dup" to update to 2018.02.18
    4. Update fails at the dracut step; /proc (and possibly others lost); can't instantiate programs


    If I could figure out how to repair the dracut step, I think the reboot would succeed. But as it is, reboots don't load anything.

  7. #7
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    32,320
    Blog Entries
    15

    Default Re: Tumbleweed aarch64 on Raspberry Pi-3B: update strategy advice

    Quote Originally Posted by hdtodd View Post
    "... it's not updated": I'm running the repository download, 2018.02.02, not the updated version from 2018.02.18. Was the initial install supposed to update that grub cma parameter to 384 as it was resizing partitions and doing its initial execution of dracut? I could easily edit the grub file, rerun the grub-mkconfig and mkinitfs, and then "zypper dup", but if it hangs again I'd need to start from scratch since I can't figure out how to recover it.


    Thanks for that ... I know that you don't normally run with a GUI interface so this is a bit of a sidetrack for you.

    Again, my sequence was pretty simple:
    1. Install with dd from the XFCE .xz file to a USB-mounted microSD card on the RPi-3 (running a Leap 42.3 host)
    2. Poweroff, remove the original boot medium (Leap 42.3) USB drive from the RPi-3, and reboot from that USB/microSD: system resizes and eventually brings up the GUI login screen
    3. Log as root, connected to eth0, and "zypper dup" to update to 2018.02.18
    4. Update fails at the dracut step; /proc (and possibly others lost); can't instantiate programs


    If I could figure out how to repair the dracut step, I think the reboot would succeed. But as it is, reboots don't load anything.
    Hi
    I'm just running an update from a fresh XFCE install, however I updated grub cma=384M first;
    Code:
    zypper -vvv dup
    ....
    ....
    The following product is going to be upgraded:
      openSUSE Tumbleweed
        20180202-0 -> 20180218-0  aarch64  openSUSE-Ports-Tumbleweed-repo-oss
        openSUSE
    
    1273 packages to upgrade, 645 new, 2 to remove.
    Overall download size: 922.0 MiB. Already cached: 0 B. After the operation,
    additional 1.4 GiB will be used.
    It's (360 of 1918) installing packages at present..... lets see if get the same error...
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    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. #8
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    32,320
    Blog Entries
    15

    Default Re: Tumbleweed aarch64 on Raspberry Pi-3B: update strategy advice

    Hi
    So all good here......cma=384M was the only change...

    Code:
    cat /etc/default/grub
    
    GRUB_DISTRIBUTOR=openSUSE
    GRUB_DEFAULT=0
    GRUB_HIDDEN_TIMEOUT=0
    GRUB_HIDDEN_TIMEOUT_QUIET=true
    GRUB_TIMEOUT=10
    GRUB_CMDLINE_LINUX=" root=/dev/disk/by-id/usb-_Patriot_Memory_07017286C1282830-00
    :0-part2 disk=/dev/disk/by-id/usb-_Patriot_Memory_07017286C1282830-0:0 resume=/dd
    ev/disk/by-id/usb-_Patriot_Memory_07017286C1282830-0:0-part3 quiet splash=silentt
     plymouth.enable=0  swiotlb=512 cma=384M console=ttyS1,115200n8 console=tty quiee
    t"
    GRUB_TERMINAL=gfxterm
    GRUB_GFXMODE=800x600
    GRUB_GFXPAYLOAD_LINUX=keep
    GRUB_THEME="/boot/grub2/themes/openSUSE/theme.txt"
    GRUB_BACKGROUND="/boot/grub2/themes/openSUSE/background.png"
    
    grub2-mkconfig -o /boot/grub2/grub.cfg
    
    uname -a
    Linux localhost.localdomain 4.14.15-2-default #1 SMP Mon Jan 29 08:15:43 UTC 2018 (9a6fca5) aarch64 aarch64 aarch64 GNU/Linux
    
    zypper -vvv dup
    ....
    ....
    The following product is going to be upgraded:
      openSUSE Tumbleweed
        20180202-0 -> 20180218-0  aarch64  openSUSE-Ports-Tumbleweed-repo-oss
        openSUSE
    
    1273 packages to upgrade, 645 new, 2 to remove.
    Overall download size: 922.0 MiB. Already cached: 0 B. After the operation,
    additional 1.4 GiB will be used.
    ....
    ....
    
    Output of coreutils-8.29-1.4.aarch64.rpm %posttrans script:
        Creating initrd: /boot/initrd-4.14.15-2-default
        dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.14.15-2-default 4.14.15-2-default
        dracut: *** Including module: bash ***
        dracut: *** Including module: systemd ***
        dracut: *** Including module: systemd-initrd ***
        dracut: *** Including module: i18n ***
        dracut: No KEYMAP configured.
        dracut: *** Including module: drm ***
        dracut: *** Including module: plymouth ***
        dracut: *** Including module: kernel-modules ***
        dracut: *** Including module: resume ***
        dracut: *** Including module: rootfs-block ***
        dracut: *** Including module: terminfo ***
        dracut: *** Including module: udev-rules ***
        dracut: Skipping udev rule: 40-redhat.rules
        dracut: Skipping udev rule: 50-firmware.rules
        dracut: Skipping udev rule: 50-udev.rules
        dracut: Skipping udev rule: 91-permissions.rules
        dracut: Skipping udev rule: 80-drivers-modprobe.rules
        dracut: *** Including module: dracut-systemd ***
        dracut: *** Including module: haveged ***
        dracut: *** Including module: usrmount ***
        dracut: *** Including module: base ***
        dracut: *** Including module: fs-lib ***
        dracut: *** Including module: shutdown ***
        dracut: *** Including module: suse ***
        dracut: *** Including modules done ***
        dracut: *** Installing kernel module dependencies and firmware ***
        dracut: *** Installing kernel module dependencies and firmware done ***
        dracut: *** Resolving executable dependencies ***
        dracut: *** Resolving executable dependencies done***
        dracut: *** Hardlinking files ***
        dracut: *** Hardlinking files done ***
        dracut: *** Stripping files ***
        dracut: *** Stripping files done ***
        dracut: *** Store current command line parameters ***
        dracut: Stored kernel commandline:
        dracut:  resume=UUID=8b1321ca-daf8-44aa-b94a-b85b5dcc6eee
        dracut:  root=UUID=5ae8a03f-9b30-4127-848d-9d5b6c1329d2 rootfstype=ext4 rootflags=rw,noatime,nobarrier,data=ordered
        dracut: *** Creating image file '/boot/initrd-4.14.15-2-default' ***
        dracut: *** Creating initramfs image file '/boot/initrd-4.14.15-2-default' done ***
    
    Output of dmraid-1.0.0.rc16-40.3.aarch64.rpm %posttrans script:
    
    CommitResult  (total 1918, done 1918, error 0, skipped 0, updateMessages 0)
    
    systemctl reboot
    
    cat /etc/os-release
    
    NAME="openSUSE Tumbleweed"
    # VERSION="20180218 "
    ID=opensuse
    ID_LIKE="suse"
    VERSION_ID="20180218"
    PRETTY_NAME="openSUSE Tumbleweed"
    ANSI_COLOR="0;32"
    CPE_NAME="cpe:/o:opensuse:tumbleweed:20180218"
    BUG_REPORT_URL="https://bugs.opensuse.org"
    HOME_URL="https://www.opensuse.org/"
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  9. #9
    Join Date
    Feb 2017
    Location
    Montana, USA & Vermont, USA
    Posts
    134

    Default Re: Tumbleweed aarch64 on Raspberry Pi-3B: update strategy advice

    Quote Originally Posted by malcolmlewis View Post
    Hi
    So all good here......cma=384M was the only change...
    Seeing your note, I made the change and tried the "zypper -vvv dup" as you did, but mine failed in the same way it did before! Lost at least /proc somewhere along the way. While the succeeding installs appear to have been made successfully, a number of them had messages like this
    (1003/1892) Installing: openslp-2.0.0-12.3.aarch64 [..............done]
    (1004/1892) Installing: open-iscsi-2.0.876-40.1.aarch64 [............done]
    Additional rpm output:
    Failed to connect to bus: No such file or directory
    Created symlink /etc/systemd/system/sockets.target.wants/iscsid.socket -> /usr/lib/systemd/system/iscsid.socket.
    Created symlink /etc/systemd/system/remote-fs.target.wants/iscsi.service -> /usr/lib/systemd/system/iscsi.service.


    (1005/1892) Installing: libwinpr2-2.0.0~rc1-2.4.aarch64 [...............done]
    This was the FIRST "Failed to connect to bus message", occurring right after the open-iscsi install, but there were a number that occurred subsequently.

    This time I was a little smarter and did the zypper command with a tee that logged the stream to a file, and I stayed logged in to my Pi from my Mac, so I have pretty much all of the log from the install stream. The tail end of the install looks like this ...

    (1892/1892) Installing: patterns-xfce-xfce_office-20171113-1.3.aarch64 [........done]
    Output of coreutils-8.29-1.4.aarch64.rpm %posttrans script:
    Creating initrd: /boot/initrd-4.14.15-2-default
    dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.14.15-2-default 4.14.15-2-default
    dracut: Turning off host-only mode: '/sys' is not mounted!
    dracut: Turning off host-only mode: '/proc' is not mounted!
    dracut: Turning off host-only mode: '/run' is not mounted!
    dracut: Turning off host-only mode: '/dev' is not mounted!
    dracut: dracut module 'multipath' will not be installed, because command 'multipath' could not be found!
    dracut: dracut module 'fcoe' will not be installed, because command 'dcbtool' could not be found!
    dracut: dracut module 'fcoe' will not be installed, because command 'fipvlan' could not be found!
    dracut: dracut module 'fcoe' will not be installed, because command 'lldpad' could not be found!
    dracut: dracut module 'fcoe' will not be installed, because command 'fcoemon' could not be found!
    dracut: dracut module 'fcoe' will not be installed, because command 'fcoeadm' could not be found!
    dracut: dracut module 'fcoe-uefi' will not be installed, because command 'dcbtool' could not be found!
    dracut: dracut module 'fcoe-uefi' will not be installed, because command 'fipvlan' could not be found!
    dracut: dracut module 'fcoe-uefi' will not be installed, because command 'lldpad' could not be found!
    dracut: dracut module 'nbd' will not be installed, because command 'nbd-client' could not be found!
    dracut: *** Including module: bash ***
    I'm at a loss as to what I might have done differently than you. I've done the complete fresh install followed by the "zypper dup" three times and by "zypper up" ( which did a dup ) once, and I get the same result each time. In two cases I did some other installs (gcc etc) and in two cases I charged right into the updates, so I can't think of what I might have done differently than you.

    I'm still logged in from my Mac. Some things (cat, ls) work; others don't. Any ideas what I might try to recover from this? Else I'll do a fresh install and immediately "zypper dup" once more and see if I can capture the log again.

  10. #10
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    32,320
    Blog Entries
    15

    Default Re: Tumbleweed aarch64 on Raspberry Pi-3B: update strategy advice

    Hi
    Interesting that you have different package count....

    All I did was download the xfce 2018 02 02 image, zcatted it onto the 16GB USB, booted the RPI3 with a screen attached and logitech keyboard, logged in via serial console, made the cam change, rebuilt grub and then did the zypper -vvv dup. No adding a user, configuring etc.

    Try a different USB device? Try a different USB port, check power supply voltage is in spec.
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •