dracut/zfs-load-key.sh: properly remove prefixes

[alaviss]

Motivation and Context

If the root is passed to the kernel like this: root=zfs:zroot/sys/def, then on boot, you'll receive a message like this:

 cannot open pool 'zfs:zroot'

Then the encryption key prompt will not show up, making the system unbootable (if you use encryption).

How Has This Been Tested?

Booted my machine with it.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the ZFS on Linux code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commit messages are properly formatted and contain Signed-off-by.

[codecov]

Codecov Report

Merging #9520 into master will decrease coverage by 0.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #9520      +/-   ##
==========================================
- Coverage   79.11%   79.03%   -0.09%     
==========================================
  Files         416      416              
  Lines      123652   123652              
==========================================
- Hits        97831    97728     -103     
- Misses      25821    25924     +103

Flag	Coverage Δ
#kernel	79.69% <ø> (-0.01%)	⬇️
#user	66.55% <ø> (-0.34%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e357046...b0aad98. Read the comment docs.

[behlendorf]

@dacianstremtan @ghfields would you mind reviewing this proposed fix.

[dacianstremtan]

I am unable to replicate the problem.
I'm running Centos 7.7 with encryption enabled at the pool level and I get the prompt all the time and successfully decrypts the pool with kernel option root=zfs:rpool/ROOT/centos7 in my case.

EDIT. Finally I was able to duplicate the issue on CentOS 7.7 On my system the zfs-load-key.sh early terminated because zfs-import-cache.service was failing. The pool was imported by the zfs-mount.sh script afterwards.

[dacianstremtan]

The suggested line fixes the issue, but I would suggest a different approach:

BOOTFS="${root##ZFS=}" || BOOTFS="${root##zfs:}"

It will chose one of them based on the the root=zfs:rpool/dataset or root=ZFS=rpool/dataset, also easier to read the code.

[ghfields]

@dacianstremtan and I worked side-by-side on this one. His suggested modification processes both instances using the same format and builds in a framework for any future checks to be cleanly added.

[alaviss]

The suggested line fixes the issue, but I would suggest a different approach:

BOOTFS="${root##ZFS=}" || BOOTFS="${root##zfs:}"

It will chose one of them based on the the root=zfs:rpool/dataset or root=ZFS=rpool/dataset, also easier to read the code.

I'm rather certain that parameter expansion doesn't work like this...

[behlendorf]

Thanks everyone for the feedback. Let's go with the change as proposed.