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?
   

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

(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.

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

(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

(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

(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