Hoerli Posted May 7, 2018 Posted May 7, 2018 I got the stable release of armbian for the ROCK64, flashed on a sd-card aaaaaaaand ... wrong password. root + 1234 doesn't work. Has the password been changed? I tried the following combinations: root:1234 ROOT:1234 root:!"§$ (german keyboard, don't know whats on en) armbian:armbian rock64:rock64 All passwords are incorrect. I try it with xenial and strech. (Files of the direct download)
chwe Posted May 7, 2018 Posted May 7, 2018 did you follow the "getting started" ? https://docs.armbian.com/User-Guide_Getting-Started/ password doesn't work is mostly related to crappy SD-Card.. and nothing changed, it should be root/1234
Igor Posted May 7, 2018 Posted May 7, 2018 23 minutes ago, Hoerli said: I got the stable release of armbian for the ROCK64, flashed on a sd-card aaaaaaaand ... wrong password. Any eMMC attached?
Hoerli Posted May 7, 2018 Author Posted May 7, 2018 I tried the test-version 3 days ago. Everything worked out fine. Today the stable version is loaded and flashed on the sd-card with etcher as before. Now the local login no longer works. Update: Login via SSH works with root:1234 Ubuntu and Debian. If i try the first login local, it sometime works but after try to set a new password he locks me out again. My eMMC is not on the board @Igor
Rfreire Posted May 7, 2018 Posted May 7, 2018 (edited) Ah @Hoerli Check /etc/securetty The console that you are trying to log in is probably unlisted. \o Tony!! Edited May 7, 2018 by Rfreire Saluting Tony o/ 1
TonyMac32 Posted May 7, 2018 Posted May 7, 2018 What is the name of the terminal when you start up? ttyS0? @Rfreire same time posting haha
TonyMac32 Posted May 8, 2018 Posted May 8, 2018 @Igor if I have time tonight this might be the culprit: https://github.com/ayufan-rock64/linux-kernel/commit/75a7a42ab19f026427c8aa0dacc034f9956f1745 [edit] hmmm, ok, so that was already remedied. I guess I'll wait for @Hoerli to report back what the tty is calling itself... [edit2] downloaded today, login via tty1 was no problem.
Hoerli Posted May 12, 2018 Author Posted May 12, 2018 New info: I have now flashed completely fresh on the SD card and on the eMMC. Both times everything worked correctly. It boots to tty1. I don't know why it didn't work the first few times.
ab1jx Posted June 6, 2018 Posted June 6, 2018 Mine didn't work either. Stock 3 amp power supply, new High Endurance Sandisk 64 GB SD from B&H Photo. Can't log in. tty something 1 (or 0), might have been ttys1? Wasn't paying attention, fairly sure there was a 1. I didn't ctrl-alt-fn to another virtual console or anything. Connected with a USB keyboard and HDMI monitor. I used dd, the only odd thing I did was bs=1M because I hoped it would go faster. I'm trying to find Etcher source or arm64 to run on my arm64 Pi but when this fsck finishes I'll start dd without telling it a blocksize. Rarely have a problem using dd. But /etc/securetty? I'll look at that in a reader if it won't boot again. Really getting tired of falling over security, maybe I should try Arch again. Securetty, PAM, Selinux, AppArmor. I don't want/need any of that stuff. Hmm, without any block size: dd if="Armbian_5.42_Rock64_Debian_stretch_default_4.4.124_desktop.img" of=/dev/sdb 6799360+0 records in 6799360+0 records out 3481272320 bytes (3.5 GB, 3.2 GiB) copied, 1030.04 s, 3.4 MB/s
ab1jx Posted June 7, 2018 Posted June 7, 2018 OK, that booted. And it's tty1. After the password stuff it came up in xcfe(?) but my rtl8192 wasn't working, no network. So I opened a terminal to find out what the interface was called, something that can only be copied and pasted, not typed or remembered. Same thing Ayufan's version called it I think, 3 letters then 12 hex digits. Made up an interfaces file by modifying one from a Pi: auto wlx48022a9d4d57 iface wlx48022a9d4d57 inet dhcp wireless-essid Moto_lte Tried to ifup it, didn't work. So I decided to reboot, using the GUI, not just typing reboot in a terminal. Now it boots to a black screen with nothing on it. I started playing with Linux 20 years ago, spent 15 years using OpenBSD. I don't like feeling coddled. I don't want it to work like MS Windows, I just want it to work. I'd actually almost prefer FVWM. Anyway this seems to work better than Ayufan's.
Igor Posted June 7, 2018 Posted June 7, 2018 2 hours ago, ab1jx said: 3 letters then 12 hex digits They came from MAC. It's an upstream change. Some background: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ 2 hours ago, ab1jx said: Tried to ifup it, didn't work. RTL8192 is a pretty dodgy adaptor but it works on some kernels ... I try to avoid it. There are other much better but perhaps for few dollars more. 2 hours ago, ab1jx said: I just want it to work Likewise It is our mission, but this sometimes brings some work. Sometimes a little, sometimes we have to give up or not even start. Currently, Rockchip legacy kernels is a complete mess, thanks to recent upstream changes by Rockchip. Don't even think to use beta builds atm. 2 hours ago, ab1jx said: I started playing with Linux 20 years ago Welcome to the club
ab1jx Posted June 7, 2018 Posted June 7, 2018 For a couple weeks or so I've been happily using Stapleberg's arm64 Buster raspi image at https://people.debian.org/~stapelberg/raspberrypi3/, was wondering about doing that with the Rock64 if all else failed. I found https://github.com/rockchip-linux/rkbin for firmware and hopefully drivers. I've used debootstrap before but lucked out and didn't need to put any machine specific stuff in. I have no experience fiddling with the way arms boot: uboot, etc. Hopefully I've got default.target symlinked to multi-user.target now so next time I try to boot I can at least see what's going on. I think the only thing I changed was the interfaces file, I'm not sure why I get a black screen. PAM hates me. I 'd rather watch the bootup messages and type startx anyway. I've got a few rtl8192s, this one didn't work reliably with Ayufan's Debian either. They seem to work in Pis OK. I have 2 downstairs on a Pi and Zero that are mining away through them. The names, yeah, I saw that page at freedesktop.org. I thought in my dmesg it was using a name like rtl8192cu but that's not what ifconfig shows.
Igor Posted June 7, 2018 Posted June 7, 2018 32 minutes ago, ab1jx said: raspberrypi3 Problems in our world are mostly below OS level and below u-boot. You don't have such problems in RPi since Linux is running inside closed proprietary OS and since kernel support is matured and supported by a huge community. If you know something about Linux, you will not learn much new with RPi. Most of the thing works and everything is pretty much the same on all versions. With Rock64 or any other board (family) things are different. They are usually further different when you move from old closed to new open or closed firmware. Booting process for Rockchip:http://opensource.rock-chips.com/wiki_Boot_option Allwinner:http://linux-sunxi.org/BROM Amlogic:https://fredericb.info/2016/10/amlogic-s905-soc-bypassing-not-so.html ... 32 minutes ago, ab1jx said: was wondering about doing that with the Rock64 if all else failed. Userspace is the last thing you need to worry about. It can be improved but in general, its fine. In most cases, you need to fiddle with kernel/u-boot, once you leave commodity and simplicity of Raspberry Pi. 32 minutes ago, ab1jx said: I've used debootstrap before but lucked out and didn't need to put any machine specific stuff in. I have no experience fiddling with the way arms boot: uboot, etc. That is the reason why Armbian (build script) started. To make this process as simple and as generic as possible even we have a huge diversity of ARM world. 32 minutes ago, ab1jx said: 've got a few rtl8192s, this one didn't work reliably with Ayufan's Debian either. They seem to work in Pis OK. Then try to port the driver from Rpi to Rock64 kernel and it will work here as well. It can be done but it is some work. Again, our build tools provide an environment for this but it is still some work.
ab1jx Posted June 7, 2018 Posted June 7, 2018 6 hours ago, Igor said: Then try to port the driver from Rpi to Rock64 kernel and it will work here as well. It can be done but it is some work. Again, our build tools provide an environment for this but it is still some work. Hmm, I'm sitting here at my arm64 Pi so I picked it up and plugged it in. My hunch would be it's a kernel module. Just wondering if I can borrow the one from this arm64 Debian. But wouldn't it be the same driver supplied by Debian? dmesg says [41742.672963] usb 1-1.4: new high-speed USB device number 18 using dwc2 [41742.778925] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=8176 [41742.786034] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [41742.793620] usb 1-1.4: Product: 802.11n WLAN Adapter [41742.798853] usb 1-1.4: Manufacturer: Realtek [41742.803268] usb 1-1.4: SerialNumber: 00e04c000001 [41743.129189] rtl8192cu: Chip version 0x10 [41743.238901] rtl8192cu: Board Type 0 [41743.242755] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1 [41743.250768] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin [41743.257591] usb 1-1.4: firmware: failed to load rtlwifi/rtl8192cufw_TMSC.bin (-2) [41743.265322] usb 1-1.4: Direct firmware load for rtlwifi/rtl8192cufw_TMSC.bin failed with error -2 [41743.278513] usb 1-1.4: firmware: failed to load rtlwifi/rtl8192cufw.bin (-2) [41743.285755] usb 1-1.4: Direct firmware load for rtlwifi/rtl8192cufw.bin failed with error -2 [41743.294478] rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin [41743.353149] ieee80211 phy1: Selected rate control algorithm 'rtl_rc' [41743.354964] usbcore: registered new interface driver rtl8192cu lsmod | grep rtl says rtl8192cu 77824 0 rtl_usb 24576 1 rtl8192cu rtl8192c_common 53248 1 rtl8192cu rtlwifi 81920 3 rtl_usb,rtl8192c_common,rtl8192cu mac80211 720896 3 rtl_usb,rtlwifi,rtl8192cu cfg80211 651264 3 mac80211,rtlwifi,brcmfmac usbcore 274432 10 usbnet,usbhid,usb_storage,rtl_usb,dwc2,usblp,smsc95xx,brcmfmac,uas,rtl8192cu locate rtl8192 | grep ko says /lib/modules/4.14.0-3-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192c/rtl8192c-common.ko /lib/modules/4.14.0-3-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/rtl8192ce.ko /lib/modules/4.14.0-3-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rtl8192cu.ko /lib/modules/4.14.0-3-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192de/rtl8192de.ko /lib/modules/4.14.0-3-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/rtl8192ee.ko /lib/modules/4.14.0-3-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rtl8192se.ko /lib/modules/4.16.0-1-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192c/rtl8192c-common.ko /lib/modules/4.16.0-1-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/rtl8192ce.ko /lib/modules/4.16.0-1-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rtl8192cu.ko /lib/modules/4.16.0-1-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192de/rtl8192de.ko /lib/modules/4.16.0-1-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/rtl8192ee.ko /lib/modules/4.16.0-1-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rtl8192se.ko Probably the kernel version number has to match, the Rock seems to have 4.4.124-rk3328.
ab1jx Posted June 7, 2018 Posted June 7, 2018 Just trying to compare the nm output from the Buster driver with the Stretch driver. If I'm not comparing the wrong files or something. It looks like about the first 6 symbols are defined in both, after that the Stretch one has numbers instead of names. But the numbers are drastically different too, the Stretch one looks like a list of pointers to pointers, the Buster one has addresses with more space between them. One uses relocatable stuff and one doesn't? I don't think I'll try using Buster ko files in Stretch. They do look significantly different, like maybe there's a change that didn't get backported to Stretch? Then again I know that Raspbian's driver has been running for 9 days, that's not the Buster arm64 Debian driver. The Rock one is unreliable, so's the one Ayufan uses. I could see my APs but not connect, then I could and did an apt-get update, but when I tried to install mc it had dropped out again. Maybe I could connect the Rock to the phone over USB in the short term. I've also got a little Ralink USB-wifi adapter somewhere.
ab1jx Posted June 8, 2018 Posted June 8, 2018 OK, I found my Ralink adapter, it works fine. Getting moved in now that I have connectivity. Why are searches in Synaptic so slow? A Pi does them maybe 10 times as fast. I like Synaptic for the searches, being able to see dev and doc addons, being able to build a list/script that calls wget for the actual downloads. Then having that batch of files in a directory by themselves so you can copy them to another machine and dpgk -i to install, instead of having to download them all over again. Maybe I see it, the apt lists are kept as .lz4, that seems like a bad idea. Maybe a couple scripts to uncompress and recompress them. But I just installed some stuff with Synaptic and it's taking 20 minutes or more to get back to the index. 100% CPU usage on 1 core. Ah, /etc/apt/apt.conf.d/02compress-indexes that's gotta go, probably. Just need to find the politcally correct way to do it.
Recommended Posts