Dear Maintainer,

overlayroot does not appear to support /usr on a separate block device. Upon installing and enabling overlayroot and rebooting, I am
dropped into an initramfs recovery shell stating that an init executable could not be found. Upon reviewing my mounts from within
the initramfs shell, it appeard that /usr had not been moved relative to the new $rootmnt by overlayrootfs.

Indeed, moving my usr data onto the same block device as my / data fixed the situation, and I was able to gain the desired function
of overlayroot.. at the expense of combining my usr data with my / data.

I had anticipated that overlayroot would have planned for the contingency of /usr being on a separate block device. And I would
like to be able to have the best of both worlds.

Reviewing the source of overlayroot and initramfs-tools, it appears that initramfs-tools does a quick-and-dirty check of fstab
to find the location of /usr shortly after mounting the intended root file system. initramfs-tools does not appear to update a
global variable to flag to scripts within init-bottom that /usr was separated from /; however, initramfs-tools does provide the function
read_fstab_entry to other scripts.

I believe that that overlayroot could easily incorporate this functionality by moving /usr to /media/root_ro/usr if a conditional
finds that /usr is on a separate block device within fstab. I think the most amount of work will go into changing how overlayroot
generates a new fstab.

I do understand that this is a niche use case, and I wouldn't be surprised by a willnotfix return. But I appreciate your time
nonetheless.

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***