ludo@gnu.org (Ludovic Courtès) writes: > Ricardo Wurmus skribis: > >> Ludovic Courtès writes: >> >>> Gábor Boskovits skribis: >>> >>>> I believe, that we could make a powerful extension to guixsd if we could do >>>> an installation from an installation description. >>>> >>>> I think this installation description should look like the operating-system description we >>>> already have. >>> >>> In what way would it defer? :-) >>> >>> ‘operating-system’ *is* an “installation description.” >> >> I guess it would differ from what we have currently in that it would >> also specify partitioning information, which is not handled by >> “operating-system”. >> >> Does it make sense to extend “operating-system” such that disk >> partitioning information could be included and (*holds breath*) acted >> upon automatically? > > I suppose only ‘guix system init’ could actually use that information. > > Perhaps we could have a separate partitioning description, and users > could optionally run: > > guix system init --partitioning=part.scm config.scm > > ? > > Is it really an improvement over writing a Parted script, which is > something people can already do? > >> Acting on partitioning info is a little scary because it can easily lead >> to data loss upon reconfiguration. Small bugs could lead to very big >> problems, so maybe this should not be default behaviour. > > It’s definitely scary. > > Ludo’. Currently, I can only imagine two possible ways this might be used: 1) Somebody wants to frequently change the hard drives, partitions, and/or file systems in their computer(s). 2) Somebody wants to initialize the hard drives, partitions, and/or file systems in their computer(s), but doesn't need to update it later. In the case of (1), who really does this? I know of no developers or users who actually need to change these things frequently. And when changes to these things ARE necessary, it's usually easier to just blast everything away and start fresh (restoring what you need from a backup later), rather than trying to figure out the right way to safely modify things in place. Since changing these kinds of things on a system that's already in use is a rare and dangerous activity, I'm not convinced that Guix needs to provide support for this use case. In the case of (2), anybody who frequently needs to provision systems will probably have a use case for this, so it might make sense to add a feature for first-time initialization only. Maybe a company wants to provision many GuixSD systems for employee laptops. Maybe somebody needs to provision many GuixSD servers in a datacenter. I think that if somebody really needs to do this sort of provisioning frequently, they're probably going to implement their own custom workflow to accomplish the task. Can Guix add a feature to make their life easier? Maybe. For example, maybe we can fields to the declaration which are only acted upon by "guix system init". The intended workflow would be: boot a GuixSD installation image, then run "guix system init" per the manual (perhaps via a script, or even a "guix-provisioning-service" started by Shepherd...!), and Guix will do everything it does today to initialize the system, but first it will also destructively initialize the hard drives, partitions, and file systems according to what is contained in the specified declaration. THIS could be nice! Of course, someone who is provisioning systems like this already has the option of creating custom scripts and tools to initialize the system's drives, partitions, and file systems, but wouldn't it be nice if Guix could do this on their behalf, also? If these details were all defined in the declaration, then (1) the user wouldn't have to implement those kinds of tools themselves, and (2) it would reduce the possibility of writing an declaration that contains incorrect information about disks, partitions, or file systems because all that information would be contained in a single file. I think the key here is that if Guix provides a way to manipulate disks, partitions, or file systems, it should only be allowed when initializing a new system - not reconfiguring an existing one. -- Chris