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
Issue 2247: draft implementation of 'mountonly' workflow. #2269
Conversation
Re-align with trunk/LATEST.
…meix to 'usr/share/rear/layout/prep-for-mount/default/600_show_unprocessed.sh'. Updated doc. based on earlier email exchange.
usr/share/rear/layout/prep-for-mount/default/600_show_unprocessed.sh
Outdated
Show resolved
Hide resolved
usr/share/rear/layout/prep-for-mount/default/600_show_unprocessed.sh
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From plain lookiing at the code
I only found tiny copy&paste typos in comments
where rear recover
should be rear repair
so all looks good to me on first glance.
As far as I see this pull request is only additional code
but no change of existing code so that merging this pull request
cannot cause regressions for existing use cases.
Therefore I would like top merge this pull request
soon - which means tomorrow afternoon - unless there is
an objection from one (or more) other ReaR maintainers.
@rear/contributors |
usr/share/rear/layout/prep-for-mount/default/540_generate_device_code.sh
Outdated
Show resolved
Hide resolved
@jsmeix As to your plan to merge the PR tomorrow: I'm currently working on a small improvement initially suggested by @schlomo to prevent running the Knowing this, do you prefer waiting for my commit (which I'm sure will warrant further review, though more limited in scope), or should I rather focus on fixing the current review comments to let you merge and then submit the aforementioned improvement as a separate branch? |
@petroniusniger But there is no need to wait until all is done for the repair workflow. I would prefer to implement new things step by step What I mean in general is: "Submit early, submit often" Do not mix up several independent separated issues in one big all-in-one On the other hand do not split several changes that belong to each other What I mean is mainly that a single piece of functionality like The final full featured repair workflow may consist of many single |
@jsmeix I'm integrating your review comments as we speak. |
@petroniusniger Did you perhaps forget to do a Cf. the "Contributing" section in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merging blocked because we are waiting
for more changes from @petroniusniger
@jsmeix : I've not forgotten the push. I've not pushed yet because I'm not finished implementing all your review comments (I still need to rename the workflow). What's more, I don't want to push any code that I've not tested. I hope I'll be able to finish this week (including the eventual push), but that also depends on any emergencies that may surface at the office. |
@petroniusniger Seems you also suffer from arbitrary kind of weird |
"Interlock" between workflows: Implementation details The current implementation only takes care of allowing certain workflows ( Here is how this works:
|
Tests ran with the modified code:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From plain looking at the code things look o.k. to me.
@petroniusniger
please tell me when things work sufficiently for you so that I could merge it.
I look forward to try out your new mountonly
workflow!
@rear/contributors |
Re-align working copy with trunk/HEAD.
@jsmeix |
Updated PR title to reflect the renaming of the workflow. |
I would like to wait until next monday When there is no objection I would merge it next monday afternoon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you to @petroniusniger and to @jsmeix for his careful reviews. Nice piece of code which makes ReaR an even better tool.
@petroniusniger |
Type: New Feature
Impact: Normal
Reference to related issue (URL): Add new 'mountonly' workflow #2247
How was this pull request tested?
First a rescue image + backup archive (
mkbackup
workflow) has been created for a VM (openSUSE Leap 15.0). The VM has then been booted off the rescue ISO and the newrepair
workflow executed to make sure that all local filesystems ended up mounted below/mnt/local
(these included LVM Logical Volumes and a LUKS-encrypted filesystem), as well as the most important virtual ones (sys, proc, dev). I then checked that it was possible tochroot
inside the system and run YaST. I also verified that once I exited thechroot
environment and shut down the VM, that process cleanly unmounted all target filesystems.In a second test, I also verified that I was able to do the same even when no backup archive was present (i.e. having only run the
mkrescue
workflow during the preparation phase).The philosophy I followed was to take advantage of the existing
disklayout.conf
(generated during therescue
workflow) and to reuse as much as possible of the filesystem recreation mechanism while implementing an alternative version of it that would only mount but not recreate anything (but still based on the same dependency analysis and the auto-generation of an intermediate script).a new
repair
workflow has been created, described as "use ReaR as livemedia to repair the system" in the online help message
the
repair
workflow is composed of the following stages:setup
,check
,layout/prep-for-mount
,layout/do-mount
andwrapup
(
setup
andwrapup
are reused as they are -- the other three stagesare new)
layout/prep-for-mount
is mostly a clone oflayout/prepare
(throughsymlinks), but with a few files of its own (
540_generate_device_code.sh
,550_finalize_script.sh
and600_show_unprocessed.sh
), modified versionsof the original ones
layout/do-mount
is a clone oflayout/recreate
(through symlinks), butwith only three action scripts kept (
100_confirm_layout_code.sh
,200_run_layout_code.sh
and250_verify_mount.sh
-- no localmodification as of yet)
check
is a minimalist clone ofverify
(through symlinks) that ignoresall the supported backup engines. This also makes it possible for the
repair
workflow to be used even when no backup is availablein
layout/prepare/GNU/Linux/160_include_luks_code.sh
(sourced throughits symlink
layout/prep-for-mount/GNU/Linux/160_include_luks_code.sh
),I've added a new function
open_crypt()
(cloned fromcreate_crypt()
)that only performs the
cryptsetup luksOpen
operationin
lib/layout-functions.sh
, a new functiondo_mount_device()
(cloned from
create_device()
) deals with opening (as in the case ofLUKS-encrypted filesystems) and then mounting the filesystems. To do
this, it may call the new function
open_crypt()
or existingmount_*()
functions
a new action script
540_generate_device_code.sh
, specific to theprep-for-mount
stage (cloned from the one that comes with theprepare
stage) will process the disk layout and generate a customscript (still called
diskrestore.sh
) to perform the actual mount ofall the needed filesystems (including the virtual ones -- that part is
currently hardcoded). That script will be called later by
layout/do-mount/default/200_run_layout_code.sh
a new example scenario has been added to chapter 4 of the User Guide,
describing how to use the new
repair
workflow and why you wouldwant to do so
Still TBD: once the
repair
workflow has been run, disable call torear recover
without rebooting first to make sure we always start from a known state, as suggested by @schlomo (in an email dated March 14, 2019).