<div dir="ltr"><div>Hello Lennart,</div><div><br></div><div>Can you help me in understanding why this push was rejected?</div><div>
<b>Make timedatectl nicely work with read-only filesystems 
#8277 </b></div><div>If there is some major issue. I would like to take this opportunity to make it right and submit it again</div><div><br></div><div><br></div><div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="background-color:rgba(255,255,255,0)"></span>Regards,<br>Shravan Singh<br>(239) 243-0838<br><br>Blue Sparq, Inc.<br>928 NE 24th Lane unit 4 and 5.<br>Cape Coral, FL 33993<br><font size="1"><br>IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please notify the sender immediately and do not disclose the contents to anyone or make copies thereof.</font><br></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 4, 2020 at 11:27 AM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Do, 20.08.20 14:22, Shravan Singh (<a href="mailto:shravan@bluesparq.com" target="_blank">shravan@bluesparq.com</a>) wrote:<br>
<br>
> But no one is telling how to resolve my issue with a read-only<br>
> rootfs.<br>
<br>
There's no concept for having some files in /etc writable and others<br>
not. And you cannot use symlinking for this, nor bind mounts, since<br>
config files in /etc are usually updated atomically, i.e. new versions<br>
written in full into temporary files and then moved into place<br>
atomically so that you either see the old or the new but never<br>
anything half-written. This means that the dir of the file to update<br>
needs to be writable and that the old inode goes away entirely on<br>
update instead of being updated.<br>
<br>
I must say I see little point in having "etc mostly read-only"<br>
though. I mean, either your config is entirely read-only or it<br>
isn't. If it is read-only /etc being read-only is not a problem. If it<br>
can be modified then make /etc the source of truth for it and<br>
writable, and drop everything else from it, so that it only contains<br>
the writable data you care about. A lot of software these days falls<br>
back to fallback settings below /usr somewhere if their config files<br>
in /etc don#t exist, and for the stuff that doesn't work like this,<br>
move it over and symlink it from /etc (you can create those symlinks<br>
with tmpfiles.d factory options).<br>
<br>
> There are other files which can be overwritten in /etc that are linked to a<br>
> file in /run directory for eg /etc/resolv.conf file.<br>
<br>
Well, that file is quite different, resolve.conf is historically was<br>
configuraiton but today is more state than configuraiton, i.e. it is<br>
usually configured dynamically via DHCP or so. Hence people started to<br>
manage it in /run and leave /etc/resolv.conf only as a compat symlink<br>
in place, if you so will.<br>
<br>
> Then why not /etc/localtime. Why is localtime guarded so much<br>
> I refuse to believe that I am the only person facing this problem. But I<br>
> did find some leads now. Will keep you posted<br>
<br>
/etc/localtime is generally considered to be configuration and not<br>
state, hence people are typically fine with leaving it in /etc, since<br>
that's where persistant configuration is supposed to be.<br>
<br>
I am sorry, but /etc on Linux is a single directory, and you can only<br>
cleanly choose between all configuration read only or none, there's no<br>
nice way for a middle ground. Sorry.<br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
</blockquote></div></div>