[Solved] WD MyBook Live Duo / two disks

Installing and Using OpenWrt
81

Hello,

sorry for the late reply.
Indeed, I had verified with the status page that the model (duo) and version was correct.

Regarding the packages, I do not care about automatic installation. I was only referring to them in the context of troubleshooting steps that I performed.

Finally, the usb device is not a flash disk. It is a usb-parallel port adapter, used as part of a home automation project ( I read a couple of status bits). It used to work fine on 18.06.0 .

It is also interesting that in the startup logs of 18.06.1, if I run logread | grep -i usb does not come up with any driver initialization, hub enumeration etc. (as was the case on 18.06.0) so I believe usb storage would not work either.

At the moment, because of these issues I am back to 18.06.0 but I am more than happy to update again in order to troubleshoot together. Has any other forum member upgraded to 18.06.1 to share their experiences with USB? Do you think it is a good idea to open another thread for this issue?

Thanks again

82

I just found time and, more importantly, a spare hard disk to test my MBL Duo here. USB works just fine on 18.06.1. It recognizes the USB interface and a USB stick I inserted:

root@OpenWrt:~# dmesg | grep usb
[    1.020999] usbcore: registered new interface driver usbfs
[    1.026544] usbcore: registered new interface driver hub
[    1.031924] usbcore: registered new device driver usb
[    1.144971] dwc2 4bff80000.usbotg: DWC OTG Controller
[    1.150067] dwc2 4bff80000.usbotg: new USB bus registered, assigned bus number 1
[    1.157474] dwc2 4bff80000.usbotg: irq 35, io mem 0x4bff80000
[    1.177435] usbcore: registered new interface driver usb-storage
[   76.994920] usb 1-1: new high-speed USB device number 2 using dwc2
[   77.180348] usb-storage 1-1:1.0: USB Mass Storage device detected
[   77.187167] scsi host2: usb-storage 1-1:1.0
root@OpenWrt:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='18.06.1'
DISTRIB_REVISION='r7258-5eb055306f'
DISTRIB_TARGET='apm821xx/sata'
DISTRIB_ARCH='powerpc_464fp'
DISTRIB_DESCRIPTION='OpenWrt 18.06.1 r7258-5eb055306f'
DISTRIB_TAINTS=''
83

Very very strange.

Reading your post, I went and installed it again.

wget http://downloads.lede-project.org/releases/18.06.1/targets/apm821xx/sata/openwrt-18.06.1-apm821xx-sata-wd_mybooklive-duo-ext4-rootfs.img.gz
sysupgrade -v openwrt-18.06.1-apm821xx-sata-wd_mybooklive-duo-ext
4-rootfs.img.gz
....
....



**root@RED:~# dmesg | grep usb**
**root@RED:~#**

root@RED:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='18.06.1'
DISTRIB_REVISION='r7258-5eb055306f'
DISTRIB_TARGET='apm821xx/sata'
DISTRIB_ARCH='powerpc_464fp'
DISTRIB_DESCRIPTION='OpenWrt 18.06.1 r7258-5eb055306f'
DISTRIB_TAINTS=''

As I updated remotely, It currently has the usp-parallel dongle connected. Even if the problem only affects my device, why does it not initialize drivers as in your case? usbcore, dwc2 etc?

This is my complete startup log

[    0.000000] bootconsole [udbg0] enabled
[    0.000000] Linux version 4.14.54 (buildbot@crazyhorse) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r7466-6719991)) #0 Mon Jul 16 13:12:19 2018
[    0.000000] Using PowerPC 44x Platform machine description
[    0.000000] Found legacy serial port 0 for /plb/opb/serial@ef600300
[    0.000000]   mem=4ef600300, taddr=4ef600300, irq=0, clk=7407407, speed=0
[    0.000000] -----------------------------------------------------
[    0.000000] phys_mem_size     = 0x10000000
[    0.000000] dcache_bsize      = 0x20
[    0.000000] icache_bsize      = 0x20
[    0.000000] cpu_features      = 0x0000000010100040
[    0.000000]   possible        = 0x0000000030100040
[    0.000000]   always          = 0x0000000000100000
[    0.000000] cpu_user_features = 0x8c008000 0x00000000
[    0.000000] mmu_features      = 0x00000008
[    0.000000] -----------------------------------------------------
[    0.000000] Top of RAM: 0x10000000, Total RAM: 0x10000000
[    0.000000] Memory hole size: 0MB
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000000fffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000000fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000000fffffff]
[    0.000000] On node 0 totalpages: 65536
[    0.000000] free_area_init_node: node 0, pgdat c05d1a30, node_mem_map cfded000
[    0.000000]   DMA zone: 512 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 65536 pages, LIFO batch:15
[    0.000000] MMU: Allocated 1088 bytes of context maps for 255 contexts
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 65024
[    0.000000] Kernel command line: root=/dev/sda2 rw rootfstype=ext4 console=ttyS0,115200
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 253480K/262144K available (4596K kernel code, 208K rwdata, 1032K rodata, 188K init, 243K bss, 8664K reserved, 0K cma-reserved)
[    0.000000] Kernel virtual memory layout:
[    0.000000]   * 0xfffdf000..0xfffff000  : fixmap
[    0.000000]   * 0xfde00000..0xfe000000  : consistent mem
[    0.000000]   * 0xfde00000..0xfde00000  : early ioremap
[    0.000000]   * 0xd1000000..0xfde00000  : vmalloc & ioremap
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
[    0.000000] UIC0 (32 IRQ sources) at DCR 0xc0
[    0.000000] UIC1 (32 IRQ sources) at DCR 0xd0
[    0.000000] UIC2 (32 IRQ sources) at DCR 0xe0
[    0.000000] UIC3 (32 IRQ sources) at DCR 0xf0
[    0.000000] time_init: decrementer frequency = 800.000008 MHz
[    0.000000] time_init: processor frequency   = 800.000008 MHz
[    0.000015] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0xb881274fa3, max_idle_ns: 440795210636 ns
[    0.010284] clocksource: timebase mult[1400000] shift[24] registered
[    0.016593] clockevent: decrementer mult[ccccccef] shift[32] cpu[0]
[    0.022861] pid_max: default: 32768 minimum: 301
[    0.027537] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.034063] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.044121] random: get_random_u32 called from bucket_table_alloc+0x1a4/0x1f8 with crng_init=0
[    0.052941] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[    0.062608] futex hash table entries: 256 (order: -1, 3072 bytes)
[    0.069462] NET: Registered protocol family 16
[    0.076062] PPC4XX OCM1: 32768 Bytes (enabled)
[    0.080420] PPC4XX OCM1: 32768 Bytes (non-cached)
[    0.085081] PPC4XX OCM1: 0 Bytes (cached)
[    0.089116] debugfs ppc4xx ocm: failed to create file
[    0.094250] 256k L2-cache enabled
[    0.097564] PCIE0: Port disabled via device-tree
[    0.102741] PCI: Probing PCI hardware
[    0.115156] SCSI subsystem initialized
[    0.119313] libata version 3.00 loaded.
[    0.124702] clocksource: Switched to clocksource timebase
[    0.130665] NET: Registered protocol family 2
[    0.135407] TCP established hash table entries: 2048 (order: 1, 8192 bytes)
[    0.142300] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[    0.148588] TCP: Hash tables configured (established 2048 bind 2048)
[    0.154962] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.160718] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.167042] NET: Registered protocol family 1
[    0.171334] PCI: CLS 0 bytes, default 32
[    0.177969] dw_dmac 4bffd0800.dma: DesignWare DMA Controller, 2 channels
[    0.188873] Crashlog allocated RAM at address 0x3f00000
[    0.194549] workingset: timestamp_bits=30 max_order=16 bucket_order=0
[    0.204937] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.219518] io scheduler noop registered
[    0.223369] io scheduler deadline registered (default)
[    0.228746] GPIO line 472 (enable EMAC PHY) hogged as output/low
[    0.234661] GPIO line 473 (Enable Reset Button, disable NOR) hogged as output/low
[    0.242086] GPIO line 474 (Power USB Core) hogged as output/low
[    0.247960] GPIO line 475 (Power Drive Port 1) hogged as output/low
[    0.254180] GPIO line 479 (Power Drive Port 0) hogged as output/low
[    0.261180] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
[    0.269220] console [ttyS0] disabled
[    0.292810] serial8250.0: ttyS0 at MMIO 0x4ef600300 (irq = 19, base_baud = 462962) is a U6_16550A
[    0.301593] console [ttyS0] enabled
[    0.308487] bootconsole [udbg0] disabled
[    0.316798] console [ttyS0] disabled
[    0.320405] 4ef600300.serial: ttyS0 at MMIO 0x4ef600300 (irq = 19, base_baud = 462962) is a 16550
[    0.320424] console [ttyS0] enabled
[    0.324393] sata-dwc 4bffd1000.sata: id 0, controller version 1.91
[    0.334323] scsi host0: sata-dwc
[    0.337810] ata1: SATA max UDMA/133 irq 33
[    0.342030] sata-dwc 4bffd1800.sata: id 0, controller version 1.91
[    0.349146] scsi host1: sata-dwc
[    0.352557] ata2: SATA max UDMA/133 irq 34
[    0.357083] of-flash 4fff80000.nor_flash: do_map_probe() failed for type cfi_probe
[    0.365294] of-flash 4fff80000.nor_flash: do_map_probe() failed
[    0.371853] libphy: Fixed MDIO Bus: probed
[    0.375954] PPC 4xx OCP EMAC driver, version 3.54
[    0.380947] MAL v2 /plb/mcmal, 1 TX channels, 1 RX channels
[    0.386689] RGMII /plb/opb/emac-rgmii@ef601500 initialized with MDIO support
[    0.393849] TAH /plb/opb/emac-tah@ef601350 initialized
[    0.399283] /plb/opb/emac-rgmii@ef601500: input 0 in rgmii mode
[    0.405299] libphy: emac_mdio: probed
[    0.521454] eth0: EMAC-0 /plb/opb/ethernet@ef600c00, MAC 00:90:a9:3d:89:94
[    0.528325] eth0: found Broadcom BCM50610 PHY (0x01)
[    0.533350] i2c /dev entries driver
[    0.536938] booke_wdt: powerpc book-e watchdog driver loaded
[    0.543016] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: dm-devel@redhat.com
[    0.554592] NET: Registered protocol family 10
[    0.560547] Segment Routing with IPv6
[    0.564299] NET: Registered protocol family 17
[    0.568770] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[    0.581681] 8021q: 802.1Q VLAN Support v1.8
[    0.687477] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    0.696072] ata1.00: ATA-9: WDC WD20EFRX-68EUZN0, 80.00A80, max UDMA/133
[    0.702767] ata1.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 1/32)
[    0.711893] ata1.00: configured for UDMA/133
[    0.716208] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    0.722835] scsi 0:0:0:0: Direct-Access     ATA      WDC WD20EFRX-68E 0A80 PQ: 0 ANSI: 5
[    0.731995] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[    0.739730] sd 0:0:0:0: [sda] 4096-byte physical blocks
[    0.745007] ata2.00: ATA-8: WDC WD1002FBYS-02A6B0, 03.00C06, max UDMA/133
[    0.751789] ata2.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 1/32)
[    0.758990] sd 0:0:0:0: [sda] Write Protect is off
[    0.763786] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    0.769078] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    0.779007] ata2.00: configured for UDMA/133
[    0.783543] scsi 1:0:0:0: Direct-Access     ATA      WDC WD1002FBYS-0 0C06 PQ: 0 ANSI: 5
[    0.792997] sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[    0.800979] sd 1:0:0:0: [sdb] Write Protect is off
[    0.805773] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    0.810900] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    0.853068]  sdb: sdb1 sdb2 sdb3
[    0.857433] sd 1:0:0:0: [sdb] Attached SCSI disk
[    1.404993]  sda: sda1 sda2
[    1.408745] sd 0:0:0:0: [sda] Attached SCSI disk
[    1.413433] md: Waiting for all devices to be available before autodetect
[    1.420209] md: If you don't use raid, use raid=noautodetect
[    1.426248] md: Autodetecting RAID arrays.
[    1.430350] md: autorun ...
[    1.433132] md: ... autorun DONE.
[    1.462439] EXT4-fs (sda2): mounted filesystem without journal. Opts: (null)
[    1.469533] VFS: Mounted root (ext4 filesystem) on device 8:2.
[    1.476118] Freeing unused kernel memory: 188K
[    1.541242] init: Console is alive
[    1.544816] init: - watchdog -
[    1.558450] init: - preinit -
[    1.607560] random: fast init done
[    1.699786] eth0: link is down
[    1.703288] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    2.111084] eth0: link is up, 100 FDX
[    2.114792] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[    4.792655] mount_root: mounting /dev/root
[    4.806520] EXT4-fs (sda2): re-mounted. Opts: (null)
[    4.811670] mount_root: loading kmods from internal overlay
[    4.822369] mount_root: failed to launch kmodloader from internal overlay
[    5.112172] block: attempting to load /etc/config/fstab
[    5.117766] random: crng init done
[    5.121292] block: unable to load configuration (fstab: Entry not found)
[    5.128035] block: no usable configuration
[    5.187012] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
[    5.247287] urandom-seed: Seed file not found (/etc/urandom.seed)
[    5.276487] procd: - early -
[    5.279465] procd: - watchdog -
[    5.821764] EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts:
[    5.829091] procd: - watchdog -
[    5.832428] procd: - ubus -
[    5.886671] procd: - init -
[    9.702221] eth0: link is up, 100 FDX
[    9.718085] br-lan: port 1(eth0) entered blocking state
[    9.723318] br-lan: port 1(eth0) entered disabled state
[    9.728781] device eth0 entered promiscuous mode
[    9.754452] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
[   10.750781] br-lan: port 1(eth0) entered blocking state
[   10.756011] br-lan: port 1(eth0) entered forwarding state
[   10.771228] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready

I just downgraded to 18.06.0 and these are the results (clean system - no additional packages installed)

OpenWrt 18.06.0, r7188-b0b5c64c22

root@RED:~# dmesg | grep usb
[    1.612931] usbcore: registered new interface driver usbfs
[    1.618480] usbcore: registered new interface driver hub
[    1.623853] usbcore: registered new device driver usb
[    1.736745] dwc2 4bff80000.usbotg: DWC OTG Controller
[    1.741838] dwc2 4bff80000.usbotg: new USB bus registered, assigned bus number 1
[    1.749248] dwc2 4bff80000.usbotg: irq 35, io mem 0x4bff80000
[    1.769335] usbcore: registered new interface driver usb-storage
[    2.140679] usb 1-1: new full-speed USB device number 2 using dwc2
root@RED:~#


And when I install usblp drivers, I also get the two additional lines

[    6.477534] usblp 1-1:1.0: usblp0: USB Bidirectional printer dev 2 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
[    6.487378] usbcore: registered new interface driver usblp
84

I honestly have no idea. The only differences are that
a) I had nothing USB connected at startup, and
b) I have only one drive connected
But I can't imagine why that would make a difference. Worth testing, though.

Edit: Didn't make any difference.

85

Here's a thought, though: Do you have OpenWrt installed on both of your drives?

If so, that would bring up an interesting problem noone has thought of. As the boot script works right now, uboot loads kernel and dtb from SATA 1:1, but root (and generally, /dev/sda) will be on SATA 0:1. That's not an issue as long as both disks have the same OpenWrt version.

However, sysupgrade would upgrade the partitions on SATA 0:1 (/dev/sda), but never kernel and dtb on SATA 1:1 (/dev/sdb). Which means you would boot a different (non-upgraded) kernel, and the (upgraded) root would not match anymore.

@chunkeey: This could probably be quite simply remedied by swapping the order of 1:1 and 0:1 in the boot script so it tries 0:1 first. I just don't know how this would behave with the MBL Single then, as it has its single disk on 1:1. MBL Single wouldn't care and after extload 0:1 invariably lead to a "Bad partition 1" error message continue with 1:1.

1 Like
86

I believe you are right.

I am updating again with only one drive and report back.

BINGO!!! That was it. Indeed I had openwrt 18.06.0 on one secondary disk and 18.06.1 on the primary/master !

With only one disk usb works fine! Thanks

But why did it load kernel from the boot disk (ata1.00: ATA-9: WDC WD20EFRX-68EUZN0 in my case) and boot partition from my secondary drive?

87

Because on hardware level the right drive bay is actually the first SATA port, the left bay is the second port. All of WD's system has been written "ass backwards" to do everything from the second "left" port first, including the boot script that loads the system. As soon as OpenWrt is loaded, the drives are numbered as they appear on hardware, i.e. the right drive is the correct "primary" one.

Noone thought of the implications there, probably you're the first one to sysupgrade on a Duo with two OpenWrt drives.

The easiest -- albeit intermediate -- fix right now would be to update the second drive to 18.06.1, too. (Or maybe wait a few days, 18.06.2 is in the making.) You can just take out any disk and the Duo will boot from the remaining one.

88

Takimata thanks once again.

Since my mybook live does not do much production work, I will leave it without the second drive for now.
The reason I mostly need openwrt on the 2nd drive is for recovery in case I screw up.

Regarding a proper fix, you seem to know the issue in detail. Tell me if you need help with proposing a patch/fix/bug report. At the moment the boot process on this device is not intuitive.

89

I know my way around stuff, but I'm really not an expert at all. Mostly I find things and then regurgitate them in front of a capable dev. I'm really the worst. :wink:

At the moment, there is already another commit in master that touches the My Book (Duo) target. Maybe we should fix this issue in the boot script and try to get both cherry picked for 18.06.2, what do you think, @chunkeey?

90

I submitted the change and a pull request via github.

2 Likes
91

@takimata thank you for going the official route.
As for the issue at hand, it might also be a good idea to just do what the x86/x86_64 target already does: use UUID.

But this is a little more complicated, as it does involve making a template for the mbl_boot.scr code and then supply the UUID as a kernel cmdline parameter.

92

I should look into UUIDs, I really can't comment on that one yet. But it sounds like for the moment we're good with the boot process confined the actual boot disk without that mix&match going on anymore.

At any rate, we should probably lobby to get this change into release, preferrably in order for 18.06.2 (which, although it hasn't been tagged yet, should be soon due to the busybox-related CVE mitigations). I think this would also require to get at least the "unification" cherry-picked, and probably a handful of other patches, too, no?

1 Like
93

From past experiences I can tell that there is usually no need to lobby. My understanding is, that just nobody with commit access to the OpenWrt-18.06 repository uses a MBL. I tried to give away some MBL-Kits (i.e. MBL Single PCB with case. But no HDD or PSU), but nobody wanted them :slightly_frowning_face: .

So of course none of the current committer knows what patches to take or not. However, they will gladly backport patches as long as they have been "tested" in the master repository for a while and apply cleanly, didn't cause build issues and most importunately "fix something important".

In theory, the simplest way to ask them would be to piggyback on the 18.06.1 release email with a list of the commits to backport from master. Of course, you could also make a github PR for the openwrt-18.06 branch (make sure to include 18.06 into the subject/title) with the patches you want. Or alternatively, post the series on the ML with a [for openwrt-18.06] tag in the subject.

Please do. From my understanding, the x86 target uses the 32bit "disc signature" PARTUUID in the legacy partition table sector to select the "right disc" and pass the "-02" as the partition selector (like the 2 in the MBL's /dev/sda2).

So of course, nobody knows what will happen with the hybrid gpt/mbr case, since this could break. It could be safer to go "full hog" and copy WD firmware behavior by putting the rootfs into a device-manager/mdadm-managed virtual partition. This way, the root cmdline parameter will just be "root=/dev/md0" . (Though, this will require to make a tool that can create and fill a md image. https://raid.wiki.kernel.org/index.php/RAID_superblock_formats )

1 Like
94

Alright, I think I got the gist. I can see that making sense on X86 where multi-boot and consequently a varying rootfs partition is a thing, but not so much with the MBL where realistically you would only ever boot OpenWrt. Sounds like a lot of effort to, in the end, still quite invariably finish up at /dev/sda2.

The thought crossed my mind, too, but I don't know how I feel about that. It seems to me that this would remove a lot of the flexibility that our current "simple" approach offers, and add a lot of overhead to catch all the possible cases of removing/swapping/inserting disks with/without OpenWrt.

Honestly, I think I'm perfectly fine with the way it currently works, with the kinks sorted out (and I believe the boot script was one of the last remaining ones.)

95

My two cents:
The MBLD is used with OpenWrt by only a handful of knowledgeable people (and I don't think it will change drastically...), so this level of sophistication is not needed in the upgrade process.
The solution is simple: copy all system partitions to the second disk after sysupgrade.

dd if=/dev/sda1 of=/dev/sdb1
dd if=/dev/sda2 of=/dev/sdb2
96

I was already thinking of giving this exact advice for a "quick fix", but I was hesitant because, of course, this will also overwrite configuration on the second drive and could lead to a set of problems on their own.

97

I do this regularly to keep the disks in sync.
What kind of problems do you think it could lead to?

98

I think he meant data loss? Both HDDs partition layouts need to be compatible in order to write one partition to the other HDD. So the user has to manually install the OpenWrt image on both. That said, on the duo it should be possible to install the openwrt-18.06 and -master images on either HDD. So switching between devel and stable is just one quick hdd swap away.

(By the way, does anybody know if hot-plugging is supported on the duo's secondary hdd?)

99

Hard to explain in a few words: What I mean is that the secondary disk, even if it contains OpenWrt, even if it contains the same Version of OpenWrt, doesn't necessarily have to contain OpenWrt that is configured for the Duo. Or this Duo. Painting over the installed version on the secondary drive may not be desirable.

I do. It is.

100

Sorry for slightly hijacking the thread but how are you supposed to do a raw install of OpenWrt using master since the image layout changed?
dd the factory image?