Use hardlinks, bind mount and systemd-tmpfiles to simplify the logic #20
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Brilliant idea. But there's one little flaw: what if the user would like to revert back to the running kernel without a reboot? The bind mounted old kernel would essentially block the downgrade path. |
|
Good point.
Maybe it can be solved with another hook which removes the bind mount on
upgrade if there is one matching the current kernel.
I'll think about that, a bit busy with life right now.
|
This looks wrong to ignore files in the repostory.
The Unlicense license is include in the licenses packages, not need to include it.
VannTen
force-pushed
the
hardlinks_+_mount
branch
2 times, most recently
from
9497d34 to
cfa301a
Compare
|
Hi o/ So I reworked a bit the hooks: The pre-hook:
WARNING: I haven't tested it yet. Thoughts ? |
VannTen
force-pushed
the
hardlinks_+_mount
branch
2 times, most recently
from
7768fbc to
401c1fe
Compare
|
Great job! |
VannTen
force-pushed
the
hardlinks_+_mount
branch
from
401c1fe to
4c9caab
Compare
This use cp with hardlinks + a bind mount for keeping the removed kernel modules accessible. Cleaning up the backup is done by systemd-tmpfiles on next boot. Cleaning up the mount is either done on shutdown implicitly, or when we reinstall the running kernel by the pre-hook script. No systemd service enabling is needed.
|
Your script is faulty in several ways |
|
It's actually worse than that, because rollback is really problematic.
You end up with files present conflicting with files pacman want to
place in the fs.
A proper solution should be to use depmod to tell the kernel where the
modules are, but I need to look at documenation for that and I've been
missing the time.
|
|
I don't see any file conflict. |
|
should have removed the mount point after umount |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi folks,
I propose to simplify the logic by relying on bind mount and systemd-tmpfiles
instead of cleaning up ourselves.
High-level view of new workflow :
On kernel upgrade / or removal :
transaction to /usr/lib/modules/backup-$(kver)
/usr/lib/modules/$(kver)
-> we delete recursively dir matching
/usr/lib/modules/backup-*-> we delete empty dir matching
/usr/lib/modules/*(installed kernel is notemtpy so it will not be deleted, but the mount point for the old kernel is)
That's a pretty big change ; I'm ok forking if you think it does not fit that
project.
Thanks.