Skip to content
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

Automated bash installer script, based on "Debian Bullseye Root on ZFS" document. #287

Open
unique1984 opened this issue Mar 27, 2022 · 5 comments
Assignees

Comments

@unique1984
Copy link

unique1984 commented Mar 27, 2022

OpenZFS - ZFS as a Root File System on Debian Bullseye installer.sh

The Document

Installation script usage It is Turkish but, with screenshots you'll get the idea and the result.

2022-03-27_18-52

2022-03-27_03-13

@rlaager
Copy link
Member

rlaager commented May 21, 2022

I only skimmed it, but that looks like a nice script. I've seen a few other examples over the years. Part of me wonders if I should give up maintaining this as a document in favor of doing an installer. But it seems like the best thing to do would be to add support to the default installers, even if I'm maintaining it as a fork forever.

@rlaager rlaager self-assigned this May 21, 2022
@unique1984
Copy link
Author

unique1984 commented May 21, 2022

I only skimmed it, but that looks like a nice script. I've seen a few other examples over the years. Part of me wonders if I should give up maintaining this as a document in favor of doing an installer. But it seems like the best thing to do would be to add support to the default installers, even if I'm maintaining it as a fork forever.


Between installation script and document i can say about both of them are valuable, If there is only installation script then we must reverse engineering on that purpose of understand the mechanism. If there is only a document then we must create something automate the steps of the document.

Maintaining as a document is the best thing to do i think. Decision is yours, i can not say something like "this must be use".

If you want i can convert the license MIT. I permit everyone to use all of the script or a part of it as wish. This is what opensource isn't it? If it is useful then simple thanks is more then enough for me.

I've written about the zfs usage to. The article is Turkish again but the commands are global. When i get the time i will translate it English.

image

Have a nice day.

@gmelikov
Copy link
Member

We may add a link to such scripts in documentation, but there are 2 ways:

  • script is outside official documentation, so it should be described as unofficial, and it may be supported by author
  • script is inside official repo, so we should have a maintainer for it

First one is easier, because we'll have official description, but optional automation.
@unique1984 if you're interested - I'm not against second way too.

@unique1984
Copy link
Author

We may add a link to such scripts in documentation, but there are 2 ways:

* script is outside official documentation, so it should be described as unofficial, and it may be supported by author

* script is inside official repo, so we should have a maintainer for it

First one is easier, because we'll have official description, but optional automation. @unique1984 if you're interested - I'm not against second way too.


I can't foresee the workload right now but i know that i can modify for all the documented Debian versions (stretch, buster, bullseye) this script and some part of the document doesn't implemented right now (native encryption, EFI ...)

I'd love to partake in OpenZFS even a bit of it, 2nd way is more suit to me. What is the road map @gmelikov , how can i become a maintainer in official repository for this script?

@gmelikov
Copy link
Member

Sorry for delay, @unique1984

Second thought is - it's a documentation repository, and the way with script is outside official documentation, so it should be described as unofficial, and it may be supported by author looks best as a start. We may add it in instructions description, look at it's popularity and change the format of officiality later, if we need to do so.

So, for this way - we can work with that if you'll have a usual repository for scripts, you may want to enable issues and PRs there and have some documentation in english too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants