Jump to content

Wrong password for root?


Hoerli

Recommended Posts

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)

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :P

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

difff_pic.png

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines