wildcat_paris

@gTs2 So it is working. please, just put the main idea in bold if you write a long message (people often wrote me : "make you message quicker, simpler & clearer, it is not a novel")

I can handle mailing list registration moderation if needed.

some simple thoughts to help (assuming limited time consumption) - adding a short "Roadmap" (main & side quests) section (in docs.armbian.com/Process_Contribute/ ?) displaying "main" goals for current & possible next iterations because currently the single tasks is the forum are useful but not "readable" - a (google group?) mailing list (read only) for contributors (to push roadmap changes & call for tasks) - a separate mailing list (read only) to call testers when needed - a page to report testing per board (wiki? google web document?)

the standard USB 5V should be between 4.75 and 5.25V (probably 4.90 - 5.10V is safer). Outside the range (over or under) the power can lead to troubles. but ok. comparing with boot from http://forum.armbian.com/index.php/topic/1897-problem-with-orange-pi-pc-not-started-after-reboot/ "MMC: no card present" the card doesn't detect a SD/eMMC card so it cannot go any further. please can you try an "old" image from http://www.orangepi.org/downloadresources/ to know if there is not a problem with recent uboot 2016.09, the other fox is using Armbian with uboot 2016.05

I forgot about your message and when testing with UUID on XU4 with recent uboot & vanilla kernel, I strangely moved to LABEL & tested and I found it very simple. Far easier to manage than the "random" UUID Thanks!

I guess zador.blood.stain hasn't still changed the variable, I am using SUBREVISION="-GRO" it doesn't rename the debian package but still the tags is changed in dpkg/aptitude so Armbian 5.21 is renamed 5.21-GRO

xenial: still the old issue eth0 is enx001e06301503 this xenial thing gave me the opportunity to test the HDMI console and figure out the usb2 port is working so the XU4 is working with vanilla software, even with eMMC, I cannot believe this. Samsung Opensource Group team is just great.

I have pushed some changes for XU4 with the help of so many internet sources (thanks!) - uboot 2016.05 - vanilla kernel (4.7.6 as of now) - single partition (using the LABEL=rootfs for booting) - SD & eMMC for eMMC, burn the image on both a SD card & eMMC first, boot with SD card to write files on mmcblk0boot0 partition, then cd /usr/lib/linux-u-boot-next-odroidxu4_5.21-GRO_armhf (probably remove -GRO) -rw-r--r-- 1 root root 15616 oct. 1 01:58 bl1.bin.hardkernel -rw-r--r-- 1 root root 14592 oct. 1 01:58 bl2.bin.hardkernel.1mb_uboot -rw-r--r-- 1 root root 1807 oct. 1 01:58 sd_fusing.sh -rw-r--r-- 1 root root 262144 oct. 1 01:58 tzsw.bin.hardkernel -rw-r--r-- 1 root root 548159 oct. 1 01:58 u-boot-dtb.bin then sudo bash ./sd_fusing.sh /dev/mmcblk0 eventually, remove the SD card, power-off, boot from eMMC Please, I would need help to check the changes, probably testing with Xenial (as I am using CLI Jessie so far) you can fetch the source here https://github.com/golfromeo-fr/lib/tree/gro_master or later in the master branch https://github.com/igorpecovnik/lib/issues/482 thanks! some config I am using note: zador.blood.stain is making the framework so well, it's getting quite easy to achieve this. So nice!

@olivier-b if you restored the SDcard and the kernel boots, your card should be fine (at least, some hopes, because you may have a bad sector being remapped on your SDcard). so, the blob & uboot is not properly written on the SDcard by the upgrade .deb file, so the boot process is broken. 1/ Plan A I would download the deb files, only install the kernel related files (nothing related to uboot/blobs/etc) OR more simple, install aptitude and select the package you want to upgrade (related to the kernel, not uboot -- so the boot process is not broken) 2/ Plan B so I would download a brand new image, so we can test your SDcard http://www.armbian.com/orange-pi-plus/ then, (I could) compile your kernel/boot , provide you the all the .deb file & so we can check if it breaking a fresh install

the gap between 5.10 & 5.20 is huge (Armbian tool especially). Maybe it is better if you backup your data & start from a fresh install and/or attend un conseil plus avisé que le mien

et voilà , I am a true goldfish_paris this one works... better writing to come... LABEL is working so I guess UUID will be working as well. I am so dumb... never forget the initramfs, if not you don't have the modules... setenv bootargs "console=tty1 console=ttySAC2,115200n8 root=LABEL=root rootfstype=ext4 rootwait rw earlyprintk"; load mmc 0:1 0x40008000 /boot/zImage; load mmc 0:1 0x42000000 /boot/uInitrd; load mmc 0:1 0x44000000 /boot/dtb/exynos5422-odroidxu4.dtb; bootz 0x40008000 0x42000000 0x44000000; so next better writing then PR the changes

ok other options are root=LABEL=xxx root=PARTUUID=xxxx (gpt only) but yeah... I need to load, not zImage but the initramfs... well! I am watching too many Greg Berlanti's shows I guess

ok, I keep writing in the air (goldfish air bubbles?) it seems /etc/fstab works fine with UUID (at least with a single partition) Then I tested in boot.scr root=UUID=xxxxxxxxx instead of root=/dev/mmcblk1p1 the kernel boots then stalls at the HDD detection (like when using by mistake root=/dev/mmcblk0p1) note: it seems uboot 2016.05 & kernel 4.7.5 are taking mmcblk0 = eMMC & mmcblk1 =SDcard ??? question: I am using MBR, I have read uboot could work with UUID with GPT partition but it doesn't explain why the kernel starts up then fails to find the root=UUID=xxxxxxxxxxxx as in the following logs maybe my answer is in the air... let's see

@zador.blood.stain @Igor @anyone the goldfish_paris is getting some headaches (ok it is goldfish headaches, each one lasts 3 seconds no more no less , goldfish limited memory related) I got a working image of Armbian with single partition for XU4, added BOOTSIZE=0 for xu4-next (and changed boot.cmd) I wonder why this simple boot.cmd works and not this one (which worked like a charm for dual partition boot), I checked the ENV variables in exynos*.h (I updated a bit the ENV) if someone has an idea, thanks edit: the boot logs (just in case)

the nice thing with the Armbian tool is "this is all scripted" so you can trace anything you want while you build your own image. So you can check yourself with your security team, if it is accurate for you. Then if something is not right for you, you can fork the project and fix it as you need (making the whole community benefits from your changes if needed)

(damned the message is too long, I am using Firefox nightly, I cannot edit) @zador.blood.stain uboot 2016.09 doesn't compile, 2016.05 is ok with the same config file (still better than uboot 2012.07) the raw patch is to embed the hardkernel blobs into u-boot Thank you for your next pieces of advise

@zador.blood.stain I got (we've got) something the xu4 starts with u-boot 2016.05 (-dtb.bin) & kernel 4.7.5 it seems to compile with gcc 5.4 (both) & the raw patch (I had headaches to figure out the patch can be make with diff -Naru) I need to dig more in the features but my problem so far is "/etc/fstab" which is not updated with the sed line (in fact sed never updated fstab when I put my first changes for xu4 this summer) with lib/config/sources/odroidxu4.conf family_tweaks() { echo "blacklist ina231_sensor" > $CACHEDIR/sdcard/etc/modprobe.d/blacklist-odroid.conf chroot $CACHEDIR/sdcard /bin/bash -c "apt-get -y -qq remove --auto-remove lirc >/dev/null 2>&1" if [[ $BRANCH == next && -f $CACHEDIR/sdcard/etc/fstab ]] ; then sed -e 's/mmcblk0/mmcblk1/g' -i $CACHEDIR/sdcard/etc/fstab | tee -a $DEST/debug/output.log 2>&1 fi cp $CACHEDIR/sdcard/boot/dtb/exynos5422-odroidxu4.dtb $CACHEDIR/sdcard/boot/exynos5422-odroidxu4.dtb | tee -a $DEST/debug/output.log 2>&1 } note: don't ask me why I have to copy the dtb in /boot... probably logical with the boot.cmd file but ??? so next: - cleaning and upload this set of changes in the tools - trying to switch to a single partition for xu4 next

3/ copy the ".config" file with the pattern in userpatches folder I am using userpatches/linux-sunxi-next.config userpatches/linux-odroidxu4-next.config 2/ unless better piece of advise, create a patch for the 2 files then put them in userpatches/kernel (?) 1/ idea 1: create a patch with all the source (???) idea 2: use symlinks ???

for the patch to be created & applied properly you have to pay attention to the path example: --- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts assuming you have 2 folders (a, b ) and you want to create a patch for the file arch/arm/boot/dts/sun4i-a10-cubieboard.dts you have to "cd" on the higher directory then diff a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts > $HOME/my.patch note: usually the patch command is used with the option "-p1" so ignoring folder a & b when patching of course, you can trick the patch and diff sun4i-a10-cubieboard.dts.old sun4i-a10-cubieboard.dts.new then replace the header with --- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts -- you may need to read some more piece of info https://duckduckgo.com/?q=creating+a+patch+with+diff http://stackoverflow.com/questions/23390823/creating-patch-file-for-linux-kernel#23390933 http://linux.byexamples.com/archives/163/how-to-create-patch-file-using-patch-and-diff/

@Da Alchemist be careful, don't put any sensitive data (or at least, do regular backup) because the eMMC may get worse and fail completely.

ok, already put a patch for the uboot config. let's see I have never tried binary raw patch

@zador.blood.stain @Igor it seems uboot 2016.05 (maybe 2016.09 as well) is booting 4.7.4 kernel (at least on a SDcard) let's go to the architecture perspective How to upload / include the hardkernel blobs in Armbian, please? currently I have hardkernel uboot 2012.07 in sources folder so I linked sd_fuse folder to the mainline uboot folder so Armbian can proceed [gr@server1604:~/gro_armbian/sources] $ cd u-boot-odroidxu [gr@server1604:~/gro_armbian/sources/u-boot-odroidxu] $ ls odroidxu3-v2012.07 v2016.05 v2016.09 [gr@server1604:~/gro_armbian/sources/u-boot-odroidxu] $ cd v2016.05 [gr@server1604:~/gro_armbian/sources/u-boot-odroidxu/v2016.05] aeaec0e* ± ll sd_fuse lrwxrwxrwx 1 root root 30 Sep 22 06:20 sd_fuse -> ../odroidxu3-v2012.07/sd_fuse// the files we need: - bl1.bin.hardkernel - bl2.bin.hardkernel.1mb_uboot (the blobs to make mainline fatty u-boot.bin) - tzsw.bin.hardkernel [gr@server1604:~/gro_armbian/sources/u-boot-odroidxu/v2016.05/sd_fuse] odroidxu3-v2012.07(+0/-0)* ± ll hardkernel_1mb_uboot total 96 drwxr-xr-x 2 gr gr 4096 Jul 26 00:03 ./ drwxr-xr-x 9 gr gr 4096 Jul 26 00:03 ../ -rw-r--r-- 1 gr gr 15616 Jul 26 00:03 bl1.bin.hardkernel -rw-r--r-- 1 gr gr 14592 Jul 26 00:03 bl2.bin.hardkernel.1mb_uboot -rw-r--r-- 1 gr gr 536 Jul 26 00:03 movi_partition.patch -rwxr-xr-x 1 gr gr 1894 Jul 26 00:03 sd_fusing.1M.sh* -rw-r--r-- 1 gr gr 262144 Jul 26 00:03 tzsw.bin.hardkernel thanks!

yeah! probably Ubuntu is packaging overlayfs properly. Mark Shuttleworth is Space Noah anyway It might be an Armbian usecase but we need to yell louder to see if someone in the forum has the knowledge and time to help.

humm... unless you are named Noah, nothing happens automagically

I know almost nothing on overlayfs https://spin.atomicobject.com/2015/03/10/protecting-ubuntu-root-filesystem/ I don't know your usage / usecase but you may need tweaking your initrd/initramfs