Very early experience with Rock64 and Debian Stretch
#1
Hi,

I had a few minutes last night to test out my new Rock64 with the Debian Stretch minimal (0.5.1-89).  The results were not stellar; however, I only had a few minutes to play with it and so have not dug into the situation.  To provide some brief background, I have a bunch of pine64s and RPi and so am reasonably experienced with this stuff, but I am not expert like many here.

  1. I created the image on a known good card and the process was flawless.
  2. The system booted up well and threw a filesystem error requiring an fsck.  This did not impact the initial boot and everything came up including SSH.  Nice.
  3. I was able to login via SSH over the LAN.  Extra nice. :-)
  4. My first step was to run "sudo apt-get update", and it failed with a "size mismatch" error.  I think that this is a known issue
  5. I was curious that the SDcard was formatted with many more partitions than my pine64
  6. I tried to fix the disk issues with fsck, but both fdisk and gparted were unhappy and failed.  I am trying to understand if this is an SDcard issue or a issue with software image.  I will test with another card next week. (I would post the error message, but it was getting late and I did not have a chance to capture it.)
  7. The process got me thinking about expanding the volume.  Do we have a script to automate this like we originally had with Debian or Armbian on the Pine64?
In short, my initial experience was not great with the Stretch image, but these are early days and I know that things will solidify.  I will test out another SDcard and Jessie next week.

I share all of this in case anyone has seen similar changes or has advice about what can be done to address issues 4, 6 and 7.

JL_678
  Reply
#2
https://forum.pine64.org/showthread.php?tid=5009
  Reply
#3
(08-25-2017, 09:03 AM)stuartiannaylor Wrote: https://forum.pine64.org/showthread.php?tid=5009

Excellent point.  Thank you.  Maybe we should wrap that into a shell script and provide it with the images?  The original Pine64 releases had this and it dramatically simplified things.
  Reply
#4
(08-25-2017, 09:15 AM)jl_678 Wrote:
(08-25-2017, 09:03 AM)stuartiannaylor Wrote: https://forum.pine64.org/showthread.php?tid=5009

Excellent point.  Thank you.  Maybe we should wrap that into a shell script and provide it with the images?  The original Pine64 releases had this and it dramatically simplified things.

Really good point Pine have been really early adopters of the RK3328 and the RK33xx series is getting a mass of development in conjunction with google.
I presume they will but you can always open an issue on git hub or maybe the mods want to keep that under control so things don't get duplicated.
I haven't even got my board yet but just reading to get to grips with things.
  Reply
#5
(08-25-2017, 09:03 AM)stuartiannaylor Wrote: https://forum.pine64.org/showthread.php?tid=5009

I had similar issues with the Debian Stretch image, which is why I switched to Xenial.
Having posted this thread I went back to Stretch to figure out the steps to include it as well, but I ran into some problems (I only had limited time as well so I gave up on it).

parted & fdisk worked for me, but there's no resize2fs installed.
The e2fsprogs package that contains it is installed, but none of the regular ext4 tools like resize2fs or mke2fs are there.
If you get it figured out, please reply to my thread for the benefit of all.


The repository size mismatch issue can be blocked by commenting out the first line in this file:
Code:
sudo nano /etc/apt/sources.list.d/ayufan-rock64.list
  Reply
#6
(08-25-2017, 06:28 PM)aussiemate Wrote:
(08-25-2017, 09:03 AM)stuartiannaylor Wrote: https://forum.pine64.org/showthread.php?tid=5009

I had similar issues with the Debian Stretch image, which is why I switched to Xenial.
Having posted this thread I went back to Stretch to figure out the steps to include it as well, but I ran into some problems (I only had limited time as well so I gave up on it).

parted & fdisk worked for me, but there's no resize2fs installed.
The e2fsprogs package that contains it is installed, but none of the regular ext4 tools like resize2fs or mke2fs are there.
If you get it figured out, please reply to my thread for the benefit of all.


The repository size mismatch issue can be blocked by commenting out the first line in this file:
Code:
sudo nano /etc/apt/sources.list.d/ayufan-rock64.list

Ayufan has updated his Debian Stretch Minimal image. The latest one at his Github as of this morning is stretch-minimal-rock64-0.5.1-89-arm64.img and it no longer shows the error when running apt-get upgrade. Resize2fs is there as well.
  Reply
#7
I just went back and reviewed this. The version that I installed is the same one listed on that github page 0.5.1-89. Hence the issues that I listed above remain.

Thank you.

Sent from my XT1254 using Tapatalk
  Reply
#8
(08-26-2017, 07:13 AM)jl_678 Wrote: I just went back and reviewed this. The version that I installed is the same one listed on that github page 0.5.1-89. Hence the issues that I listed above remain.

Thank you.

Sent from my XT1254 using Tapatalk

Sorry to hear about that. I didn't have such problem though. Like you, the first thing I did using this latest image (stretch-minimal-rock64-0.5.1-89-arm64) was  running '"sudo apt-get update" and "sudo apt-get upgrade". All was running smoothly without any error unlike the previous version.  I have also done the resizing of the SD partition (thanks to AussieMate), then migrated the root system to an SSD, and installied nginx, php, mariadb, phpmyadmin, rtorrent (with rutorrent as its webui), smbd, nmbd, dtach, etc... All seems to be running fine so far. 


FYI:

Code:
rock64@rock64:~$ uname -a

Linux rock64 4.4.70-rockchip-ayufan-89 #1 SMP Sun Aug 20 13:29:12 UTC 2017 aarch64 GNU/Linux

rock64@rock64:~$ lsb_release -d

Description:    Debian GNU/Linux 9.1 (stretch)

rock64@rock64:~$ systemd-analyze blame
         10.854s nmbd.service
          5.432s dhcpcd.service
          2.542s mariadb.service
           957ms dev-sdb1.device
           788ms php7.0-fpm.service
           479ms networking.service
           393ms public3.mount
           380ms smbd.service
           337ms systemd-journald.service
           318ms systemd-udev-trigger.service
           292ms ntp.service
           262ms phpsessionclean.service
           242ms systemd-logind.service
           224ms sysstat.service
           195ms ssh.service
           152ms rsyslog.service
           147ms avahi-daemon.service
           145ms nginx.service
           143ms alsa-restore.service
           137ms fake-hwclock.service
           132ms systemd-modules-load.service
           130ms systemd-fsck@dev-disk-by\x2dlabel-boot.service
           129ms systemd-remount-fs.service
           122ms rtorrent.service
           117ms systemd-user-sessions.service
           110ms systemd-tmpfiles-setup-dev.service
           104ms kmod-static-nodes.service
            96ms systemd-random-seed.service
            86ms systemd-sysctl.service
            65ms sys-fs-fuse-connections.mount
            56ms systemd-udevd.service
            53ms sys-kernel-config.mount
            48ms ssh-keygen.service
            46ms systemd-journal-flush.service
            44ms sys-kernel-debug.mount
            44ms systemd-tmpfiles-setup.service
            38ms public.mount
            36ms boot-efi.mount
            33ms systemd-tmpfiles-clean.service
            28ms systemd-update-utmp.service
            20ms systemd-update-utmp-runlevel.service
  Reply
#9
is using the supplied build update script in /usr/local/sbin [if it is still supplied] the same thing as doing manual apt update/upgrade commands?
  Reply
#10
(08-26-2017, 08:35 PM)rontant Wrote:
(08-26-2017, 07:13 AM)jl_678 Wrote: I just went back and reviewed this. The version that I installed is the same one listed on that github page 0.5.1-89. Hence the issues that I listed above remain.

Thank you.

Sent from my XT1254 using Tapatalk

Sorry to hear about that. I didn't have such problem though. Like you, the first thing I did using this latest image (stretch-minimal-rock64-0.5.1-89-arm64) was  running '"sudo apt-get update" and "sudo apt-get upgrade". All was running smoothly without any error unlike the previous version.  I have also done the resizing of the SD partition (thanks to AussieMate), then migrated the root system to an SSD, and installied nginx, php, mariadb, phpmyadmin, rtorrent (with rutorrent as its webui), smbd, nmbd, dtach, etc... All seems to be running fine so far. 


FYI:

Code:
rock64@rock64:~$ uname -a

Linux rock64 4.4.70-rockchip-ayufan-89 #1 SMP Sun Aug 20 13:29:12 UTC 2017 aarch64 GNU/Linux

rock64@rock64:~$ lsb_release -d

Description:    Debian GNU/Linux 9.1 (stretch)

rock64@rock64:~$ systemd-analyze blame
         10.854s nmbd.service
          5.432s dhcpcd.service
          2.542s mariadb.service
           957ms dev-sdb1.device
           788ms php7.0-fpm.service
           479ms networking.service
           393ms public3.mount
           380ms smbd.service
           337ms systemd-journald.service
           318ms systemd-udev-trigger.service
           292ms ntp.service
           262ms phpsessionclean.service
           242ms systemd-logind.service
           224ms sysstat.service
           195ms ssh.service
           152ms rsyslog.service
           147ms avahi-daemon.service
           145ms nginx.service
           143ms alsa-restore.service
           137ms fake-hwclock.service
           132ms systemd-modules-load.service
           130ms systemd-fsck@dev-disk-by\x2dlabel-boot.service
           129ms systemd-remount-fs.service
           122ms rtorrent.service
           117ms systemd-user-sessions.service
           110ms systemd-tmpfiles-setup-dev.service
           104ms kmod-static-nodes.service
            96ms systemd-random-seed.service
            86ms systemd-sysctl.service
            65ms sys-fs-fuse-connections.mount
            56ms systemd-udevd.service
            53ms sys-kernel-config.mount
            48ms ssh-keygen.service
            46ms systemd-journal-flush.service
            44ms sys-kernel-debug.mount
            44ms systemd-tmpfiles-setup.service
            38ms public.mount
            36ms boot-efi.mount
            33ms systemd-tmpfiles-clean.service
            28ms systemd-update-utmp.service
            20ms systemd-update-utmp-runlevel.service
Thank you for this clarification. I will test further tonight and use a different sdcard in case that is part of the problem.

Sent from my XT1254 using Tapatalk
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  openwrt for the rock64 wilsonYan 17 7,451 09-22-2021, 06:38 PM
Last Post: wilsonYan
  DietPi OS for ROCK64 MichaIng 19 5,052 09-17-2021, 02:38 PM
Last Post: MichaIng
  slarm64 (unofficial slackware) Rock64 RK3328 (aarch64) mara 117 73,707 09-10-2021, 03:01 PM
Last Post: mara
  rock64-debian-mrfixit-190531.img.xz : missing /usr/lib/dri/rockchip_dri.so popi 5 478 08-12-2021, 04:55 AM
Last Post: igorp
  Centos 8 Stream on Rock64 ayoungdukie 1 542 06-07-2021, 11:50 AM
Last Post: zer0sig
  Talos on ROCK64 cjyar 2 618 06-04-2021, 11:50 AM
Last Post: cjyar
  CentOS 7 for Rock64 pineadmin 3 3,617 05-30-2021, 08:20 AM
Last Post: ayoungdukie
  Rock64 CRUX-ARM (aarch64) mara 0 427 05-27-2021, 02:22 PM
Last Post: mara
  RETRO-GAMING: UPDATED RELEASE OF RECALBOX FOR THE ROCK64 Mrfixit2001 32 27,569 05-22-2021, 07:01 AM
Last Post: fartadeadrian
  Debian build from mrfixit2001 Luke 18 12,926 05-17-2021, 02:35 AM
Last Post: Wizzard

Forum Jump:


Users browsing this thread: 1 Guest(s)