Open unique1984 opened 2 years ago
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.
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.
Have a nice day.
We may add a link to such scripts in documentation, but there are 2 ways:
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.
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?
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.
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.