Jump to content

New user creation in Armbian 5.04


Recommended Posts

I have compiled to test new armbian 5.04 in a banana pro (Output: Armbian_5.04_Bananapipro_Debian_jessie_4.4.3.zip). At the first boot it is asking for the new user:

 

login as: root
root@192.168.178.30's password:


Thank you for choosing Armbian! Support: www.armbian.com


Creating new account. Please provide a username (eg. your forename):

I introduce whatever username and after that the system is booting. There is a loop continuously because after the boot, if I try to login with root, aks again for user but if I login with a created new user doesn't work because the password not was asked before and therefore is not accepting a password. I'm doing something wrong?

 

I'm connected through SSH; like as usual.

 

Thanks

Link to comment
Share on other sites

I introduce whatever username and after that the system is booting

 

Care to give an example? We tried to eliminate possible illegal characters but maybe this didn't worked out. And then you're in a reboot trap :)

 

Can you please try to adjust line 8 in lib/scripts/check_first_login.sh with

RealUserName="$(echo "${username}" | tr -d -c '[:alpha:]' | tr '[:upper:]' '[:lower:]')"

and try it again using the same username? Or better replace the whole file temporarely with the contents from http://pastebin.com/raw/vdUeXndC then try it again and post /var/log/user-creation.log somewhere? Thx

Link to comment
Share on other sites

Care to give an example? We tried to eliminate possible illegal characters but maybe this didn't worked out. And then you're in a reboot trap :)

 

Can you please try to adjust line 8 in lib/scripts/check_first_login.sh with

RealUserName="$(echo "${username}" | tr -d -c '[:alpha:]' | tr '[:upper:]' '[:lower:]')"

and try it again using the same username? Or better replace the whole file temporarely with the contents from http://pastebin.com/raw/vdUeXndC then try it again and post /var/log/user-creation.log somewhere? Thx

 

after changing the check_first_login.sh it works somehow. Here the terminal output:

 

root@192.168.178.30's password:
-bash: /var/log/user-creation.log: Read-only file system


Thank you for choosing Armbian! Support: www.armbian.com


Creating new account. Please provide a username (eg. your forename): achilles
Adding user `achilles' ...
Adding new group `achilles' (1000) ...
groupadd: cannot lock /etc/group; try again later.
adduser: `/usr/sbin/groupadd -g 1000 achilles' returned error code 10. Exiting.
usermod: user 'achilles' does not exist
usermod: user 'achilles' does not exist
usermod: user 'achilles' does not exist
usermod: user 'achilles' does not exist
usermod: user 'achilles' does not exist
usermod: user 'achilles' does not exist
rm: cannot remove ‘/root/.not_logged_in_yet’: Read-only file system


Dear , your account achilles has been created and is sudo enabled.
Please use this account for your daily work from now on.


root@bananapipro:~#

It looks like that system booted in RO mode:

 

root@bananapipro:/boot# mount
/dev/mmcblk0p1 on / type ext4 (ro,relatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=505360k,nr_inodes=126340,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=23,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=262144k)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=102744k,mode=700)

and dmesg:

 

[    8.282663] systemd-udevd[160]: starting version 215
[    8.299699] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
[    8.315395] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[    8.964878] sun4i-ss 1c15000.crypto-engine: no reset control found
[    8.966448] sun4i-ss 1c15000.crypto-engine: Die ID 0
[    9.218466] sun7i-dwmac 1c50000.ethernet: no reset control found
[    9.218493]  Ring mode enabled
[    9.218503]  No HW DMA feature register supported
[    9.218510]  Normal descriptors
[    9.218516]  TX Checksum insertion supported
[    9.263874] libphy: stmmac: probed
[    9.263907] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
[    9.263917] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
[    9.267169] sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok
[   14.729415] EXT4-fs (mmcblk0p1): Cannot change data mode on remount
[   15.095964] systemd-journald[161]: Received request to flush runtime journal from PID 1
[   15.550204]  RX IPC Checksum Offload disabled
[   15.550236]  No MAC Management Counters available
[   21.537749] sun7i-dwmac 1c50000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
root@bananapipro:/boot#
because RO filesystem, not possible to create logfile.
Edited by jobenvil
Link to comment
Share on other sites

because RO filesystem, not possible to create logfile.

 

And why is it read-only? What's the whole output of 

dmesg | grep ext4

BTW: In case you use a 'fresh' SD card please have a look in our documentation http://www.armbian.com/documentation/and in case the necessary steps to prepare a SD card (always check first) didn't happen already please do so.

 

Most probably the reason for a read-only rootfs with Armbian is our default setting: mountopts[ext4]=',commit=600,errors=remount-ro'

Link to comment
Share on other sites

here the relevant:

[    3.774137] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 8, RTO !!
[    3.783427] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    3.784924] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    3.786417] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    3.789101] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[    3.804212] mmc1: new high speed SDIO card at address 0001
[    3.818023] ata1: SATA link down (SStatus 0 SControl 300)
[    3.830828] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
[    3.830908] VFS: Mounted root (ext4 filesystem) readonly on device 179:1.
[    3.835046] devtmpfs: mounted

dmesg:


root@bananapipro:~# dmesg | grep ext4
[    0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 cgroup-enable=memory swapaccount=1 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
[    3.830908] VFS: Mounted root (ext4 filesystem) readonly on device 179:1.


yes, probably the sd_card. It is lexar High-Speed 16GB class 10. I will see what I can do. Thanks. Probably with first try, was the same RO problem on the background.

Link to comment
Share on other sites

Probably with first try, was the same RO problem on the background.

 

Definitely. Since adduser faced the same problem due to read-only rootfs it exited != 0 and then a reboot occured.

 

What about to use logout instead of reboot?

 

Also not nice and it doesn't help in such situations either. We must take care of more things, check /etc/mtab for obvious errors and so on.

 

At least we should soon implement logging verbosity by checking /boot/.verbose from u-boot (who will do this?) and should definitely check for r/o filesystem, present a warning and try to deal reasonable with such a situation in the other involved scripts.

 

When I ran into that issue some time ago it wasn't even possible to change the root pwd on 1st login (authentication error without further notification that the reason was r/o rootfs). This seems to be different in jobenvil's case -- see top of thread (maybe jessie acting differently than wheezy?)

 

EDIT: And maybe a bit more error handling in the build process too -- see below ;)

Link to comment
Share on other sites

maybe it is another problem. I check the compilation and I had following:

essie.b6eee545ceffad6ec9cb1b12f2a6c61e.tgz:  628MiB [27.7MiB/s] [==========================>] 102%
[ o.k. ] Install kernel [ linux-image-next-sunxi_5.04_armhf.deb ]
[ o.k. ] Install u-boot [ linux-u-boot-next-sunxi_5.04_armhf.deb ]
[ o.k. ] Install headers [ linux-headers-next-sunxi_5.04_armhf.deb ]
[ o.k. ] Install firmware [ linux-firmware-image-next-sunxi_5.04_armhf.deb ]
[ o.k. ] Install DTB [ linux-dtb-next-sunxi_5.04_armhf.deb ]
[ o.k. ] Fixing release custom applications. [ jessie ]
Selecting previously unselected package sunxi-tools.
(Reading database ... 46115 files and directories currently installed.)
Preparing to unpack .../sunxi-tools_1.3-1_armhf.deb ...
Unpacking sunxi-tools (1.3-1) ...
Setting up sunxi-tools (1.3-1) ...
[ o.k. ] Creating boot scripts [ bananapipro ]
[ o.k. ] Possible after install. [ customize-image.sh ]
[ o.k. ] Writing bootloader [ /dev/loop0 ]
[ o.k. ] Shrink image last partition to [ minimum ]
losetup: /root/compilation/output/cache/Armbian_5.04_Bananapipro_Debian_jessie_4.4.3.raw: failed to set up loop device: Device or resource busy
tune2fs: Bad magic number in super-block while trying to open /dev/loop0
Couldn't find valid filesystem superblock.
tune2fs: Bad magic number in super-block while trying to open /dev/loop0
Couldn't find valid filesystem superblock.
losetup: /root/compilation/output/cache/Armbian_5.04_Bananapipro_Debian_jessie_4.4.3.raw: failed to set up loop device: Device or resource busy

2: unknown command
+: unknown command
Re-reading the partition table failed.: Invalid argument
[ o.k. ] Create and sign [ Armbian_5.04_Bananapipro_Debian_jessie_4.4.3.zip ]

[ o.k. ] Runtime [ 56 min ]
root@kali:~/compilation#

Usually I'm not building in this VM (Linux kali 4.3.0-kali1-amd64 #1 SMP Debian 4.3.5-1kali1 (2016-02-11) x86_64 GNU/Linux) but last time so far as I remember It was succesfully for the banana pro compilation but not for the odroidXU4. This time failed the banana pro. I don't know, I have to check the compilation with your ubuntuVM instead with this VM. I have to left right now. I will check later. Thanks once again.

 

Link to comment
Share on other sites

 

 

At least we should soon implement logging verbosity by checking /boot/.verbose from u-boot (who will do this?) and should definitely check for r/o filesystem, present a warning and try to deal reasonable with such a situation in the other involved scripts.

 

I'll add this.

Link to comment
Share on other sites

In the night I downloaded the banana pro image from armbian, the 5.04, then I copied it with Rufus (DD Image + Checking for errors). It took one hour to finish. No errors found (http://pastebin.com/zNgFcYZn). Later I was able to boot and create the user without any problem. Here the dmesg: http://pastebin.com/PLHxHYTg

 

I see that you added verbosity to the boot process. This will be helpfull in such cases like mine.

 

Shorted the mmc output from dmesg is following:

root@bananapipro:~# dmesg | grep -i mmc
[    3.193379] reg-fixed-voltage vmmc3: could not find pctldev for node /soc@01c00000/pinctrl@01c20800/vmmc3_pin@0, deferring probe
[    3.682541] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found
[    3.683089] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    3.717561] sunxi-mmc 1c0f000.mmc: base:0xf08ee000 irq:27
[    3.733990] sunxi-mmc 1c12000.mmc: No vqmmc regulator found
[    3.754349] mmc0: host does not support reading read-only switch, assuming write-enable
[    3.756779] mmc0: new high speed SDHC card at address b368
[    3.757604] mmcblk0: mmc0:b368 LEXAR 14.9 GiB
[    3.759042]  mmcblk0: p1
[    3.767456] sunxi-mmc 1c12000.mmc: base:0xf08f2000 irq:28
[    3.773479] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 8, RTO !!         THIS LINE ALWAYS IN RED, ERROR?
[    3.782769] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    3.784267] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    3.785759] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    3.788443] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[    3.803508] mmc1: new high speed SDIO card at address 0001
[    6.319368] systemd[1]: Expecting device dev-mmcblk0p1.device...
[    9.159883] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)

 

Link to comment
Share on other sites

About the build process, I've noticed that /tmp folder of my workstation is always becoming RO for other groups/users, so after "sudo ./compile.sh" finished, I always need to do a "sudo chmod a+rw /tmp"

Interesting, this could be the reason why my last 4 Virtual Machines (VMware + Ubuntu) died....uhmm?, no, the reason for my problem should be something different.  I checked that right now and /tmp is still 777 after building.

Link to comment
Share on other sites

About the build process, I've noticed that /tmp folder of my workstation is always becoming RO for other groups/users, so after "sudo ./compile.sh" finished, I always need to do a "sudo chmod a+rw /tmp"

 

IIRC this was introduced when we changed the build process of the desktop image. We should either fix that or set /tmp back to 777 automatically when finished.

 

I see that you added verbosity to the boot process. This will be helpfull in such cases like mine.

 

Yes, we also tried to introduce 'crash detection' with the next release (enable verbose messages automatically after a crash but unfortubately I messed it up ;) )

 

But in your case you had troubles with loop devices on your build host that are currently ignored by our build system and let then to an image with fs errors.

Link to comment
Share on other sites

I think this could be succesfully catalogued like as solved.

 

Summary: Errors(1) on SD-Card which lies to read-only filesystem on first boot and as a result new user an not be created.

 

(1) Errors due to faulty compilation image.

Edited by jobenvil
Link to comment
Share on other sites

About the build process, I've noticed that /tmp folder of my workstation is always becoming RO for other groups/users, so after "sudo ./compile.sh" finished, I always need to do a "sudo chmod a+rw /tmp"

Thank you for this tip. I was wondering why my Ubuntu crashes every time after i build Armbian.

Link to comment
Share on other sites

You should do an 'git pull' immediately since we implemented at least a workaround the moment we've been aware of the problem (commit from 4 days ago)

A lot of changes from 5.0 i've tried last and 5.05 and all look good :) . Yes, problem is solved, no more crashes after building image. And i saw some other things - like locales don't break compilation anymore if there is something else, than EN. Also i noticed new extra ralink driver. Is this for hardware mod with RT5572N from here - http://forum.armbian.com/index.php/topic/372-hardware-mod-bpi-r1/ ? Because i already have the module but been too lazy to soldered it yet and this could be quite useful for me.

Link to comment
Share on other sites

MT7601 you can found now in most cheap USB adapters, so not related to R1 hw mod. I have one of those - they are working quite ok, but the speed performance is so so but good for 5 USD shipped ;)

Link to comment
Share on other sites

I don't know if it's helpful, but I think I've experienced something similar.

(I mentioned it briefly here).

 

Image:

Armbian_5.04_Cubieboard2_Debian_jessie_3.4.110.zip

 

After writing the image, I booted from it.

I found the board's IP address on the router, used SSH to connect and was asked to enter a new root password.

I entered a new root password (twice as usual), then it said "rebooting" and I logged in again.

Again I was asked to enter a new root password.

 

I'd expect that this is a related issue. I gave up on 'legacy' and decided to go back to vanilla, as I'll be using the board as a server. -Maybe other CubieBoard2 owners can provide feedback if this particular image can be booted ?

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