cubietruck hangs at boot with debian-3.8-wheezy-4.0.4

[cibomato]

If it's the same problem than by me, after booting up debian-3.8-wheezy-3.4.107 (or whatever system works) you should first make shure, that the system date&time is correct:

date

If it's not correct, you can set it with:

date -s "26 JUN 2015 19:20:21"

and control once again with date, that it's correct now.

 

After that, you should check date&time of the hwclock:

hwclock --show

If it's not correct (or you do it anyway), you can set the hwclock date&time to the system date&time via:

hwclock --systohc --localtime

and doublecheck afterwards once again with hwclock --show, that this was successful.

 

 

After that I was able to shut down the system, copy the image I like to sdcard and boot from it.

Everything was discovered (rtc, eth0,...), dhcp worked and got an IP and the system came up without a problem.

 

Hope this helps you too! Let us know.

 

Cheers,

Jochen

[lampra]

Hi,

 

doesn't work for me. My hwclock if fine and still i can't boot images with kernel 4.0.5 or 4.1.

Both stop at runlevel 2 after enabling ramlog. Sadly i do not have a serial cable to provide more info.

Debian-3.8-wheezy-3.4.107 boots fine

[DMG]

It's doesn't work for me too.

Can you set wrong date to hwclock and try boot again?

[cibomato]

Sorry that my solution didn't work for you.

 

I'm not sure whether I'd like to risk my system by wantonly brick it again. Maybe I won't be able to recover it then.

[lampra]

It's doesn't work for me too.

 

Can you set wrong date to hwclock and try boot again?

I didn't try this approach. I started from the beginning to build one image with 4.1 precompiled kernel from http://danand.de and ubuntu core rootfs.

I successfully booted CT but it does not connect to the network.

So if Igor's image needs network at the first boot maybe this is one cause of the problem.

[Igor]

I successfully booted CT but it does not connect to the network.

 

And which u-boot did you use? This is most important.

 

Network is not essential at first boot. If we have it we run apt-get update and recreate ssh-keys else not.

[lampra]

Hi sorry for the delay, I used u-boot provided with the kernel (from danand.de) which is 2015.07 rc3 dirty

[Igor]

O.K. I rebuild all images today, try - It's working for me

 

U-boot is still 2015.04 but there were some changes and fixes to the code.

[Igor]

BTW. My long term stress test. All boards survived 15 days or more. 

[lampra]

ok here are my findings from the latest build.

I used the 12.7.15, 4.1.2 Trusty image.

The image starts booting the kernel, after 3 messages (i.e. brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO 3166 code) hangs for some minutes (2-3),  then continues with firstrun and then stops with the cursor blinking.

I tried ttys2 and i was able to login and change the root password. So far no network connection. Using top, i saw that fping consumes all the cpu. Killing fping causes reboot. After reboot, boot is fine (except of the delay probably caused by brcmfmac) but impossible to login as root as it does not accept the old or the new password. The same happens if at first boot a new user is added.

[Igor]

I download this image and burn it to the fresh SD card. 

No problems at all - working like a charm.

 

Your Cubietruck must have some HW (quality) issue if you have so many troubles.

[lampra]

Finally solved, my problem was also hwclock as described in post 31.

I was able to solve it using my image to set hwclock.

After that, 12.7.15, 4.1.2 Trusty image works like a charm.

Strangely, with other images using kernel 3.4 hwclock seemed correct.

Thank you

[Igor]

All images are build the same way and I also always sync the clock on host ... which is anyway not relevant I guess.

 

Any ideas for walk around?

[lampra]

To my understanding, if needed ie if the date command produces errors, the hwclock could probably be set by a script asking the user to confirm or input the current date/time. Reboot the system and then start first run.

In my case the date command produced errors (which i do not remember exactly) and the hwclock was set at year 1949.  

Alternatively set the root password to expire immediately at the end of first run (not at first login) in order for the user to be able to set the hwclock manually and reboot the system. Then start again firstrun.

[alex-ac]

I have meet this bug on two cubietrucks from five. My solution was simple:
 
Login to system.
Change date to actual.
Change root password again (it was changed with invalid datetime.)
Reboot.
 
ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime
date 071901102015
passwd
reboot
 
If you forgot to change root password, you can insert your sd card into linux computer and reset it.
 
mount /dev/sdc1 /mnt
sed -e '/root/s/root:[^:]*:[^:]*:/root::1:/' -i /etc/shadow 
umount /mnt

 

[Tatane]

I juste faced the issue on the cubietruck.

 

The Debian jessie 12.7.2015, 4.1.2 was running fine on a SD Card for several days.

 

To test an Android, I removed the SD and I installed uing Phoenix Tool the android-ct-nand-hdmi&vga-v3.0.img.img.7z from http://dl.cubieboard.org/model/cubietruck/Image/Android/android-ultimate/to the nand (Android was booting fine etc.).

Then I inserted again the SD card with my jessie and the boot was stuck at:

 

"Welcome to Debian GNU/Linux 8 (jessie)!"

[   TIME   ] Timed out waiting for device dev-ttyS0.device.

[DEPEND] Dependency falided for Serial Getty on ttyS0.

 

So I tried the fix from the post #31 on several armbian images (3.X kernel was always booting), updating the hwclock, checking the updated date OK and reboot, still failing with my jessie 4.1.2

 

Finally, I got it working using the Debian wheezy 12.7.2015 3.4.108, updating to the kernel to 4.0.3 using the Kernel archive/FAQ commands. After reboot the wheezy Ethernet was no more working but it was possible to log to the system directly from the cubie.

The date was something from 1945 and the hwclock --show was returning:

"hwclock : The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095)". (Even if it was updated succesfully through the wheezy)

Applying the fix from post #31, reboot, and then the Ethernet was working again.

 

Tried the jessie 12.7.2015, 4.1.2 and it was booting \o/! Hence, I agree with post #44.

 

Please note that the nand is no more displayed in /dev:

root@cubietruck:~# ls /dev/nan*
ls: cannot access /dev/nan*: No such file or directory

[Igor]

I am going to add root pwd expiry and setting hwclock to some fixed date, 1.1.2015  to firstrun script? 

 

Next build will also come with new uboot 2015.07 which might help with this issue. I don't have those problems so hard to tell.