Dual boot from ssd?

Software
1

In preparation for the release of the 4.0 firmware, I configured the Omnia to run from the ssd card I plugged in years ago. I partitioned it into 2 to allow two OS versions with the current setup running off /dev/sda1.

I’m assuming I can do the following:

  1. Copy the running system ( likely via a schnapps created medkit for consistency ) to /dev/sda2 after prepping that with a btrfs FS. At this point, I could use the 4.0 medkit to install the latest test version too.
  2. update the bootloader scsiboot script to use ‘btrload scsi 0:2’ for both the kernel image and the device tree loads
  3. update bootargs with root=/dev/sda2
  4. Reboot…

At this point, the router should boot from the second partition of the ssd. This gives me a solid, easily recoverable working image by setting the bootloader arguments back to default and a playground for testing 4.0.

Am I missing something? I’m assuming if I ever ran the 4 led recovery, it would write all over my bootenv and set me back to an mmc boot.

Thanks

2

GPT is not supported in the current OpenWRT / TOS implementation of u-boot.

It does not reset the boot env to default, least the last time I did that, i.e. it will still boot the last set device/partition.

3

It might not be officially supported but does work. I am running TurrisOS 3 right now from an ssd formatted with GPT just fine.

4

Tried GPT on SSD and USB and neither boots, only MBR. Thus surprised that it works your end.

5

Mine is booting from the SSD. My question was about booting from the second partition of the same drive. I don’t see why it won’t work since ‘scsi 0:1’ means first device, first partition so scsi 0:2 should be interpreted as first device, second partition. I partitioned the ssd with fdisk. Time to try the second partition :slight_smile:

6

which is just userland and can specify different partition table types and it would seem that MBR been used then since

or else with GPT it would be expected to fail.

That should work, suppose you changed both scsi 0:X stanzas. On my node it works that way just fine on a USB drive with 4 partitions, switching between installations from ssh cli with fw_setenv -s /path/to/script/file

Suppose it does not make a difference whether the second partition on your node’s SDD is a primary or logical volume but perhaps check.

7

Yep, will try when my user population ( the wife ) is asleep to avoid any interruption to her network access. The filesystem on the /dev/sda2 is all set and loaded with the most recent 4.0 medkit. I have a number of VLANs in the house and the WLAN one is plugged into eth2. I’m assuming that with 4.0, I’ll need to move that to an eth1.x tag. I’ll boot into 4.0, take a look and boot back into 3 while I configure the 4.0 to match the house set up.

8

There is a bit of change with TOS4.x in the port layout/scheme - there are forum posts about it, also about VLAN management.

9

The uboot package in the turris repo (https://gitlab.labs.nic.cz/turris/openwrt/blob/test/package/boot/uboot-turris-omnia/Makefile#L43) references https://gitlab.labs.nic.cz/turris/turris-omnia-uboot/blob/master/configs/db-88f6820-gp_defconfig.

When comparing it to the build config of a chromebook for example https://source.codeaurora.org/external/qoriq/qoriq-components/u-boot/tree/configs/chromebook_speedy_defconfig?h=git.denx.de/WIP/01Sep2019 you can see that the turris version is missing the option CONFIG_CMD_GPT=y which seems to be responsible for compiling the gpt program in uboot.

1 Like
10

Thanks for pointing that out. Just wondering how you get your node to boot then from a GPT volume but not working on my node :thinking:

There is probably a bunch of other necessary conf missing

CONFIG_CMD_GPT
CONFIG_EFI_PARTITION
CONFIG_PARTITION_UUIDS
11

Mine’s working because I used fdisk rather than gdisk and used MBR. It’s only a 64GB SSD so not hindered by the limits of MBR.

Now that 4.0 is out, I’ll proceed with getting that up and running on the second partition although it will need to wait a while due to work commitments and travel.

12

Do this on the same partition, but different subvolumes.
You can change boot subvolume using u-boot variables, even from running system via fw_setenv.
The only problem can be with schnapps. I have no idea if it will work as expected (propably there will be common pool of backups).

13

Thanks - the different subvolumes could be interesting. I discovered that the dual boot wasn’t working off the two SSD partitions after all, or at least that’s what it looks like.

I had been using the same image, copied to the two partitions and what appeared to be happening was the root device was changing fine but the kernel was coming from the same partition each time, regardless of the bootcmd settings. When I medkitted 4.0 onto the device, it went to the eMMC ( no probs there ) and this boots fine. Booting from the SSD also works fine for the first partition. When I moved the eMMC contents to the second partition and changed the root device to /dev/sda2 as well as scsi device 0:2 , the router booted but the network failed to start due to the devices being incorrect ( lan0,1,2,3 etc were not created when booted from the SSD )which indicated either an incorrect kernel or DTB. If I pull the kernel from the eMMC but mount root from /dev/sda2 ( where I copied the eMMC too), all is good. If I boot wholly from /dev/sda1, I boot correctly into version 3 of the OS. So, it looks like the partition of the scsi boot isn’t being honored. Having migrated successfully to 4.0 over the weekend, this is much less of an issue but it would be great to have full support for multiple partitions on an SSD. At some point, I’ll move the contents of sda2 and the eMMC into a unified partition on the SSD and boot fully from that to simplify updates. Right now, any kernel changes will need to be manually copied back to the eMMC before a reboot.