08-25-2017, 07:27 AM
(This post was last modified: 08-26-2017, 07:17 AM by jl_678.
Edit Reason: Clarified Stretch version
)
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.
- I created the image on a known good card and the process was flawless.
- 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.
- I was able to login via SSH over the LAN. Extra nice. :-)
- 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
- I was curious that the SDcard was formatted with many more partitions than my pine64
- 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.)
- 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
(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: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.
(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-25-2017, 08:31 PM
(This post was last modified: 08-25-2017, 08:32 PM by rontant.)
(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.
08-26-2017, 07:13 AM
(This post was last modified: 08-26-2017, 07:17 AM by jl_678.
Edit Reason: Update
)
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, 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
08-26-2017, 10:31 PM
(This post was last modified: 08-26-2017, 10:33 PM by dkryder.)
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?
(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
|
