Jump to content

Moving Linux to SATA or external drive


Recommended Posts

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

@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").

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines