On a LIME2 board, after running the olinuxino-sd-to-sata script, what next?

Started by Nate, January 16, 2023, 08:04:02 PM

Previous topic - Next topic

Nate

Back in March of 2022 I was trying to get the SATA drive to be the root partition on a MICRO board with no success: https://www.olimex.com/forum/index.php?topic=8627.msg33269#msg33269

A few years back I bought the Freedombox Pioneer HSK which uses the LIME2 board.  After having a 128GB micro-SD card die on me I want to use an SSD with it.  While waiting for the SSD to arrive I am testing the installation on a SATA laptop HDD I have.

Once again I tried the olinuxino-sd-to-sata script from the latest Olimex Bullseye minimal image, first with the drive not partitioned or formatted and again with it partitioned and formatted from the first run.  Everything seems to go well and the copying is apparently successful but at the end after the Cleanup... line the next line is no spi flash found!!.

Regardless, I tried to boot without the micro-SD card inserted and the board failed to boot, of course.  Booting with the micro-SD card results in the root partition being /dev/mmcblk0p1 instead of /dev/sda1.

Without spi flash available, is it simply not possible to use the SATA disk as the root partition?

Nate

I also attempted this script with the Bullseye base image of 20220928 and get the same result.  Follows is the output of the script:


root@a20-olinuxino:~# olinuxino-sd-to-sata

Detecting board...

Detecting the root device...
Root partition: /dev/mmcblk0p1
Root device: /dev/mmcblk0

Detecting SATA device...
SATA partition: /dev/sda1
SATA device: /dev/sda

Checking disk size...
Required blocks: 5223312
Available blocks: 1953525168

Unmount target device...
umount: /dev/sda1: not mounted.

Copying MBR record...
sfdisk: no disk device specified

Resizing partition...
lsblk: /dev/sda1: not a block device
lsblk: /dev/sda1: not a block device

Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x0352d44d.

Command (m for help): No partition is defined yet!

Command (m for help): 1: unknown command

Command (m for help): Partition type
  p  primary (0 primary, 0 extended, 4 free)
  e  extended (container for logical partitions)
Select (default p): Partition number (1-4, default 1): First sector (2048-1953525167, default 2048): Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-1953525167, default 1953525167):
Created a new partition 1 of type 'Linux' and of size 931.5 GiB.
Partition #1 contains a ext4 signature.

Command (m for help):
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

e2fsck 1.46.2 (28-Feb-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 28375/61054976 files (0.1% non-contiguous), 4295538/244190390 blocks
resize2fs 1.46.2 (28-Feb-2021)
The filesystem is already 244190390 (4k) blocks long.  Nothing to do!


Formating disk...

Copying disk...
  2,943,744,383  99%    5.07MB/s    0:09:14 (xfr#95948, to-chk=0/136646) 

Configuring...

Cleanup...
no spi flash found!!
root@a20-olinuxino:~#

LubOlimex

> Without spi flash available, is it simply not possible to use the SATA disk as the root partition?

It is possible if you use the SD card to store the data that usually goes to the SPI flash but I don't think our script supports it at the moment. But that is the basic idea, use another SD card that can be used for the task. Oh and edit the script to perform it.
Technical support and documentation manager at Olimex

Nate

I ended up resolving this another way.  As the image supplied by the Freedombox folks uses btrfs for its root partition, a bit of searching eventually led me to this thread:

https://www.olimex.com/forum/index.php?topic=7975.msg30691#msg30691

Here I learned about the btrfs replace capability.  It seamlessly moved the data to the HDD (at the moment as the SSD is lost in the mail, apparently) and left a clue on the micro-SD card as to the device the root partition resides.

I did not pursue the Olimex image any further, but I did find mention that all that really needs to be done is to add a line in uenv.txt setting the root partition variable.  It seems as though the script could do that easily enough when SPI flash is not available, but perhaps it is not that simple since the Olimex image is all one partition.