Western Digital My Book Live

Just a quick follow-up: I managed to get some love for a rather long standing pull request. Thanks to a new maintainer, gdisk is now back in the snapshot packages feed and will also be available in 18.06.

Have found SATA driver with NCQ support but it's for kernel 4.9
Link to Ewald's GDrive https://drive.google.com/file/d/0B8Nj6R0Fc58pb3hwSWxCcEZVZzA/view
Original topic here https://community.wd.com/t/any-interests-in-kernel-4-0-on-my-book-live/60483/128

Can I preserve the boot sector and keep the data partition if I do it this way:

  1. Extract sysupgrade from https://downloads.openwrt.org/releases/18.06.0-rc1/targets/apm821xx/sata/openwrt-18.06.0-rc1-apm821xx-sata-wd_mybooklive-ext4-rootfs.img.gz,
  2. Overwrite it to currently running LEDE MBL system,
  3. Run the sysupgrade from the running system?

First of all, you don't need to extract (gunzip) the .img.gz file, sysupgrade works just fine with the .gz file. Just move the .gz over to the MBL, or wget it directly on the MBL, or feed it to the web interface (if you have LuCI installed).

And yes, you will keep the data partition. Caveat: If you are currently
a) on 17.04 or a trunk build older than November 2017, and/or
b) using GPT instead of MBR on your disk (mandatory for drives > 2TB)
you will have to restore it because older sysupgrades overwrite MBR with the default one, and they will return the drive to MBR if you are using GPT. In this case, you will have to manually re-create the MBR (using fdisk) or GPT (using gdisk) partition table. So it would be smart to note the partition table layout before upgrading.

Do I need to tear down the MBL and connect to PC' SATA interface in order to manually re-create MBR/GPT?

My plan is to overwrite the "sysupgrade" file extracted from 18.06 img on top of "sysupgrade" file on a system running 17.04, then doing upgrade without a hassle of disassembling the unit then run fdisk/gdisk on it.

If I understand it right, "sysupgrade" file from LEDE 17.04 will not able to keep the boot sector along with its data partition. On the other hand, "sysupgrade" file from OpenWRT 18.06 will able to keep both boot sector and will not disturb its data partition.

No you don't need to do that. (Although you want to be careful).

Yes you got this right: a update from 17.04 to 18.06 with sysupgrade will overwrite/destroy the MBR. Which causes the partition layout to be lost.

you could do that. But you could also just backup the MBR/sector 0. Move it to a safe location (i.e download it to your PC) and restore it after the sysupgrade. (You'll need to reboot after restoring the MBR since the kernel will not update the partition layout on its own. And sadly it's not possible to refresh the partition layout with hdparm if the disk has a mounted filesystem.).

You could also go with the Hybrid GPT route:

(But anyway, making a backup of the MBR is probably a good choice either way).

EDIT: This of course only works if you didn't put all your data in the root partition too. If you did that you'll definitely need to make a backup of it (and save it on a PC) before upgrading.

No need for that. You can do it from the MBL itself, fdisk and gdisk are available as packages.

Honestly, don't invest too much time into "patching" an old release to keep your data partition on the off-chance that it might actually work. The "data" partition will still be on the disk, it will just need the entry in the partition table. So what you need to do is the following:

  • for MBR: a) before upgrading, run fdisk and print the current partition table, tuck it away somewhere safe, b) after upgrading, re-create the data partition using fdisk and the parameters you took down before. If all the parameters match, fdisk will actually tell you that there's already a file system in the new partition and offer you to wipe it clean, which you politely decline.
  • for GPT: after upgrading, run gdisk. It will notice that there's a GPT but it doesn't match the MBR, you can just choose to use the GPT again and write everything to disk.

I tried above procedure, and it was NOT working.

So, what I did:

  • Backup MBR with: dd if=/dev/sda of=/www/mbl.mbr bs=512 count=1
  • Upgrade with original sysupgrade
  • Restore MBR with: dd if=mbl.mbr of=/dev/sda bs=512 count=1
1 Like

"cat /proc/crypto",
I see new: "driver : jitterentropy_rng"
Is this where "/dev/hwrng" came from?

I also see new : "driver : gcm-aes-ppc4xx"
Why I don't see improvement of "openssl speed -elapsed -evp aes-128-gcm" result compared with previous 17.04?

That's not the MBL's fault. Unlike dm_crypt or ipsec where you will find that hardware acceleration is present, OpenSSL 1.0.x does not directly make use of hardware acceleration. As I understand, the move to 1.1 is underway but still an ongoing process because between 1.0 and 1.1 the API changed significantly, which in turn requires changes to a lot of packages.

You could compile and install a version of libopenssl with hardware crypto support through cryptodev if you are so inclined. I never tried that, though.

to add to @takimata post: The crypto offload hardware was designed with ipsec in mind. Hence there is no native support for the XTS scheme (disk- / partition- / file-encryption). In order to really utilize the hardware crypto, one would need to setup strongswan and select the Suite B cipher there (both aes-ctr and aes-gcm should work).

Last time I checked Openvpn (~2.4.3-ish) it was not a good choice. it does not batch incoming and outgoing frames together, so the hardware crypto is left dealing with individual frames at a time, which is very sub-optimal for this particular hardware.

EDIT: (oops sorry forgot about this)

No, the hardware crypto engine in this device has a "true random number generator" (and this is were the data from /dev/hwrng is coming from). There are no details on how it works exactly, though. So if you are worried you can stick with jitterentropy_rng.

I updated the file, I added DLNA now, and it works fine (just added one directory with about 100 mp4 and 100 jpg files and no problems so far)

Link: https://gist.github.com/braian87b/84802005e61f7080620b2d522b804f0d

Hello everybody,

I don't know if my question should be in this thread or if I need to open a new conversation. So, my apologies, if I mess.
I have some trouble with OpenWrt installation on MBL single :
After having installed the firmware 18.06.01 (release : r7258--5eb055306f) (and picked a few packages), I wanted to use the whole hard disk size (1TB) for OpenWrt, instead of having unused space.
I then used GParted to remove the unused space between first and secund partition and extend the secund one to occupy all the available space. Result : despite a strange warning from GParted, the job was achieved.
So now, when I list the partitions (using cfdisk), this is what I get :


                                 Disk: /dev/sda
            Size: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
                       Label: dos, identifier: 0x4e54ab1b

    Device       Boot     Start          End      Sectors     Size   Id Type
>>  Free space             2048         8191         6144       3M              
    /dev/sda1    *         8192        32767        24576      12M   83 Linux
    /dev/sda2             32768   1953523711   1953490944   931.5G   83 Linux

:cool:

But on the other hand, when I use df this is what I get :


Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root               258016     42716    210060  17% /
tmpfs                   127064     37916     89148  30% /tmp
/dev/sda1                12275      3120      8542  27% /boot
tmpfs                      512         0       512   0% /dev

:-1:
That is, nothing changed : I'm still stuck with the same disk space amount I had at the beginning.
So first question : is this the normal, expected, behaviour or have I done something wrong ?
Secund : if this is "normal", then how can I make OpenWrt use the whole disk space amount ?

Thanks

P.S. : btw, thanks @chunkeey and @takimata for the sleepoff.sh script, it's a must-have !!!

Seriously, don't do that, don't modify the default partitions. You'll gain a few megabytes at best, but you'll (at the very least) break sysupgrade.

Just create a new, additional partition after the last default one (starting at sector 557056 up to the end of your disk), format and mount it as you wish.

Also, you don't need to convert a disk <= 2 TB to GPT, regular MBR using fdisk will do.

Thanks @takimata for your reply,

Just create a new, additional partition after the last default one (starting at sector 557056 up to the end of your disk), format and mount it as you wish.

so I'll make a new fresh install, but I don't know what partitioning scheme would fit for my need. Since I'll devote one for user data (i.e. /home partition), how should I use the remaining one ? Coming from a mainstream linux background, I've always partitioned my disk as follows :

  1. /boot
  2. /swap
  3. /
  4. /home

And I've never had a shortage when installing whatever packages. So what should I do, in order to generously add OpenWrt packages, without fearing space shortage ? Should I create a /usr partition ?
It seems to me that, bottom line, the question sums up to "Where do OpenWrt's packages install their apps ?"
In /usr/local ? In /opt ?

Regards.

As long as you leave the default partitions alone, you can create as many additional partitions as you like, mount them wherever you like, and use them however you like.

The default root partition is ~256 MB, and practically all of that is free space. That might not sound like much for a full-blown Linux installation, but in OpenWrt terms that is very generous and can take a lot of packages, even larger ones. Keep in mind that OpenWrt and its packages are very much geared towards embedded systems with extremely limited flash space.

I observe that most packages install their binaries to /usr/sbin, with the configuration files at /etc and OpenWrt/UCI specific configurations at /etc/config.

The default root file system comes with ~ 256 MB space. It might not be for full-blown Linux installations, but in OpenWrt terms that is very
generous. Keep in mind that OpenWrt is geared towards embedded systems, many of which come with 16 MB of flash, and oftentimes less.

Ok, Takimata, I understand that I must "think in OpenWrt". I was seeing it as an headless server (which it is), but it's more than that : it's an headless server for very extreme configs.
So I'll will keep it lean and mean (or small and simple :slight_smile: ).
Just one last question regarding the partitioning concern : do you think that allocating a partition to /swap makes sense at all ?

I'm not sure if I'm qualified to answer that. Up until now I have only used my MBLs as rather lean file servers, and I have never been in the situation where the 256 MB of RAM on the MBL was even close to being a constraint.

But of course that very much depends on what you want to run on it. I guess you could put a small partition somewhere in your partition layout, something like 256 or 512 MB, just as a precaution should you ever need a swap partition.

Just as an update to not have this thread with outdated or potentially dangerous information, for anyone who goes down this path:

"Hybrid MBR" is not a viable workaround anymore. With current snapshots, on GPT disks, sysupgrading always resets the MBR to the default two partitions and leaves a "damaged" GPT. You will always have to use gdisk, when prompted which table to use tell it to use the GPT table (option 2), confirm and write it to disk (w), and reboot.

Can anyone tell me if its possible and can we keep the data directory if we upgrade from a running system of [https://downloads.openwrt.org/releases/18.06.5/targets/apm821xx/sata/openwrt-18.06.5-apm821xx-sata-wd_mybooklive-duo-ext4-rootfs.img.gz] (ext4 based image) to a new [https://downloads.openwrt.org/releases/19.07.0-rc1/targets/apm821xx/sata/openwrt-19.07.0-rc1-apm821xx-sata-wd_mybooklive-squashfs-sysupgrade.img.gz] (squashfs based one)?