lauhub

Yes I completely erased the eMMC and re-installed everything: it now works As I have modified partitions I may have destroyed something while using fdisk with a wrong value I noticed that the first sector of boot partition had changed to 8192 Is there a reason for that ? Is it still a right way to re-install u-boot using the following command ? dd if=/usr/lib/linux-u-boot-next-lime2_5.35_armhf/u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1k seek=8

Thanks for your answer No it is 4.13.x kernel compiled on November 29

After creating my own initramfs using this command from a chroot-ed environment sudo update-initramfs -t -u -k `uname -r` And rebooting, I get the following error: Found U-Boot script /boot/boot.scr 3708 bytes read in 126 ms (28.3 KiB/s) ## Executing script at 43100000 U-boot loaded from eMMC or secondary SD Boot script loaded from mmc 202 bytes read in 80 ms (2 KiB/s) 5731772 bytes read in 668 ms (8.2 MiB/s) 6790944 bytes read in 759 ms (8.5 MiB/s) Found legacy kernel configuration ** File not found /boot/script.bin ** ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 5731708 Bytes = 5.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK EHCI failed to shut down host controller. Loading Ramdisk to 49a88000, end 49fff57c ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Error: unrecognized/unsupported machine ID (r1 = 0x42000820). Available machine support: ID (hex) NAME ffffffff Generic DT based system ffffffff Allwinner sun9i Family ffffffff Allwinner sun8i Family ffffffff Allwinner sun7i (A20) Family ffffffff Allwinner sun6i (A31) Family ffffffff Allwinner sun4i/sun5i Families Please check your kernel config and/or bootloader. I chroot from a SD card with Armbian 5.35.installed to a eMMC with armbian 5.35 installed, with an encrypted LUKS partition (and a boot ext4 partition containing my boot files, including the initramfs). I am missing something but could not find it. What is the right way to update initrd ?

Hi, I had the same issue with the ARMBIAN_MAINLINE_KERNEL_VERSION variable which has to be replaced by KERNELBRANCH. This is not in armbian documentation and there is still the ARMBIAN_MAINLINE_KERNEL_VERSION in configuration.sh file although it is not used in other scripts. And I still have the same problem about the patches : I need to compile back to the 4.9 kernel's version but ran in an error because current patches are for 4.13 branch. My questions are : where are the patches for lime2-emmc (and other boards) ? how can I download them (a branch/tab on armbian build tool or somewhere) ? where can be found documentation about this (where is a patch, the tag/versioning policy) ? A subsidiary question (out of this topic): how to disable any auto-update feature in order that when one can come back in six months one not have to re-configure everything ?

Hi, Thanks for this answer. Do I need to apply the patch before trying ethtool ? And what are the parameters for "Fast" ethernet mode ?

SOLVED The problem did not come from software nor installation: it is a hardware related problem I tested on another board of the same revision: everything works, network, IP, etc I made my tests with several Armbian builds on different SD/eMMC Sorry for the inconvenience

I managed to compile without RTL8211X_PHY_FORCE_MASTER enabled by: removing the add-lime2-emmc.patch sudo mv lib/patch/u-boot/u-boot-sunxi/add-lime2-emmc.patch lib/patch/u-boot/u-boot-sunxi/add-lime2-emmc.patch.disabled editing the existing (or creating) configs/A20-OLinuXino-Lime2-eMMC_defconfig file and setting CONFIG_RTL8211X_PHY_FORCE_MASTER=n running compile.sh with FORCE_CHECKOUT=no But, I still do not have network. So now I wonder where to search

Hi again, I think I have found what is not working, but I do not manage to achieve it : I need to re-compile u-boot According to this message I need to disable CONFIG_RTL8211X_PHY_FORCE_MASTER which is enabled in current u-boot configuration for A20 Lime2 eMMC This gives me the following patch: diff --git a/configs/A20-OLinuXino-Lime2_defconfig b/configs/A20-OLinuXino-Lime2_defconfig index 8fd7c64..96d9d0e 100644 --- a/configs/A20-OLinuXino-Lime2_defconfig +++ b/configs/A20-OLinuXino-Lime2_defconfig @@ -17,7 +17,7 @@ CONFIG_CMD_DFU=y CONFIG_CMD_USB_MASS_STORAGE=y # CONFIG_CMD_FPGA is not set CONFIG_DFU_RAM=y -CONFIG_RTL8211X_PHY_FORCE_MASTER=y +CONFIG_RTL8211X_PHY_FORCE_MASTER=n CONFIG_ETH_DESIGNWARE=y CONFIG_AXP_ALDO3_VOLT=2800 CONFIG_AXP_ALDO4_VOLT=2800 My problem is that it does not seem to be taken into account by u-boot compilation process So the network does not work after boot sector update with freshly compiled u-boot. After compilation I should get a file in /usr/lib/u-boot/A20-OLinuXino-Lime2-eMMC_defconfig that contains the following line: CONFIG_RTL8211X_PHY_FORCE_MASTER=n But all I get is : CONFIG_RTL8211X_PHY_FORCE_MASTER=y I noticed that a file configs/A20-OLinuXino-Lime2-eMMC_defconfig was created besides A20-OLinuXino-Lime2_defconfig I created a second patch for this file, without success. So what is the process to make modification (or patch) for this specific file which seems to be created during compilation process ?

Hello, I received a few weeks ago some new Lime2 boards. Using compiled Armbian kernel leads to a network problem: no IP is set and network does not work I have messages when connecting Ethernet cable: sun7i-dwmac 1c50000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx Link is Up - 100/Full The ip a command gives: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 02:02:02:cc:cc:cc brd ff:ff:ff:ff:ff:ff inet6 fefe::fe:xxx:xxx:9307/64 scope link valid_lft forever preferred_lft forever I think the problem is related to the new revision of the board as described here : Ethernet PHY is changed to RTL8211E replacing the obsolete RTL8211CL no need for kernel patches But searching through the kernel options did not give me any clue, and nothing works. What is to be done to make network up again ? Is there something to reconfigure on an existing armbian installation ? Are there some files to modify ?

Hi, Because all the work I have already done on my current project is based on Jessie

Hi again, I successfully made overlayroot work under Debian Jessie. Ubuntu package I installed overlayroot_0.27ubuntu1.2_all.deb package wget http://fr.archive.ubuntu.com/ubuntu/pool/main/c/cloud-initramfs-tools/overlayroot_0.27ubuntu1.2_all.deb dpkg -i overlayroot_0.27ubuntu1.2_all.deb Correcting overlayfs module name About the following error: Failure: overlayroot: missing kernel module overlayfs I had to modify the /usr/share/initramfs-tools/scripts/init-bottom/overlayroot file: Here is a diff: diff --suppress-common-lines -r -y ./usr/share/initramfs-tools/scripts/init-bottom/overlayroot /usr/share/initramfs-tools/scripts/init-bottom/overlayroot VARIABLES="overlayroot overlayroot_cfgdisk" | VARIABLES="overlayroot overlayroot_cfgdisk overlayroot_driver overlayfs) | overlayfs|overlay) mount_type="overlayfs" | mount_type="overlay" mount_opts="${mount_opts} overlayroot ${ROOTM | mount_opts="${mount_opts} overlay ${ROOTMNT}" mount --move "${ROOTMNT}" "${root_ro}" || | mount -o move "${ROOTMNT}" "${root_ro}" || mount --move ${root_ro} ${ROOTMNT} | mount -o move ${root_ro} ${ROOTMNT} mount --move ${root_ro} "${ROOTMNT}${root_ro}" || | mount -o move ${root_ro} "${ROOTMNT}${root_ro}" || mount --move "${root_rw}" "${ROOTMNT}${root_rw}" || | mount -o move "${root_rw}" "${ROOTMNT}${root_rw}" || As you can see, I added one variable to the VARIABLES list and made some changes to mount parameters. Here is the complete file: I modified the /usr/share/initramfs-tools/hooks/overlayroot: diff --suppress-common-lines -r -y ./usr/share/initramfs-tools/hooks/overlayroot /usr/share/initramfs-tools/hooks/overlayroot manual_add_modules overlayfs | manual_add_modules overlay Configuration I added a file named /etc/overlayroot.local.conf (instead of modifying /etc/overlayroot.conf): overlayroot_cfgdisk="disabled" overlayroot="tmpfs" overlayroot_driver="overlay" Chrooting to R/W Last but not least, I had to modify the overlayroot-chroot executable diff --suppress-common-lines -r -y ./usr/sbin/overlayroot-chroot /usr/sbin/overlayroot-chroot overlay=$(grep -m1 "^overlayroot / overlayfs " /proc/ | overlay=$(grep -m1 "^overlay / overlay " /proc/mounts Fast-forward I attached an archive with the modifications. Using tar zxvf overlayroot-debian-lauhub.tar.gz -C / after package installation should do the trick overlayroot-debian.tar.gz

Hi Chris, I think I found at least a lead to that problem There are some missing parts into the initramfs scripts / configuration problem in boot.cmd. I experienced the same problem with a small difference Investigation To investigate the problem, I modified the /usr/share/initramfs-tools/init first line as follow (shell debug mode): #!/bin/sh -x To correct the problem, I did the following: FIrst bug correction: creating the /root/dev mount point I had to modify the script /usr/share/initramfs-tools/scripts/init-bottom/udev adding a line prior to the mount command: #This line prevents the "mount: No such file or directory" error: mkdir -p ${rootmnt}/dev #The following mount call was leading to "mount: No such file or directory" error #Creating the directory works better # move the /dev tmpfs to the rootfs mount -n -o move /dev ${rootmnt}/dev Second bug: modification of boot.cmd I changed my boot.cmd script. I replaced boot parameters PARTUUID=e8198e69-01 with the UUID value (root=UUID=abcdef-012345-abcdef-123456) My script is (if I remember well) is close to the one you provided: setenv verbosity 7 part uuid ${devtype} ${devnum}:${distro_bootpart} uuid #Old line: #setenv bootargs "console=${console} root="PARTUUID=${uuid}" rw rootwait nomodeset mac_addr=02:8f:06:c0:f4:31 loglevel=${verbosity} ${extended_bootargs}" #New line setenv bootargs "console=${console} root="UUID=6b742ea8-78e6-403f-8558-d57ec67755c4" rw rootwait nomodeset mac_addr=02:8f:06:c0:f4:31 loglevel=${verbosity} ${extended_bootargs}" if load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} /boot/zImage; then if load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} /boot/dtb/${fdtfile}; then if load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}; else bootz ${kernel_addr_r} - ${fdt_addr_r}; fi; fi; fi if load ${devtype} ${devnum}:${distro_bootpart} 0x48000000 /boot/uImage; then if load ${devtype} ${devnum}:${distro_bootpart} 0x43000000 /boot/script.bin; then setenv bootm_boot_mode sec; bootm 0x48000000; fi; fi # Recompile with: # mkimage -C none -A arm -T script -d boot.cmd boot.scr This make my initramfs work. Now, I have to make overlayfs work. Conclusion Two bugs, and two ways to correct the second one. The second way: I think it could be possible to retrieve UUID from PARTUUID in u-boot, but I don't know how to do this. Another way could be to change the scripts/functions script (resolve_device function) by adding the PARTUUID parsing (line 327), and/or the scripts/local (function local_mount_root, line 152 adn 154, replacing "mount" with "mount -f ") EDIT: There is a bug about PARTUUID in Debian BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801154 Version 0.121 of initramfs-tools support PARTUUID

Hi, I yesterday built a new image for my A20-OLinuXino-MICRO board (Armbian 5.17 Jessie with kernel 4.7.3) At first boot, everything worked fine. I could manage to connect through SSH and changed root password and add new user. However, avec adding a Hard Disk (on the SATA connector) and reboot, I could not manage to connect via SSH So I tried the serial (UART) connector. After some tries and a non responding console (I could see no kernel messages at boot to I had to change the verbosity), I finally succeeded in booting with a console prompt on serial connector. But... The keyboard is not responding on that serial connector. After a few tries, I discovered that the problem occurred to be in u-boot too (U-Boot 2016.07-armbian) : before autoboot, typing any key does nothing Hit any key to stop autoboot: 0 I tried with several serial cable (which work fine on other board's connector) I removed the hard disk from SATA connector: same result Below the beginning of my boot.cmd setenv verbosity 7 setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait nomodeset rootfstype=ext4 cgroup_enable=memory swapaccount=1 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sun #the ending of the file is the same as default boot.cmd So I am a little bit out of idea of what is happening there. Is there anything special to activate UART console on A20-OLinuXino-MICRO in u-boot / kernel ?

OK, thanks, I was not fully aware of this That's not good for me but I'll have to deal with it However, I found this page (I am a little bit stubborn when I have something in mind ) which explain how to debootstrap without systemd Can I change/modify the debootstrap process (I believe it is in lib/debootstrap-ng.sh) in order to achieve my aim ? Or is there some configuration file that would allow to do this ? I believe not since I do not see where to put a command like the following one after first stage and before second stage: # sed -i -e 's/systemd systemd-sysv //g' system/debootstrap/required

I do'nt want any systemd dependencies. However, util-linux depends on systemd only if systemd is the default init system. Which is not the case on my system since I disabled systemd: root@lime2:~# apt-cache depends util-linux util-linux Depends: initscripts Depends: lsb-base Depends: tzdata PreDepends: libblkid1 PreDepends: libc6 PreDepends: libmount1 PreDepends: libncurses5 PreDepends: libpam0g PreDepends: libselinux1 PreDepends: libslang2 PreDepends: libsmartcols1 PreDepends: libtinfo5 PreDepends: libuuid1 PreDepends: zlib1g Suggests: dosfstools |Suggests: kbd Suggests: <console-tools> Suggests: util-linux-locales Breaks: bash-completion Breaks: grml-debootstrap Replaces: bash-completion What I would like is to create a Debian with sysvinit as the initial init system (to be sure to avoid the side effects due to disabling systemd afterwards). Because I would like the /boot/ initramdisk files to be completely independent from systemd too (which is not the case) Apparently this allows to use sysvinit during first boot: preseed/late_command="in-target apt-get install -y sysvinit-core" Where should I set this in the armbian build process ?

Thanks, Actually I want ramdisk (initramfs and so on) but with sysvinit (and not systemd). I removed systemd, but initramfs configuration seems to be broken for now. I have an error like : /scripts/init-premount/devpts: line 21: mountpoint: not found So I guess that removing systemd broke something. So I would like to have an initial ram disk correctly configured at system install just for sysvinit. A pre-install parameter could allow Debian to be initially installed without systemd if it is possible to include it in the build process.

Hi, I would like to get a Debian Jessie version without systemd. I already tried to reconfigure an armbian image to remove systemd (There are several topics about this like this one or this discussion). This worked for me except for one important thing: initramfs. When I tried to configure and run my system using initramfs, I get always an error and system stop booting. I would like to know if it is possible to configure the build-tool (compile.sh) to directly create a Jessie image without systemd and with sysvinit. Something like this (as described here): preseed/late_command="in-target apt-get install -y sysvinit-core" Is it possible and what part of the armbian build tool is to be hacked to do this ?

I still have the same problem on some SD cards (even with network connected). Here is another lead I have not time yet to follow: http://blog.jamesrhall.com/2014/04/ubuntu-server-1404-fun.html Apparently, the kernel switches to a video mode that is not seen through serial link. So adding nomodeset could avoid this blocking. I am interested in the link of the other thread you talked about

Hi again, So the kernel is fine, but apparently not the u-boot bootloader. I can boot from SD card fine. But after installation on the NAND, booting from it gives me a ** Unrecognized filesystem type ** error : CPU: Allwinner A10 (SUN4I) Board: Cubieboard I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: SUNXI SD/MMC: 0 Card did not respond to voltage select! MMC init failed Using default environment In: serial Out: serial Err: serial Net: emac Hit any key to stop autoboot: 0 ** Unrecognized filesystem type ** ** File not found boot/uEnv.txt ** ** File not found uEnv.txt ** ** File not found /boot/script.bin ** ** Unrecognized filesystem type ** ** File not found /script.bin ** Calling ''nand info'' from u-boot prompt gives no response. I presume I miss a configuration in u-boot, but I cannot figure out where. I am surprised that the Board detected is Cubietruck although I am running a OLinuXino A10-Lime.

Thank you, I think I found why it did not work: without Ethernet cable connected, the boot process hangs. With the Ethernet cable connected, it works. So I think that the random pool was not enough random without the cable connection. So good news: my SD card is fine !

Thank you for this info, I will try it, hoping that the package version are not too old (initramfs-tools 0.109 under Wheezy, although 0.122 under Ubuntu Xenial). I will try it with Trusty packages as soon as I have some time.

Hi again, Sorry, but it seems that overlayroot package is not available for Debian (package is missing from both Jessie an Wheezy). Seems to be an Ubuntu only package. As I am stuck (for now) to Debian, I have to use my solution.

Thanks, I change hardware from NAND based A20-Lime to eMMC based ones. So I now use 4.x kernel. I will give it a try.

Thank you for this lead. I had forgotten that solution. Overlayfs was not OK for me two years ago, because of my needs of 3.4 kernel with NAND support. At that time, it was not as simple as you indicate (there were some patches, but it gave me some headaches). So I developed my own solution. (it sounds like I re-invented the wheel ) Do you know if there are consequences in term of speed, boot time, reliability, ram footprint (I will run a Java VM (or more on a 1Gb RAM machine)) ?