Hello,
I recently got a WD My Book Live Duo and it makes me happy that there is working OpenWrt for this device. I want to use it as a FTP server in local network.
On original HDD I ran OpenWrt without any problem, but I'm not able to run it on WD Blue WD5000AZLX. Is OpenWrt works with any HDD?
Will drive go sleep after some time when not used?
Is there something extraordinary to do or to know comparing to normal OpenWrt setup (except IP address and FTP server)?
You might need to install additional filesystems. By default, OpenWrt only supports the default Linux-oriented filesystems.
My guess with a 500 GB disk (right?) is that it is not formatted with Linux ext2/3/4, and not with vanilla FAT or FAT32 either, but maybe with either EXFAT or NTFS ???
You might need to install kmod-fs-exfat or ntfs-3g, depending of what file system the disk uses.
I wasn't clear enough. I wish to run OpenWrt from WD Blue and when I dd image to drive it goes bootloop
Try dd:ing the dump from the old, to the new drive.
What image did you use?
BTW, blue drives aren't made for NAS usage.
What image did you use?
Official one from OpenWrt site
BTW, blue drives aren't made for NAS usage.
I know 
I have useless WD Blue drive which I want to repurpose in that way (and I don't care about data because it is a 2nd backup) so in case of drive failure I will just upload them again.
This may be caused by a bug that has very recently been found and fixed (tl;dr: the upstream SATA driver had problems with certain drive firmwares, it became apparant with some SSDs). To confirm or disprove try a current snapshot, the fix will be in the next (minor) release versions.
If that doesn't fix it for you it's hard to tell what is really going on, you would have to hook up a serial connection and actually watch the MBL (fail to) boot and see why.
Neither were WD Greens, WD still used them in the single-drive MBLs from factory. Their rationale might have been that this kind of "home NAS" powers down the drives between infrequent periods of use and doesn't actually need or even necessarily benefit from NAS-grade drives rated for 24/7 constant operation.
And they were not entirely wrong: In 10+ years of use -- half a decade with the original firmware, the other half with OpenWrt -- I haven't had a single WD Green in any of my multiple MBLs fail on me. I wouldn't rely on them for anything critical or non-redundant of course, especially given their age, but in the same vein any disk can fail and I similarly wouldn't trust a single NAS-grade disk with irreplaceble data. And I realize I'm rambling, sorry.
This may be caused by a bug that has very recently been found and fixed (tl;dr: the upstream SATA driver had problems with certain drive firmwares, it became apparant with some SSDs). To confirm or disprove try a current snapshot, the fix will be in the next (minor) release versions.
It didn't help, but at Tuesday I will have another drive so I will test it again.
Neither were WD Greens, WD still used them in the single-drive MBLs from factory. Their rationale might have been that this kind of "home NAS" powers down the drives between infrequent periods of use and doesn't actually need or even necessarily benefit from NAS-grade drives rated for 24/7 constant operation.
And they were not entirely wrong: In 10+ years of use -- half a decade with the original firmware, the other half with OpenWrt -- I haven't had a single WD Green in any of my multiple MBLs fail on me. I wouldn't rely on them for anything critical or non-redundant of course, especially given their age, but in the same vein any disk can fail and I similarly wouldn't trust a single NAS-grade disk with irreplaceble data. And I realize I'm rambling, sorry.
It's my observation too. There is nothing wrong in use ordinary disks at home or small office. I'm a bit old fashion and I skip all these fancy bouncy features like home media hub or private cloud (which in my opinion are very dangerous eg.: WD and vulnerability CVE-2021-35941) and I'm setting up this like local file server for encrypted backups so I need this disk daily for short time.
So I tested with new drive (WD WD5000AZRZ) which differs from previous only in rpm's (5400 instead 7200). I can confirm that Openwrt 21.02 (not a snapshot) runs from first try.
But I found another glich. I have two same drives. Both are new. I put boot drive in B and clean drive in A and Openwrt booted. I set up Samba shares and I started to copy data. Every thing went smooth for more or less 200GB after that MBLD hangs up. After restart MBLD didn't boot up (solid yellow LED). When I removed drive A it boots up. What I also found is that when I hot plug drive A it's mounted and I can put data on it but MBLD is not booting. Any solution for that?
Partitions are:
/dev/sda1 * 8192 24575 16384 8M 83 Linux
/dev/sda2 32768 245759 212992 104M 83 Linux
/dev/sda3 860160 976773119 975912960 465.4G 83 Linux
/dev/sdb1 2048 976773134 976771087 465.8G Linux```Not being condescending, just making sure because this needs to be absolutely correct for OpenWrt when we talk about "Drive A" and "Drive B":
Drive B -- as shown in this diagram: the right handside one -- needs to have the disk that contains OpenWrt.
I confirm that my drive B is drive B from yours picture
Alright, alright. (rummages and gets out a few hard disks and the serial dongle)
Yeaaah, I see the problem. uboot is trying to load /boot/boot.scr from sdb1 which obviously will not be there on a blank disk. [expletive deleted] WD and their insistence to have the two drive numbered backwards, down to the boot parameters. Although I'm actually surprised that neither I nor anyone else in the last years ran into this obvious problem, even by accident.
The uboot song and dance goes like this:
bootcmd=run boot_sata_script_ap2nc
↓ runs
boot_sata_script_ap2nc=run load_boot_ap2nc; source 100000
↓ runs
load_boot_ap2nc=echo ----- Checking Boot Partitions -----;if run lbf1;then echo 1:1;elif run lbf2;then echo 0:1;elif run lbf3;then echo 1:2;elif run lbf4;then echo 0:2; fi
↓ runs (in order)
lbf1=sata init; ext2load sata 1:1 100000 /boot/boot.scr
lbf2=sata init; ext2load sata 0:1 100000 /boot/boot.scr
lbf3=sata init; ext2load sata 1:2 100000 /boot/boot.scr
lbf4=sata init; ext2load sata 0:2 100000 /boot/boot.scr
What I'm a bit surprised now is that if the partition exists, just not the file, or if the partition is anything but ext2 ... the ext2loadattempt in the first line apparantly doesn't error or time out, it just sits there confused. Which makes it a rather shitty fallback mechanism. I guess WD never expected anyone to shove anything but a completely uninitialized or a properly MBL-initialized disk in there.
Anyway, at this point there's two solutions to your problem:
a) put OpenWrt on the second disk, too. I would argue this is a very sensible option anyway, OpenWrt does not take up that much space and you afterwards have the option of booting off that disk without reformatting it first. You can leave OpenWrt on that disk unconfigured, it will never actually boot, the MBL will just take the boot.scr file and continue booting from the disk in drive B.
b) change the uboot script
This is a bit more involved. I actually once wrote a much, much simpler boot script than the one MBL uses:
setenv boot_owrt 'echo -- SATA init; sata init; if run boot_owrt_01; then echo -- found boot.scr on 0:1; source 100000; elif run boot_owrt_11; then echo -- found boot.scr on 1:1; source 100000; else echo -- boot.scr not found on any disk!; fi'
setenv boot_owrt_01 'echo -- searching boot.scr on 0:1; ext2load sata 0:1 100000 /boot/boot.scr'
setenv boot_owrt_11 'echo -- searching boot.scr on 1:1; ext2load sata 1:1 100000 /boot/boot.scr'
setenv bootcmd 'run boot_owrt'
Or, if you want it to be as short as possible, without a fallback to booting OpenWrt from a single drive in Drive A:
setenv bootcmd 'sata init; ext2load sata 0:1 100000 /boot/boot.scr; source 100000'
setenv requires serial access to the uboot console. If you don't have that, you can probably do it via fw_setenv in the uboot-envtools package, but I can't help with that since I've actually never done that myself.
As for
I don't have any idea why that would be. It's certainly not related to the boot problem.
Wow, thanks for so long explanation
I will try what you wrote tomorrow or ... when I won't be able to boot MBLD again because meantime I found that drive B was MBR and drive A was set GPT. I used to use Openwrt for routers only not for NASes. So my though was that's wrong. So I removed drive A, deleted partition and put drive again in MBLD and it booted. This time I made MBR partition (I don't know why previously I made GPT) and I booted few times MBLD and it always booted up. Now I left it with uploading data so at the morning I will come back with tests.
Thanks again
I didn't experiment much, there's obviously conditions in which ext2load will error out, as expected by the boot script subsequently trying the next partition. In other conditions it will get stuck as observed.
... is not the reason though, I tried with both disks as MBR, and ext2load still got stuck.
I don't know what the conditions for getting stuck actually are, and I'm certainly not investing a lot of time reversing uboot sources to maybe possibly find out. Trying to read boot.scr first from sata 0:1 or simply putting boot.scr on all disks reliably removes the problem.
Just FYI I uploaded almost 300GB of data to each drive and MLBD didn't hang up, I rebooted device few times and it's always boot up and all partitions are visible. I think there is no need to spend more time on it. Thank you for your help.
BTW because I see that you mastered MLBD 
Could you wrote me:
Far from it, I just know my way around it a little bit. Mostly simply because I spent a lot of time with it.
Doesn't matter much if your MBL is in your LAN, the firewall will never actually firewall anything. You can safely disable it.
What matters though: you should disable the DHCP servers (dnsmasq and odhcpd), you really don't want another host in your network giving out IP addresses and stepping on the main router's toes.
Honestly, don't know.
Possible? Absolutely. Available? Don't know. Do I want to program that? No.
I am aware of that but I don't have dnsmasq and odhcpd even installed
I didn't expect that you will program it
I forked this old project from github and if I will find a bit of time I will try to update it to current LUCI and Openwrt.