On 11/24/2015 12:47 PM, Roman Khimov wrote:
В письме от 24 ноября 2015 12:27:30 пользователь Mark Hatle написал:
On 11/24/15 12:05 PM, Roman Khimov wrote:
В письме от 24 ноября 2015 07:47:38 пользователь Mark Hatle написал:
On 11/24/15 4:39 AM, Roman Khimov wrote:
В письме от 23 ноября 2015 15:41:28 пользователь Mariano Lopez написал:
1. Use a separate partition for the configuration.
a. The pro of this method is the partition is not touched during the
update.
b. The con of this method is the configuration is not directly in
rootfs (example: /etc).
That's the right solution, although to do it really right (at least IMO)
you need to implement the /usr merge [1] (and that's orthogonal to using
or not using systemd), which can also help you make your /usr read-only
(because that's just code and static data) with read-write / for user
data of various sorts.
Why does merging /usr have anything to do with this? I've read the case
for merging /usr and / and still don't understand why it "helps". The
key is that if you have separate partitions for /usr and /, then you
need to update both of them in sequence. Merging these two just seems
like a lazy solution to people not wanting to deal with early boot being
self-contained.
It helps in that you can achieve a clear separation of your software and
users data (whatever that is, even if that's just some configuration
files) and only update your part (which is /usr).
This can easily be archived using different partitions like /opt as well.
Usually it leads to more complicated partitioning and more complicated startup
(as well as update) procedure. Of course it can vary from system to system,
but in my experience /usr merge was exactly the thing needed to clearly
separate and simplify things. One way or another you want to have your code
and users data to be separated, /usr merge makes it quite simple.
Bandwidth is a big deal in areas that are not serviced by anything but very
GPRS or worse. So 100 MB is even too big in some cases. Cost is a factor
as is overall bandwidth.
Again, it depends on the product and what you are building if this matters.
The point is we don't want to make some assumptions that preclude
alternative implementations.
Sure.
Thanks to all for your input. The conclusion of this thread is:
1. One size doesn't fit all.
2. Most of the people was fine with the image based update.
3. The recommended way to keep the configuration is to have a separated
data partition.
4. The partition scheme would be:
1. boot. This is the usual boot partition
2. rootfs. Partition used for normal operation.
3. maintenance. This partition will be used to update rootfs.
4. data. This will hold the configuration files. Not modified by
updates.
--
Mariano Lopez
--
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
