[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

Bartosz Bilas b.bilas at grinn-global.com
Mon Feb 3 18:41:22 UTC 2020


Nah, sorry guys - I've been mistaken for the email so please ignore the 
previous message then.


Best
Bartek
On 03.02.2020 19:34, Bartosz Bilas wrote:
>
> Hi everyone,
>
> I had finally a couple of time to double-check that and I agree with 
> Jeremy that I was wrong therefore let's reject this patch as it turned 
> out as an unthought idea.
>
>
> Best
> Bartek
> On 03.02.2020 19:28, Bartosz Bilas wrote:
>> Hello everyone,
>>
>> let's reject this patch due to possible upstream solution as Jeremy 
>> mentioned.
>>
>> Best
>> Bartek
>> On 19.11.2019 11:15, Jérémy ROSEN wrote:
>>> As a side-note, I am working with upstream to have a better support 
>>> of (3) : https://github.com/systemd/systemd/pull/14059
>>>
>>> I am a bit cautious about the new config option because it seems too 
>>> "advanced" for a config option (for me, it's something that should 
>>> be set
>>> in a post-image or overlay) but that's open to discussion.
>>>
>>> Please wait a little before applying this patch, if that's the way 
>>> buildroot wants to go, so my pull-request above is solved and we might
>>> backport it to ease our transition.
>>>
>>> Cheers
>>> Jérémy
>>>
>>> Le mar. 19 nov. 2019 à 09:40, Thomas Petazzoni 
>>> <thomas.petazzoni at bootlin.com <mailto:thomas.petazzoni at bootlin.com>> 
>>> a écrit :
>>>
>>>     Hello,
>>>
>>>     On Sun, 17 Nov 2019 17:00:05 +0100
>>>     Arnout Vandecappelle <arnout at mind.be <mailto:arnout at mind.be>> wrote:
>>>
>>>     > > Could something like that be enough ? can we trust "remount
>>>     RW" ?
>>>     > > maybe "remount RW" should be renamed "create a RW
>>>     filesystem" and enable various
>>>     > > tweaks related to RO vs RW
>>>     >
>>>     >  As written above: no.
>>>     >
>>>     >  The problem is: we're not a distro.
>>>
>>>     Agreed.
>>>
>>>     > We leave too much freedom for the user to
>>>     > integrate things in various ways to be able to make
>>>     assumptions about what is
>>>     > the right way to do things. So, the only thing we can do is to
>>>     give a decent
>>>     > out-of-the-box experience, and let the user figure out how to
>>>     tweak things -
>>>     > possibly adding a config option for a common situation that is
>>>     easily handled in
>>>     > a generic way. The other thing we can do is to provide
>>>     documentation about the
>>>     > proper way to integrate things in different scenarios.
>>>     >
>>>     >  I'm starting to agree that this option is maybe not that great.
>>>
>>>     But I would in fact not come to the same conclusion. Having this
>>>     empty
>>>     machine-id file is useless and causes problems when the
>>>     filesystem is
>>>     R/W. So for the sake of supporting the R/O case (for which we create
>>>     this empty machine-id file), we make the R/W experience less good.
>>>
>>>     So I'd say that the right approach is to not do too much
>>>     integration by
>>>     precisely having the option proposed by Bartosz, with many the tweak
>>>     that it should default y if rootfs is really, and default disable
>>>     otherwise, but while still being an option that the user can tweak,
>>>     because as you rightfully explained, the RW/RO remount option is
>>>     just a
>>>     clue, not a definitive answer on whether /etc is writable or not.
>>>
>>>     To me, having this option matches the Buildroot way: we are not a
>>>     distro, we don't enforce how the system should work, so we
>>>     provide the
>>>     appropriate options, while making sure the option has the most
>>>     sensible
>>>     default values.
>>>
>>>     Generally speaking, Buildroot kind of supports "out of the box"
>>>     two use
>>>     cases:
>>>
>>>      (1) The root filesystem is completely read-write.
>>>
>>>      (2) The root filesystem is completely read-only, and all files
>>>     that need
>>>          to be written are stored in tmpfs, and therefore are volatile.
>>>
>>>     I.e, we do not have any explicit support for what is I guess a much
>>>     more common use case than (2):
>>>
>>>      (3) The root filesystem is completely read-only, but there is
>>>     another
>>>          read-write partition somewhere that stores the information
>>>     that can
>>>          change but needs to be persistent (user configuration, etc.)
>>>
>>>     Since we don't have explicit support for (3), there is no way we can
>>>     properly support machine-id and ConditionFirstBoot in the case
>>>     of (2),
>>>     because there's nowhere we can store /etc/machine-id.
>>>
>>>     So the best we can do is in the case of (2), default to creating an
>>>     empty /etc/machine-id, while giving the possibility for the user
>>>     implementing (3) in its own way, to disable the creation of the
>>>     empty
>>>     /etc/machine-id.
>>>
>>>     Best regards,
>>>
>>>     Thomas
>>>     -- 
>>>     Thomas Petazzoni, CTO, Bootlin
>>>     Embedded Linux and Kernel engineering
>>>     https://bootlin.com
>>>
>>>
>>>
>>> -- 
>>> SMILE <http://www.smile.eu/>
>>>
>>> 20 rue des Jardins
>>> 92600 Asnières-sur-Seine
>>>
>>> 	
>>> *Jérémy ROSEN*
>>> Architecte technique
>>>
>>> email jeremy.rosen at smile.fr <mailto:jeremy.rosen at smile.fr>
>>> phone  +33 6 88 25 87 42
>>> url http://www.smile.eu <http://www.smile.eu/>
>>>
>>> Twitter <https://twitter.com/GroupeSmile> Facebook 
>>> <https://www.facebook.com/smileopensource> LinkedIn 
>>> <https://www.linkedin.com/company/smile> Github 
>>> <https://github.com/Smile-SA>
>>>
>>>
>>> Découvrez l’univers Smile, rendez-vous sur smile.eu 
>>> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200203/40ed1c57/attachment.html>


More information about the buildroot mailing list