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