Cubieboard 2 stopped working after update

[WarheadsSE]

As a note: we've also disabled xattrs for cgroups in systemd until more devices get in line, or mainline.

[PLyttle]

to ZagorTeNej:

My guess is that uboot now wants a valid uenvcmd in uEnv.txt.
I base this on:
$this->bbcode_second_pass_code('', '202 bytes read in 115 ms (1000 Bytes/s)
Importing environment from mmc (uEnv.txt)...
Checking if uenvcmd is set ...
Running default loaduimage ...
3321064 bytes read in 330 ms (9.6 MiB/s)
48128 bytes read in 108 ms (434.6 KiB/s)
Booting from mmc ...
')
see line 3.

but I could be wrong

you have to revert to uboot-cubieboard2-2014.04-1 to make it work as before

$this->bbcode_second_pass_code('', 'sudo pacman -U /var/cache/pacman/pkg/uboot-cubieboard2-2014.04-1-armv7h.pkg.tar.xz
')
where I assume you still have this in your cache.

LP

[ZagorTeNej]

@PLyttle

Thanks for quick answer. I took a look at file include/configs/sunxi-common.h (from which the output comes from). Analysing this file i have seen that there is no more "extraargs" variable, but there is a variable called "optargs" that i have used to pass my extra arguments. My uEnv.txt now looks like this
$this->bbcode_second_pass_code('', 'optargs=ipv6.disable=1 mac_addr=00:18:8b:c4:9b:fe')
and after restart /proc/cmdline looks like this
$this->bbcode_second_pass_code('', '[root@alarm ~]# cat /proc/cmdline
console=ttyS0,115200 ipv6.disable=1 mac_addr=00:18:8b:c4:9b:fe root=/dev/mmcblk0p1 rw rootwait video=')
Thanks again!

[kmihelich]

Yes, the sunxi U-Boot releases have been brought in line with our other U-Boot releases as far as the default environment and boot logic is concerned. The extraargs variable used before is now optargs.

[maggu2810]

$this->bbcode_second_pass_quote('WarheadsSE', 'A')s a note: we've also disabled xattrs for cgroups in systemd until more devices get in line, or mainline.

[WarheadsSE]

ARGGGGGGGGGGG

[eduardoarnoldh]

I have the same problem with my Cubieboard version 1. The thing is I was using this computer as my personal server and I do not have physical access to it, as I am travelling. The only way I can get access is to ask someone to remove the SD Card, where my Arch system resides and take it into it's personal computer and give me remote access. I am having a hard time figuring out how to apply the patch in this way, because that person would be using Ubuntu and it won't be possible to chroot into the system.

I really do not consider reinstalling all the system, so how should I proceed?

[WarheadsSE]

We've actually already integrated the a patch into the systemd PKGBUILD that we now override, disabling xattr entirely due to this.
https://github.com/archlinuxarm/PKGBUIL ... ount.patch

[eduardoarnoldh]

Thank you for the reply, but I still don't know how I should proceed to update my system, as it cannot boot, so I have no SSH connection. Also, I cannot ask a third person to chroot into the SD Card as the architecture (x86) is different. Any suggestions on how to deal with this?

[WarheadsSE]

have them extract the pkg.xz to the root of the folder, boot, then re-install that package. You'll then have a few .dot files on / to clean up after boot.