blindpet Posted October 12, 2015 Posted October 12, 2015 I have several users following my move Linux to SATA on the Banana Pi guide using Armbian with Kernel 4.1 and they are saying that uEnv.txt on the boot partition isn't there. Is this a bug or is the procedure different for armbian? Can you shed any light on this?
Igor Posted October 12, 2015 Posted October 12, 2015 We are using boot scripts (on all images) for several reasons ... The procedure is similar except, boot.cmd need to be translated / compiled to boot.scr (u-boot script format). Maybe it looks like a bit more complicated but you are changing the same thing. root=/dev/mmcblk0p1 to root=/dev/sda1 (for example) Then recompile with: mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Check boot.cmd source: # if you want to boot jessie with systemd: setenv bootargs init=/bin/systemd console=tty1 ... # remember to disable ramlog prior switching to systemd setenv bootargs "console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 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" #-------------------------------------------------------------------------------------------------------------------------------- # Boot loader script to boot with different boot methods for old and new kernel #-------------------------------------------------------------------------------------------------------------------------------- if ext4load mmc 0 0x00000000 /boot/.next || fatload mmc 0 0x00000000 .next then # sunxi mainline kernel #-------------------------------------------------------------------------------------------------------------------------------- ext4load mmc 0 0x49000000 /boot/dtb/${fdtfile} || fatload mmc 0 0x49000000 /dtb/${fdtfile} ext4load mmc 0 0x46000000 /boot/zImage || fatload mmc 0 0x46000000 zImage env set fdt_high ffffffff bootz 0x46000000 - 0x49000000 #-------------------------------------------------------------------------------------------------------------------------------- else # sunxi android kernel #-------------------------------------------------------------------------------------------------------------------------------- ext4load mmc 0 0x43000000 /boot/script.bin || fatload mmc 0 0x43000000 script.bin ext4load mmc 0 0x48000000 /boot/zImage || fatload mmc 0 0x48000000 zImage bootz 0x48000000 #-------------------------------------------------------------------------------------------------------------------------------- fi # Recompile with: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr https://forum.htpcguides.com/thread-Problem-pointing-boot-to-hdd BTW: Bananian also have boot.scr now.
blindpet Posted October 12, 2015 Author Posted October 12, 2015 Thank you Igor. So basically I just have to edit /boot/boot.cmd to point the /dev/sda1 and then recompile to boot.scr format, do I understand you correctly?
Igor Posted October 12, 2015 Posted October 12, 2015 Yes. Further. If you are copying root from SD card check and adjust /etc/fstab if needed.
iot Posted November 2, 2015 Posted November 2, 2015 Hello, many thanks for these perfect armbian distris Igor! They make embedded dev. extremly useful now. Just one question. We started with a 16GB SDCard and the new 4.5 version (Vanilla-kernel). After installation on SDCard we used your Nand/Sata/Usb-script and moved the system to a 32 GB Sata-SSD. Everything works fine. To use smaller SDCards now (only for bootloader & some starting files) we wanted to save the Boot-partition, which usually is a <100MB Fat partition. Unfortunarely there is only one expanded ext4-partition on the SDCard, which can't be used on smaller ones. We guess this comes from your automatic expand function, isn't it? Do you have an idea, how can we make a small bootpartition on SDCard with link to the system on SSD? With best regards iot
Igor Posted November 2, 2015 Posted November 2, 2015 You will need to shrink your partition if you want to move / copy it to smaller SD. It's possible to do that. Check my function for shrinking - I do this in image creation process. https://github.com/igorpecovnik/lib/blob/second/common.sh#L254
iot Posted November 3, 2015 Posted November 3, 2015 Hello Igor, thanks for your fast reply. I realized it manually with fdisk and reloading the partition table with "hdparm -z /dev/mmcblkp0" to shrink the 16GB SDCard to 1.2GB. Compared to the very small FAT-Bootpartion of a Raspbian (60MB) it's still big but enough for a 2GB SDCard. Does a similiar small FAT-Boot-partition exist before your second boot of armbian? If so - maybe it could be exported or copied just before. Thanks for armbian - love it - donated it !!! with best regards iot
Igor Posted November 3, 2015 Posted November 3, 2015 Thanks! No, I use only one EXT4 partition and it can't be much smaller than it is. I left some reserve to avoid troubles @ first run, when size is still small, then it expands to full size.
berturion Posted January 11, 2016 Posted January 11, 2016 Hello Igor, I have a similar question about the rootfs. For now, my armbian boots from an sd card and rootfs is installed on a SATA disk: a 3.5 inch HDD in an box which has an e-sata connector and a USB connector. Now, I use the e-sata connector which is plugged in the cubieboard2 built-in sata connector. And that works. But I detected some ata bus errors in dmesg and syslog that proves my SATA cable or something is broken. So I want to use the USB Connector from the same drive. When plugged in SATA, my drive is in /dev/sda (/dev/sda1 has rootfs, /dev/sda2 is a big partition for data storage). If I plug the same drive in USB, do I need to change something in boot.cmd or /etc/fstab ? Here is my current /etc/fstab: # UNCONFIGURED FSTAB FOR BASE SYSTEM tmpfs /tmp tmpfs nodev,nosuid,size=256M 0 0 /dev/sda1 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 0 /var/swap none swap sw 0 0 /dev/mmcblk0p1 /media/mmc ext4 defaults 0 0 /media/mmc/boot /boot none bind 0 0 Here is my current boot.scr (only relevant line): setenv bootargs "console=tty1 root=/dev/sda1 rootwait rootfstype=ext4 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" Because, I just tried and my cubieboard2 doesn't boot with this disk connected with USB and these untouched files... Thanks.
Igor Posted January 11, 2016 Posted January 11, 2016 If you have only one single USB drive and no SATA attached, your USB drive should be /dev/sda ... of course you need to reboot with USB attached. There is one problem which is related to U-boot. It might stop booting if it detects some (strange) device on USB. In my case it stops if USB keyboard is attached. Are you facing such issue? Where the booting stops? Can you provide some logs?
berturion Posted January 11, 2016 Posted January 11, 2016 So, I connected a screen (it's headless otherwise) and disconnected all other USB devices except the hard drive. When powered, I can hear my hard drive turning on. The boot sequence stops just after the "Starting kernel" sentence. Then, the screen becomes black and my hard drive stops working, I think it's tuning into standby mode. Nothing happens then. What log could I give you ? Since the kernel is not launched, is there any log somewhere ?
Igor Posted January 11, 2016 Posted January 11, 2016 Change loglevel=1 to loglevel=7, recompile boot script and do it again.
berturion Posted January 11, 2016 Posted January 11, 2016 Here is the screen. The process stops after "waiting for root device /dev/sda1"
tkaiser Posted January 11, 2016 Posted January 11, 2016 Which kernel are you using? Is it possible that USB support is built as a module?
zador.blood.stained Posted January 11, 2016 Posted January 11, 2016 Attached dmesg log looks like mainline kernel, and since I see "cubieboard2" on screenshot too, it must be sunxi-next kernel. USB support for it should be built-in, uas built as a module shouldn't affect anything, however sg too is a module, which may be required depending on USB-SATA controller. I would recommend booting fresh armbian system with this kernel and looking for dmesg output and list of loaded modules when you plug your USB HDD.
berturion Posted January 12, 2016 Posted January 12, 2016 Ok, I think I know what is wrong. After moving rootfs from sd card to sata, I deleted most of directories from sd card to save disk space. The goal was to use a 1go sd card. That worked with my sata disk but USB devices were not detected at boot time because of this shrinked sd card. I will try to remove some /usr/share stuff only. Otherwise, do you know which folder I can delete safely in order to preserve boot and save maximum disk space ?
zador.blood.stained Posted January 12, 2016 Posted January 12, 2016 @berturion Only /boot directory is required, since it contains kernel (zImage), DT file and u-boot script (boot.scr). After that kernel mounts new rootfs and doesn't use any other files. Since I think your problems are due to "sg" (CONFIG_CHR_DEV_SG) compiled as a module, I would recommend either waiting for new Armbian kernel release or compiling new kernel yourself ("dev" branch should be stable enough). You'll need CONFIG_CHR_DEV_SG built-in ("y").
berturion Posted January 12, 2016 Posted January 12, 2016 Thanks @zador.blood.stained. I have troubles compiling the kernel for now, due to my linux environment, I suppose. And I can't wait a new one because sata errors are serious. For now, I installed a fresh armbian on a 16Go sd card (a bad class 4 one). I updated the kernel to have the same as I have in my production rootfs and I try to remove maximum of packages to be able to move all things in my existing 1Go sd card. I hope this will work.
berturion Posted January 13, 2016 Posted January 13, 2016 Hello again. I think there really is a bug with linux firmware image next sunxi 4.81 and kernel sunxi 4.3.3 using the nand-sata-install. I've done a fresh install on an 16GB sd card with an usb stick and I have the same issue... I will stick on my first install with the sata disk and wait for an update of the kernel.
tkaiser Posted January 13, 2016 Posted January 13, 2016 Hello again. I think there really is a bug with linux firmware image next sunxi 4.81 and kernel sunxi 4.3.3 using the nand-sata-install. As already pointed out the problem seems to be that SG support (SG --> 'SCSI generic' that is necessary for some USB implementations) is currently built as a module. Modules are stored on the rootfs below /lib/modules. In case the rootfs is not already mounted and the SG module is needed to access the rootfs you're simply lost. And unfortunately this applies to your USB disk and also to your USB thumb drive situation. Again: Either recompile the kernel with CONFIG_CHR_DEV_SG=y instead of a module or wait for the next version. 1
Igor Posted January 13, 2016 Posted January 13, 2016 I just figured out there is something else ... need to look further. I just built 4.4 for CT and try USB install. It does not work ... CONFIG_CHR_DEV_SG=y Edit: SATA install works fine. 1
berturion Posted January 15, 2016 Posted January 15, 2016 Hello, just in case, any news on the USB install issue ?
berturion Posted April 24, 2016 Posted April 24, 2016 Hello, I just re-tried to boot cubieboard with rootfs on external drive using USB it it works now. Although, I want to use UUID of disk in order to be sure the rootfs is correctly found if I plug other USB devices. My u-boot line is now : setenv bootargs "init=/bin/systemd console=tty1 root=PARTUUID=83ce9744-1e54-4191-af69-d7a7fcfeedbe rootwait rootfstype=ext4 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=7" And my fstab has now this line (I commented the /dev/mmcblk0p1... line, rootfs was on sdcard) : UUID=83ce9744-1e54-4191-af69-d7a7fcfeedbe / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 0 The kernel is launching but not Debian. I re-tried with the "/dev/sda1" notation and it works... Is there a problem using UUID ?
Igor Posted April 24, 2016 Posted April 24, 2016 AFAIK you need to use initrd ... which is available on self build images by default or on prebuild images in few days when we will rebuild them all.
zador.blood.stained Posted April 24, 2016 Posted April 24, 2016 @berturion root=PARTUUID=83ce9744-1e54-4191-af69-d7a7fcfeedbe This doesn't look like PARTUUID unless you are using GPT on your USB drive. Partition UUID will work without initrd, while filesystem UUID won't. Look at this output of "blkid" for example: # blkid /dev/sda1: LABEL="share" UUID="25616f82-0842-4af4-aea8-8ee54cf2df9d" TYPE="xfs" PARTUUID="0004cde8-01" /dev/sdb1: LABEL="Red" UUID="4a6e870b-f6f7-4b68-9864-55da3b328a75" TYPE="xfs" PARTLABEL="Red" PARTUUID="dccadf90-01e7-4624-99f9-9858ce11ea8f" /dev/sda is using MBR, /dev/sdb is using GPT. If you are using PARTUUID correctly, please try to get a boot log on serial console and post it here. 1
berturion Posted April 24, 2016 Posted April 24, 2016 AFAIK you need to use initrd ... which is available on self build images by default or on prebuild images in few days when we will rebuild them all. Thanks for this quick reply but I don't know what to do exactly... Install intrd ? Modify boot line ? @zador.blood.stained, I am wrong with my partuuid, you're right. I will try again.
zador.blood.stained Posted April 24, 2016 Posted April 24, 2016 First, boot from SD as usual and check output of "blkid". If your USB drive with rootfs has PARTUUID that looks like this "0004cde8-01", then insert this to your kernel command line in boot.cmd, recompile it and try booting again. 1
berturion Posted April 24, 2016 Posted April 24, 2016 Ok, that works, it was the PARTUUID's fault ! /dev/mmcblk0: PTUUID="0006426d" PTTYPE="dos" /dev/mmcblk0p1: UUID="01bed786-74eb-4262-9f51-1c604e65c951" TYPE="ext4" PARTUUID="0006426d-01" /dev/sda1: UUID="83ce9744-1e54-4191-af69-d7a7fcfeedbe" TYPE="ext4" PARTUUID="000c8dd7-01" /dev/sda2: UUID="20753884-8113-4c2e-a9fe-0e2322f84c16" TYPE="ext4" PARTUUID="000c8dd7-02" I had to use "000c8dd7-01" in my boot env line. My fstab was correct. Thank you
lampra Posted April 26, 2016 Posted April 26, 2016 Ok, that works, it was the PARTUUID's fault ! /dev/mmcblk0: PTUUID="0006426d" PTTYPE="dos" /dev/mmcblk0p1: UUID="01bed786-74eb-4262-9f51-1c604e65c951" TYPE="ext4" PARTUUID="0006426d-01" /dev/sda1: UUID="83ce9744-1e54-4191-af69-d7a7fcfeedbe" TYPE="ext4" PARTUUID="000c8dd7-01" /dev/sda2: UUID="20753884-8113-4c2e-a9fe-0e2322f84c16" TYPE="ext4" PARTUUID="000c8dd7-02" I had to use "000c8dd7-01" in my boot env line. My fstab was correct. Thank you Is this a self build image? I tried yesterday with Armbian_5.04_Cubietruck_Ubuntu_trusty_4.4.3 and I did not manage to boot from usb.
Recommended Posts