[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-0002.html>
More information about the buildroot
mailing list