On Tue, Aug 02, 2016 at 02:53:58PM +0200, Ludovic Courtès wrote: >Hello, > >Tomáš Čech skribis: >>>All the packages used by the initrd are automatically part of the >>>initrd. The proposed patch would allow people to add unused packages to >>>the initrd. >> >> It is for the packages which you may want to use interactivelly in >> case of failure or for some extra initrd hacking you may not want/be >> able to write in Guile. >> >> Features like >> - extra authentication >> - full disk encryption >> - root on NFS >> - LVM :) >> - ... > >OK but if you need these packages, for instance because you have a LUKS >boot device, they’ll already be in the initrd. No need to manually list >them in #:extra-packages. That is correct only for cases which are already handle. Last time I booted from LVM it didn't work. IOW your answer is valid for user but not for (potential) contributor. This can help me (and possibly others) to write it. Otherwise it is hard to write for Guix in Guile because it is hard to write for Guix in Guile. My solution is not perfect but helps. >>>Could you explain how/when this would be used? Maybe as commands for >>>use by Bournish when it’s used as a rescue shell? >> >> I agree that it is more for debugging and to balance my inability to >> express it in Guile but it lowers the barrier a bit. >> >> Bournish is too young to rely on it. I miss pipes, accessing files in >> different directories or `ls' with wildcards. I can put in minimal >> static busybox which is more than sufficient for rescue, problem >> analysis or even data recovery. >> >> I like the idea of Bournish but I'd rather have an alternative >> until it is more capable. > >I agree, but hopefully, you don’t run into Bournish too often? Of course I did until I used exactly this patch and was able to solve my problem. >I guess my main concern (again, as a lazy maintainer) is the cost of >turning ‘base-initrd’ into a kitchen sink, as discussed in the other >thread about #:extra-modules. > >I would prefer to provide simple tools that people can build upon, like >‘expression->initrd’ or the ‘raw-initrd’ procedure I proposed, than >trying to come up with a one-size-fits-all procedure with many >parameters. I know that your approach is cleaner and nicer for any Guile programmer. On the other hand it can be harder to use for the rest of the world. Kitchen sink issue is matter of configuration and we're all adults here, we can make our decisions. I'm not ignoring your proposal but - I haven't seen a way how it could help me in previous thread - I'm afraid I can't deliver you such solution until I improve my Guile skills. I'm fine with keeping my patches out of tree (they can be found in devel mailing list if anyone is interested in it), I just don't think that I'm the only one facing this sort of problems. I'm sorry I didn't provide you more constructive answer. S_W