New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Should function apply_layout_mappings() also migrate in comments? #2183
Comments
My immediate idea is to enhance
|
The other idea to add an additional check that each mapping Reason: If there is only a mapping from 'foo' to 'bar' |
With the fix in my With the unchanged autogenerated mapping file that contains only
the mapping works and results the following disklayout.conf after the mapping:
i.e. there is a leftover replacement string |
…cement strings in comments (issue rear#2183)
…or_leftover_replacement_strings_in_comments_issue2183 In the function apply_layout_mappings (therein in its "step 3") treat leftover temporary replacement words (like '_REAR1_') as an error only if they are in a non-comment line (comment lines are those that have '#' as first non-space character), see #2183
With #2189 merged |
So the answer to the question
is: |
Current ReaR master code:
On original system
/dev/vda
and/dev/vdb
existand both have partitions but
/dev/vda
is not used andonly
/dev/vdb
was used (i.e. has mounted filesystems).Therefore disklayout.conf has entries for
/dev/vda
and/dev/vdb
but the entries for
/dev/vda
are commented out likeOn replacement hardware only
/dev/vda
exists and should be used.In MIGRATION_MODE disk mapping from
/dev/vdb
to/dev/vda
failsbecause there is no counterpart mapping for the old
/dev/vda
so that after the failed mapping attempt disklayout.conf looks like this:
The remaining
_REAR1_*
result thatapply_layout_mappings()
returns with non-zero exit code in its
which lets layout/prepare/default/320_apply_mappings.sh Error out at
One workaround is to manually remove the entries
for
/dev/vda
that are commented out in disklayout.conf.Another - probably even easier - and at least cleaner - workaround is
to manually add the missing counterpart mapping to the mapping file
which is initially only
With an added dummy counterpart mapping like
the mapping works and now it is even documented what the old thingy was
because that results the following disklayout.conf after the mapping:
The question is if that special case could be autodetected
so that things "just work" in MIGRATION_MODE even
in such special cases.
The danger with any such "nice to have" autodetection
to make things "just work" even in special cases is that some
other subtle real errors might be no longer detected and
ReaR blindly proceeds (as it did too often in the past)
until it miserably fails out of control somewhere later
at an unrelated place with a weird error message, cf.
"Try to care about possible errors" in
https://github.com/rear/rear/wiki/Coding-Style
The text was updated successfully, but these errors were encountered: