Consider a new installer for Void

[gevera]

There are issues with the current Void installer. Like the absence of LUKS on top of LLVM. Also, some users report trouble with partitioning.

There are alternatives that could be implemented. One of them is ArchLabs installer. https://bitbucket.org/archlabslinux/installer/src/master/

It lacks any of the issues stated above, plus it is more advanced and looks better.

Please consider the switch. Thank you

[bobertlo]

Could you elaborate on the trouble with partitioning?

[gevera]

When I was installing on top of older distro I didn't have the option to choose GPT, basically, the installer skipped the partition type chooser.

It took me straight to cfdisk. So whatever I did after that didn't had an effect. I had to load a different live distro, had to create a new partition table with gparted on the hard drive, and only after that go all over again with the void installer. This is frustrating.

Apparently this happens more often. Here are some comments on distrowatch regarding the installer

• The installer failed at the GRUB stage with “unknown filesystem” with not much explanation of why, and dumped me back into a root shell. I was using what I thought was a pretty basic ESP+XFS partitioning scheme. I tried to put together my own chroot and fix it from there, but I got stuck and pretty much gave up. (my assumption is because of unset GPT)

• unintuitive installer (command line installer like Arch OR graphical installer like calamares should be preferred)

[Duncaen]

It took me straight to cfdisk. So whatever I did after that didn't had an effect. I had to load a different live distro, had to create a new partition table with gparted on the hard drive, and only after that go all over again with the void installer. This is frustrating.

https://docs.voidlinux.org/installation/live-images/partitions.html?highlight=wipefs#partitioning-notes

The problem with issues like this is that you have to find someone who wants to actually work on the installer. I think everyone agrees that there is room for improvements, but there is no one who stepped up to actually work on it.

Edit:

unintuitive installer (command line installer like Arch OR graphical installer like calamares should be preferred)

And comments like this are just wrong, there is not problem using xbps-install to do a arch like command line install. All the more extensive guides for i.e. luks etc do exactly this.

[leahneukirchen]

command line installer like Arch

This is roughly what xvoidstrap of xtools provides.

[ghost]

I agree. I migrated from Xubuntu -> Void

Partition & Filesystems were the confusing steps in the ncurses installer for GPT/EFI. You could get more users by easing (automating if possible) this process.

[the-maldridge]

This is a common misconception about void. We aren't driven by some pursuit of popularity or more users, we're driven by building high quality software. You may find at times that these goals naturally line up (a system that doesn't break every time you update it) and sometimes diverge (an installer that requires an understanding of the underlying processes).

[ghost]

I am aware about the high quality software bit (BSD roots, not including garbage in the package index). It is the reason I took the leap of faith from LTS to rolling. I feel Void Linux is too underrated. Making it easier to install will bring more users which may bring more donations, mirrors, testers, bug reports and what not.

Btw, Thank you to the developers for this blazing fast OS. :)

[pinpox]

This is a common misconception about void. We aren't driven by some pursuit of popularity or more users, we're driven by building high quality software. You may find at times that these goals naturally line up (a system that doesn't break every time you update it) and sometimes diverge (an installer that requires an understanding of the underlying processes).

Came here to suggest a guided partitioning with or without luks to be added to the existing installer. I fully agree with the quote above, but since there already is a (quite nice) text-based installer, a submenu for guided and manual partitioning would be a nice addition. There might be cases where more special partitioning is required, but 90% of the time I end up doing the same partitioning scheme for my machines.

I'm willing to contribute this feature, but would like to know first if that is something you would consider merging at all.

Since there already is a partitioning entry in the void-installer I would suggest a menu structure like:

...
├── Partition Disk
    ├── Guided
    |   └── Select LVM, LUKS, separate root partition, swap options, hit go
    └── Manual
        └── Open cfdisk like at the moment

...

Let me know what you think and if/how I can help get this done

[hippi777]

hi folks! :)

edit: after i sent this, ive seen the mentioned arch installer, it is promising and somewhat similar, thx! :)

as i already mentioned it somewhere around here (under a git issue of whichever void repo and issue :D ), im working on one, but ive seen a huge amount of installers and wikis (near to and far from void; mostly shell based things, but perl and python were on the list as well; ive read like the ~3/4 of the internet to make this happen :D ) and mine will be a yet another one...

the hardest thing of all is the fs, where no consensus exists, with ~unlimited possibilities, and that has the highest complexity, as that takes at least a tree or maybe even a graph to be represented ideally, and bash is ... well, bash.. :D it can solve anything, but it always takes some hacking... also, ive seen no other configs for filesystems than very basic ones, if any, while i use a large amount of the settings to get optimal results :D my approach to solve this complexity around filesystems in bash is to make flavors (currently 1 :D ), pick one, and if possible, then make one of them more flexible instead of making yet another... this could be improved, and suggestions are welcome, but i dunno if i wanna put that much effort into it or not....

accordingly, just to see my motivations, limits and whatever: (((im living on a 8g pendrive with an installed deb10 on it for a couple of months now and i would be happy to be ready with it sooner than later, and to finally see my 1st ssd in action with void (story: my hdd died, i decided to make the best system ever, or at least the funds that would hurt to be messed with after ive built my new empire on top of them...) and i also have much other things to do, but simple things could be fine for improving that fs stuff that i mentioned above, or otherwise i could leave somoe notes there so when it will be public, then others may do it, or whatever.... also, i have a universal app in lua, called to be Szoszi, that is still private, and i would be more happy to migrate there, but i wanted to make this public when its done, while Szoszi will take much time to be ready to see the sunlight, and my tools there relying upon each other too much to be able to simply extract some bits from here and there, so i took bash to be able to make this installer public when its ready, while by the time maybe i will abandon this in favor to that, or do it parallel with much fewer focus on this... whatever... )))

more about the installer:

this will only ask for the password of a loopback luks container (if not already opened) for the things that are better to be kept secure (passwords (luks+users), luks header backups, whatever...) to either create or open it, and then the rest will be automatized, so it wont need any more interactions! :) the whole stuff is based on a config (or two, to override bits of the 1st one; where the 1st kinda configs represent systems (as a flavor, or as a machine specific stuff), the latter represents installations (minor modifications for different machines or different times of installation...)), these config stuffs are neither sanity-checked nor created automatically, but they could be, so in that case, the installer could be used by the mere mortals as well, now its kinda much of a techie stuff, just with much guidance written in comments... :D by creating the config automatically, i mean that it could get an interactive component to create the config, and as a gratis, next time ppl will only need to start the installer and then get back their previous system :D

also, i think it takes no much effort to make it work under different distros and to assemble different distros (package names could be the greatest issue...) so i think it can become something awesome (or bloated trashware), but i realized that this is a thing that is urgent for everyone when its time to make it happen, and then they dont care when they have their system up and running, so i dunno what will be the future of this, but as of now, i think its promising :)

[pinpox]

@hippi777 is there a link to your project where we can see it?

[hippi777]

i will upload it whenever i will be ready, but now im hacking it all around, and i dont care now about version management and things like that (not like i would be fluent in any of those X'D that would hold back my slow progress even more... :D ) also, its still nowhere to be usable, im still only about to finalize the fs related stuffs, the rest have a huge amount of mostly copypaste based notes, so in the current form its not even a thing that could make me proud :D otherwise i know ppl could help me, but i wanna give it a basic shape according my own taste and while others could help here, they would hold me back there... so i dont hope for big win from that as well...

actually i wrote that in case if this is not in a big hurry, but on the contrary, i dunno how much more time i will spend on it, and i have a very high load, like daily ~100 mail threads (most from void, but others as well) 400+ tabs waiting for me in firefox, and what not, now i will read those two mentioned installers as well for example, then i will try my last 2 guessed to solve an issue with bash and strings :D , and in the meantime probably i will try to reduce my mails, and hope for nothing else to come ... (spoiler: adhd :D )

[hippi777]

i just finished to read https://bitbucket.org/archlabslinux/installer/src/master/ .... uhm, how to be polite? imho most of it is trash :D the "puppy genesis" gave me a similar feeling recently, but thats somewhat better :D i hope for a better experience with calamares.....

edit: i can already tell no. but pain is gain, i will read some more.... (ok, its much better, but still... :D )

edit/2: (((d-i is really sophisticated and (mostly) well-crafted and it doesnt feel like it would be written by dilettanti, but its really debian specific, and it would hurt to reshape it or to consult with it too much, cuz on the one hand it has nice colorful options and much covered corner-cases, but on the other hand, its fundamentally more overengineered than it would be necessary, and feels like a typical industrial legacy bloatware :D btw probably i wont read more installers/wikis, even if i would know some areas to look after more, and i already read too much of them... most are untold... :D )))

while reading d-i, i realized two very important things about mine... one thing is that it will probably have a very high fluctuation, so one will need to save a copy of the installer alongside their config, (that isnt a big deal), and maybe rework it in case of an update, or just play with a legacy copy, and this can take away the fun partially from having a JustWorks^TM installer... the other thing is that my fs flavor concept must be reworked, as it would probably evolve into too many of them, and an option tree would be really required, and i believe that arrays cant be embedded into other arrays in bash, however i feel like they will be the answer beside ${!var} and prefixed globals with some good naming convention, so trees can be simulated with these... :D but bash is about evil hacks anyhow... :D (currently i dont even use arrays to pack them...) and the point is that theres some chance that i wont make that now (maybe u?), so im not sure if u should wait for me or not or whatever, but at least it will carry some nice gems, as i really did my homework, just i realized how much other things are waiting for me and i already spent more time on this than sane ppl would do..... anyhow, i will be around for any purpose, and i will make this at least work, even if it wont be near to be production-ready...

[pinpox]

I just got a pull-request merged for calamares to support the xbps package manager: https://github.com/calamares/calamares/pull/1431

Would anyone be interested in helping me build a calamares install iso for void to test out how well it works?

[hippi777]

up:

i have trees in bash!!!!!!!

they can be passed by reference, i can dump them (not implemented), i can tell if something is unset/primitive(string)/array(associative, but could be used as numeric arrays like in lua :D or could be made into a matter of switch, but why after the former possibility? :D ) parent nodes can be accessed, namespaces can be used to prevent collision of identical root elements (i wont use more than 1, just its possible :D ) ... this is more than enough, i only need to set things once, get them back, and list node keys, but i still dont have a function to get the length of a node (all keys/array keys) and i wanna make a delete stuff, cuz if i would insert anything in place of a node, then it wouldnt remove its branch, but only the actual item... so far so good, i can make the installer universal and i can rework the fs flavor stuff that currently cant even reorder things or change single component (like an ext4 partition to xfs) without the need to derivate a new flavor, but only sizes, labels, and some exposed options can be changed as of now... and that wasnt enough fun... now bash started a new era with trees X'D (secretly i still hate u bash! X'D ) im not sure, but i think it could be possible to rework it to work even on dash (ive got only 2 other bashisms, a trivial, and a maybe trivial), but then based on strings instead of arrays, but i dont care right now that much... i shouldnt even make a deleter function to make my installer happy, but i want to... and to make this whole thing cool, i will release it alongside my void installer, cuz i wouldnt be enough happy if anything else would use it before the void installer (thats a lie, cuz it was already possible to add other package managers/init systems/whatever with less headache than the fs mess could be :D but void rulz) btw.... it can be serialized (into bash source :D ), so options can be saved in case of making an interactive frontend, but thats most likely an exercise for anybody else to make that happen (not really a big deal), just like the interactive installer... i like the handmade config as i liked it before :D

ps: i already dont really worry about fluctuation, maybe in the early times, when ppl will start to experiment with it... now i only need to make it into a thing :D

[pinpox]

TL;DR?

[hippi777]

im on the way :D that heuristic was a missing component to make my void installer flexible, and with that, wide variety of tastes can be satisfied :)

[gevera]

im on the way :D that heuristic was a missing component to make my void installer flexible, and with that, wide variety of tastes can be satisfied :)

Any updates on this? Should I keep it open?

[hippi777]

its just that im extremely busy with everything...

release: really dont hold ur breathe, but i will try my best to inform the void community whenever i will be ready, if i will find this issue, then i will leave a ping here, even if it will be closed, and probably i will ping on reddit too, and im open to other suggestions as well.

status: i have/had really much other stuffs to do as well, but the relevant part is that i have a reasonably polished set of basic tools that i needed (even a bit more, just to make them more complete, as these are actually universal libs) and now i need to rebase my already mostly done fs related tools from very much inflexible globals to this tree based config i made available, and that is passed by reference. i also need some minor math for partitions and lvm; and i have a smaller amount of organized notes for the actual installation from all the related sources i could find (various installers and wikis), that needs no much effort, and a huge amount of other messy notes that may contain some gems, and will take some hours just to skim them... :D some other possible work that maybe i will address before releasing is discussed below.

[TL;DR: the details after the initial statements (up to the 1st semicolon or full stop) can be skipped at will] what to expect:

• public domain (or maybe unlicense or cc0) ; no limits = no complaints. :D
• depends on bash; even if i have tried to minimize bashisms, while probably it could have variations in the background for other shells, but i dont actually care about this, except for ash/dash, but those would be the most painful hacks...
• the style and conventions are weird; and not really aligned to those things ive seen around void.
• well documented; (but in that weird style :D ) even implementation details are exposed, there are notes for future plans, possibilities, and about things that i dont really feel settled with.
• config driven, so basically automatic; this, and the trees (or their components) that can be passed by reference give high flexibility, configs can be granulated, they can even override others partially, they have all the power of bash and all of my related tools, and they could be generated by a frontend, but thats out of my interest. (btw note that no tool is mandatory that i will mention below, like luks or grub, anything is a matter of altering the config and making those tools that i didnt care about...)
• initial support will cover these (dont stop here at semicolons) : sgdisk (with room for supporting sfdisk or parted); grub2 (maybe even optionally git head for luks2 format); esp (fully or partially mbr, hybrid boot and protective mbr, as i want to have an universal usb drive that works without touching bios/uefi settings, but without the write-only el torito and its workarounds, but that may be added as well at a later point); proper alignment with flash drives in mind on all fs layers (currently its manual, but i plan to optionally set/sanetize it based on detection of rotational drives and 4kn, but i dunno how far i will reach with this part, and i cant test things for 4kn, and theres no free rotational drive at hand that i could just grab from the shelf without taking care of its contents); vfat, xfs, ext4 and luks with fully exposed settings and in any "constellations", others like zfs btrfs and even raid are considered, and probably would be easy to add without messing up anything, while im not sure i have thought enough about raid, but i guess, and i took care of backing up things like partition tables, luks headers and lvm headers, they can even be restored if the installation fails at reasonable points (i should think somewhat more about this how far this makes sense, and its only partially done); multiple systems can be defined in a single installer (like for having a chroot subsystem or a multiboot system), and mount points may differ across these systems for the various fs components, and also, labels are currently mandatory, as that will render everything much prettier; both musl and glibc, and whatever sw stack upon them; generation and/or installing configs is a thing i will need to solve at a reasonable level, but there are much possibilities around these...
• portable; but on the contrary, it should be reorganized to turn it into a shape that is suitable for packaging, maybe i will do it myself, maybe not, dunno as of now...
• i avoided as much external utils as i just could; like grep/awk/sed/bc/sort/tr/ls/whatever for those stuffs that bash can solve on its own :D
• currently theres no check for the actual dependencies, but i plan to make it work on any hosts; this has only the drawback that im aware of is that shaping the fs could require fresher programs than those that are available on a host.
• reliable on so many levels; see below! :)
• only a vault for passwords (or keyfiles and whatever u want) needs to be created or opened interactively (as of now), this prevents storing unencrypted secrets on permanent mediums. this could be altered to ask passwords interactively or to use defaults, and make it even more automatic, but that just delays the actual task to set up like at least 3 passwords, where i mean a single luks and 2 users. while i will have 2 luks devs, where 1 is the "hall/anteroom" of the system, and that can be used to validate an unencrypted esp (and/or mbr) from grub and/or an initramfs before opening up the main luks with all the actual treasures, so the only attack vectors for a turned off computer remains at hw/fw level. :) (maybe i will delay this validation part after an initial release.) it is similar to what the tomb application does, probably it can even open tombs, but i discovered that just recently, much after i created my vault stuff, and mine is way more lightweight, and the actual engine can be changed behind the vaults as a matter of setting a backend/engine variable in its config, while the default will remain this, so an existing config wouldnt get affected, however this change is again out of my interest.
• i expect no flux but extension for the config; so future versions should work with old configs, that will be able represent a whole system from the ground up! :) (maybe it could even follow up changes of a system by wrapping some tools to generate minor parts of the config, but i wont do this before releasing it...)
• there are a bunch of sophisticated auto tests, that cover the more complex parts, and there are some unpolished "manual/visual" tests that litter the output if activated, and they need to be factored out from the libs, and i dunno how much i will play with polishing these parts or how much of this i will leave to others.
• corner-cases that im aware of are handled correctly. like 2 is sorted before 12; strings and lists doesnt get wrecked on the fly when they have spaces and newlines included (like ls and sort dont have reliable output when something has a newline in it, or even $() eats trailing newlines), etc; name reference collisions are prevented, printing unknown texts that could become valid flags to echo and be eaten by it use printf instead; number validation has many gotchas, and actually the validity depends on the actual use case; etc
• things that may fail unexpectedly are always checked, but not the invalid input; while the config could be validated before anything else, but probably that will be an exercise to any1 else who cares enough about that. :D i took an approach of applying the least amount of protection, so like where an input string shouldnt contain spaces, there i dont quote any related variables, and actually i have found this beneficial, as this can give me hints about their contents, while i see no reason to protect against anything that is an error that is only delayed to happen at a later point. only the tests have extra caution about these, and extra caution as a habit can be a good thing, but habits are not about taking care of the reality at hand... :D
• there is a stack based cleaner to sanitize things after an error in the middle of something, and i already have a partial vision about resolving stuffs in case of a crash, blackout or anything like, when the cleaner cant be relied upon.

[the-maldridge]

As there are efforts beyond the scope of -mklive to provide an installer, I'm going to go ahead and close this thread.