Re: [RAUC] Errors in Using Rauc
Hi, On 03/09/2017 12:13 PM, gurpartap singh wrote: I installed RAUC with --disable-network option because of libcurl dependency issues. I have done below steps so far: Created manifest.raucm like this [update] compatible=rauc-demo-x86 version=2015.04-1 [image.rootfs] sha256=4c03d5be6780e64a604e94222a2da50e671698b9c1d764f1bbc617558de80f98 size=11376640 filename=rauc.img this one looks ok. MY /etc/rauc/system.conf is: [system] compatible=rauc-demo-x86 bootloader=uboot mountprefix=/mnt/rauc [slot.rootfs.0] device=/dev/mmcblk0p1 type=raw bootname=A this one will require a second rootfs partition to allow you installing updates when running from the productive one. But when I try to install this update using: ./rauc install -d update.raucb it shows following log: Domains: 'rauc' (rauc:21307): rauc-DEBUG: install started (rauc:21307): rauc-DEBUG: input bundle: /home/rauc/update.raucb Error creating proxy: Error calling StartServiceByName for de.pengutronix.rauc: Timeout was reached D-Bus error while installing `/home/rauc/update.raucb` There seems to be a communication issue between the command line client and the service. Did you try to start the service. Do you have the d-bus config installed? Could you get any log data from the service itself? Previously I have done: ./autogen.sh ./configure --disable-network make make install service rauc start This looks ok so far. LOG of ./rauc info -d update.raucb Domains: 'rauc' rauc-Message: Reading bundle: update.raucb rauc-Message: Verifying bundle... 3069734912:error:2E09D06D:CMS routines:CMS_verify:content verify error:../crypto/cms/cms_smime.c:393: (rauc:21318): rauc-WARNING **: signature verification failed: error:2E09A09E:CMS routines:CMS_SignerInfo_verify_content:verification failure I assume you executed this on the target? Obviously, there is a certificate verification error. Did you set up the key, cert and keychain correctly? If you want to (for test-purpose) inspect the bundle without verification, you can use the `--no-verify` argument. But for installation the verification is mandatory thus it should work with `info`, too. QUESTION 2: How to use it with uboot? Can u please elaborate how to install library to modify u-boot variables and environment. In the documentation there is the chapter `Interfacing with the bootloader`: http://rauc.readthedocs.io/en/latest/integration.html#interfacing-with-the-bootloader Did you already try what is described in there? If there is some information missing please let us know. The subsection "U-Boot" also points you to the u-boot example script located in the `contrib/` folder. This should be a good starting point. Best regards Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
[RAUC] [ANNOUNCE] RAUC v0.1.1 released
Hi,
we are proud to announce that we've just released RAUC v0.1.1:
https://github.com/rauc/rauc/releases/tag/v0.1.1
This is mainly a bugfix release. We also introduced a CHANGES file that
allows you to track the project development from a more high-level
perspective:
http://rauc.readthedocs.io/en/latest/changes.html
For the current version, the changes are as follows (copy+paste from
`CHANGES`):
Release 0.1.1 (released May 11, 2017)
-
.. rubric:: Enhancements
* systemd service: allow systemd to manage and cleanup RAUCs mount directory
.. rubric:: Bugs fixed
* Fix signature verification with OpenSSL 1.1.x by adding missing binary
flag
* Fix typo in json status output formatter ("mountpint" -> "mountpoint")
* Fixed packaging of systemd service files by removing generated service
files
from distribution
* src/context: initialize datainstream to NULL
* Added missing git-version-gen script to automake distribution which made
autoreconf runs on release packages fail
* Fixed D-Bus activation of RAUC service for non-systemd systems
.. rubric:: Documentation
* Added contribution guideline
* Added CHANGES file
* Converted README.md to README.rst
* Added RAUC logo
* Several typos fixed
* Updated documentation for mainline PTXdist recipes
Best regards,
The RAUC Team
--
Pengutronix e.K. | Enrico Jörns|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
RAUC mailing list
___
RAUC mailing list
Re: [RAUC] Bootloader updates
Hello Martin, On 05/18/2017 11:45 AM, Martin Hollingsworth wrote: Hello RAUC Team, I am currently implementing software update on my embedded target and evaluating the usage of RAUC. But I have trouble finding a solution for the following scenario, which needs a little explanation, but can be summerized as: „How does Rauc handle Bootloader Updates?” Here is what I want to achieve: A software release is a combination of multiple software components in specific versions, that have been tested and defined fit for usage together on an embedded target. Lets say a simple example would be a bootloader and a rootFS (which includes linux and some custom software pre-installed). that sounds rational to me (despite the fact that you might not want to update you bootloader with each rootFS update). When I update my system, I secure my linux operating system using a symmetric A/B setup. If the update fails, I can always jump back to the last slot and continue regular device operation. Yes, that is one of the common Scenarios RAUC will be able to handle for you. But when I update my bootloader AND my linux system together, after exchanging the bootloader I cannot jump back to the last running linux, because now the bootloader configuration might not match the configuration expected from the previous bootloader. How does RAUC approach this issue? this is not something that really touches RAUC and I am not sure if I got you problem right. You intend to exchange the bootloader, but this should not have any consequence for the stored update configuration. The information about which slot has which priority, remaining attempts, etc. will normally be persisted in a different storage location than your bootloader itself. E.g. a different partition on your FLASH or a distinct EEPROM location, etc. Thus, after having updated your bootloader, it will read your previous configuration and know in which state you are! The only scenario where you will get into troubles is when the new bootloader is unable to read the storage format your old one used. But 1) this should not happen or is an issue that is really out of scope of what an update tool can do for you. If I did not really get what your worries are, please let me know. May I ask which bootloader you are using? Best regards, Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
Re: [RAUC] Progress indication
Hi Leif,
On 05/11/2017 12:29 PM, Middelschulte, Leif wrote:
Hello Enrico,
Am Mittwoch, den 10.05.2017, 15:22 +0200 schrieb Enrico Joerns:
Hi Leif,
On 05/04/2017 04:33 PM, Middelschulte, Leif wrote:
Now, about my second question: How does a custom hook script
communicate its progress back to the install-handler (i.e. rauc
service)?
I'd go modify rauc's update_handler.c, set the
G_SUBPROCESS_FLAGS_STDOUT_PIPE flag for the spawned slot
script-process and read back the progress and propagate it to the
DBus interface using r_context_send_progress. Is that the right
direction here?
in RAUC, the progress is generated by adding a 'step' for an action
you perform. When starting the action you call
r_context_begin_step(), when terminating the action you call
r_context_end_step(). It is important to know that steps have a
nesting depth that allows visualizers to control the granularity of
information they show. A step can also be marked as either
successful or failed.
An example is the "Determining slot states" step:
r_context_begin_step("determine_slot_states", "Determining slot
states", 0); [...] r_context_end_step("determine_slot_states",
res);
Thus, this should be the interface to use to add new steps.
The current granularity we have does not go deeper than "Copying
image". This will be called for both a default install handler as
well as for an install hook.
If you ask for progress from the install hook, you intend to be
more fine-grained with your messages?
Yes, since some updates will take quite a while, we'd like to display
an approximate progress (e.g. bytes written/byte to be written).
I saw that there's a "send_progress" callback one can use from
*within* the installer.
Not sure if I understand you right, but this is what I described above,
isn't it? A `git grep send_progress` only gives me
`r_context_send_progress`.
But currently it's not even used to indicate any progress of raw (stream)
copies, right?
No, there is currently no progress indication for raw stream copies. For
this it would work, but most other copy operations performed by binaries
(such as nandwrite) do not provide any progress, thus we did not put too
much effort on it, yet.
I'm trying to stick to upstream code as much as possible and,
eventually, contribute what's necessary to communicate progress
back.
That sounds like the perfect way for me :)
If I understood the code right, I'd go and do the following:
1.) make my hook script write its percentual progress to stdout
2.) I'd fork RAUC Service's update_handler code to read back STDOUT from the
spawned's process (i.e. hook.sh)
> 3.) use send_progress to publish the information to the "dumb" GUI
Basically, yes, but what you should use for indicating progress (had to
dig in the code for that, too ;) ) is `r_context_set_step_percentage()`.
You can read from its documentation string that its designed for such
purposes you have, where you have a step that you want to give a number
of nonspecific substeps. Thus like a copy progress inside a `installing
slot` step.
There you can provide percentage steps that will also propagate to the
global progress, meaning that you will have something like
50% Updating rootfs0...
51% Updating rootfs0...
52% Updating rootfs0...
53% Updating rootfs0...
...
Unfortunately, the only place in the code where this is used, already is
the "/progress/test_explicit_percentage" test in test/progress.c.
Hope that helps you.
Best regards, Enrico
--
Pengutronix e.K. | Enrico Jörns|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
RAUC mailing list
Re: [RAUC] unable to mark slot as good or bad
Hi, On 09/15/2017 08:44 AM, Aditya Purohit wrote: Firstly I want to thank team RAUC for good documentation and supportI am working on beaglebone with debian jessie and I am facing a couple of issues. Firstly, I am able to update my appfs using rauc but update for rootfs is failing with the following error. marking slot rootfs.1 as bad Cannot parse config file: No such file or directory Error: environment not initialized > My guess is something related to my 'make' configuration wherein the required configuration file is not provided at the required place. However due to lack of information from the errror message I am unable to identify the exact file or the exact problem per se. I've already answered this question in the corresponding GitHub issue https://github.com/rauc/rauc/issues/173 let's continue discussion there. Secondly, I want to integrate hawkbit with rauc and wish to use rauc-hawkbit client for the same. However there is little documentation on rauc hawkbit client. Any staring point on how to use it would be appreciated. Did you already take a look at the README file and the Module documentation? https://github.com/rauc/rauc-hawkbit/blob/master/README.rst http://rauc-hawkbit.readthedocs.io/en/latest/modules/modules.html Could you explain a bit more detailed what kind of information you expect? I know that the tool is not well documented, yet, but it would help knowing a bit more about what is missing. Best regards, Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
[RAUC] [ANNOUNCE] RAUC v0.2 released
Hi,
we are proud to announce that we've just released RAUC v0.2:
https://github.com/rauc/rauc/releases/tag/v0.2
This release contains a bunch of enhancements provided by the community
over the last months. Beside a number of bug fixes, error handling
improvements and a significant documentation update we introduce new
features and options further extending the scope of applications and
easing the usability of RAUC
Progress information in the CLI, support for resigning bundles, delayed
update activation, a `--keyring` argument, certificate information and
trust chain dumping are only a small excerpt of what has been added.
Find the more extensive list of changes from
http://rauc.readthedocs.io/en/latest/changes.html attached below.
Stay tuned, and contribute! We just started working for the next
release, already having a bunch useful extensions pending...
Best regards and happy (and robust) updating,
The RAUC Team
---
CHANGES:
Release 0.2 (released Nov 7, 2017)
--
.. rubric:: Documentation
* Added docs/, CHANGES and README to tarball
* Added and reworked a bunch of documentation chapters
* Help text for ``rauc bundle`` fixed
* Added short summary for command help
.. rubric:: Enhancements
* Added ``--override-boot-slot`` argument to force booted slot
* Display installation progress and error cause in CLI
* Allow installing uncompressed tar balls
* Error reporting for network handling and fail on HTTP errors
* Added ``--keyring`` command line argument
* Added ``activate-installed`` key and handling for ``system.conf`` that
allows
installing updates without immediately switching boot partitions.
* Extended ``rauc status mark-{good,bad}`` with an optional slot identifier
argument
* Added subcommand ``rauc status mark-active`` to explicitly activate slots
* New D-Bus method ``mark`` introduced that allows slot activation via D-Bus
* Added ``tar`` archive update handler for ``vfat`` slots
* Introduced ``rauc resign`` command that allows to exchange RAUC signature
without modifying bundle content
* Display signature verification trust chain in output of ``rauc info``.
Also generate and display SPKI hash for each certificate
* Added ``--dump-cert`` argument to ``rauc info`` to allow displaying signer
certificate info
.. rubric:: Bugs fixes
* Flush D-Bus interface to not drop property updates
* Set proper PATH when starting service on non-systemd systems
* Include config.h on top of each file to fix largefile support and more
* Let CLI properly fail on excess arguments provided
* Do not disable bundle checking for ``rauc info --no-verify``
* Properly clean up mount points after failures
* Abort on inconsistent slot parent configuration
* Misc memory leak fixes
* Fixes in error handling and debug printout
* Some code cleanups
.. rubric:: Testing
* Miscellaneous cleanups, fixes and refactoring
* Add tests for installation via D-Bus
* Let Travis build documentation with treating warnings as errors
* Allow skipping sharness tests requiring service enabled
* Explicitly install dbus-x11 package to fix Travis builds
* Fix coveralls builds by using ``--upgrade`` during
``pip install cpp-coveralls``
* Use gcc-6 for testing
--
Pengutronix e.K. | Enrico Jörns|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
RAUC mailing list
Re: [RAUC] Rauc and Hawkbit server
Hi, On 12/05/2017 05:46 PM, Laurent GUILLIER wrote: Hi, first of all thanks for Rauc which is a very nice piece of software! I am now trying to use rauc on a imx6 target, along with hawkbit as the update server. Everything runs fine, except that after the reboot following the successful slot update, the rauc-hawkbit client detects the update again, and starts the process again and again ... the slots are alternated as it would expected if each update cycle was required (i.e. different bundles). Looks like the client doesn't tell hawkbit the update process was succesfully performed, from downloading to reboot on the brand new slot. Any clue to solve that little issue would be appreciated! do you have any log from the rauc-hawkbit python client running during the update? Not that you can also start it in debug mode to increase verbosity as listed here [1]. A log would help finding out what is going on and what not. And, do you see feedback in the targets Action history view in the hawkBit Web UI? As in the Demo video [2] shown at 0:25. The update must have a green mark to be considered successful by hawkBit and to not trigger an update again. Best regards Enrico [1] https://github.com/rauc/rauc-hawkbit#debugging [2] https://www.youtube.com/watch?v=SLX0Fd_y6Cc -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
Re: [RAUC] Rescue system
Hi Kevin, On 05/17/2018 04:29 PM, Kevin Golding wrote: Hello, Am just getting my head around RAUC, and wondered if I'm right in thinking that a rescue system is not included with RAUC? i.e. I would need to find or create a small bootable rescue system that would run the RAUC update command say via say from a file on a USB stick? conceptually RAUC is a generic update framework that can run on your Linux device and handle safe and atomic updates of partitions etc. It does neither provide any ready-to-use distribution nor depend on any specific. Thus building a system is always a task that should be solved outside of an update tool. With OE/Yocto, PTXdist and buildroot good build system exists for this that allow you to generate well defined customized systems in versioned and reproducible manner. RAUC also does not depend on any specific source for its update artifacts. Neither on the production system nor on any rescue system. You can fetch your update from USB / network / storage media or whatever fits your concept or platform. Nevertheless, conceptually a rescue system is surely supported. A slot configuration for your rescue system (and the default ones, too) would look like [slot.rootfs.0] device=/dev/mmcblk0p1 ... [slot.rootfs.1] device=/dev/mmcblk0p1 ... [slot.rescue.0] device=/dev/sda1 ... This would allow detecting RAUC that it is not running from one of the normal rootfs partitions but from the rescue partition instead and that it can safely upate the others. If I am right, are there any examples of a rescue system available? No. A rescue system can be as small as only a minimal kernel+initramfs+dtb with RAUC binary + dependencies which will result in a few kB. Most of the build systems above provide a minimal rootfs configuration that you can simply extend with RAUC. https://rauc.readthedocs.io/en/latest/integration.html Did that roughly point you in the right direction? Best regards, Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
[RAUC] [ANNOUNCE] RAUC v0.4 released
Hi, we are proud to announce that we've just released RAUC v0.4: https://github.com/rauc/rauc/releases/tag/v0.4 Beside a few fixes, this version provides some useful new features such as atomic bootloader updates for eMMC, a central storage location for the RAUC system status information and experimental support for using RAUC with the casync chunking tool for delta updates over the network. Find more details in the full changes list below. Best regards and happy (and robust) updating, The RAUC Team --- CHANGES: Release 0.4 (released Apr 9, 2018) -- **Enhancements** - Add `barebox-statename` key to `[system]` section of system.conf in order to allow using non-default names for barebox state - Support atomic bootloader updates for eMMCs. The newly introduced slot type `boot-emmc` will tell RAUC to handle bootloader updates on eMMC by using the `mmcblkXboot0/-boot1` partitions and the EXT\_CSD registers for alternating updates. - Support writing `*.vfat` images to vfat slots - Add basic support for streaming bundles using casync tool. Using the casync tool allows streaming bundle updates chunk-wise over http/https/sftp etc. By using the source slot as a seed for the reproducible casync chunking algorithm, the actual chunks to download get reduced to only those that differ from the original system. - Add `rauc convert` command to convert conventional bundles to casync bundle and chunk store - Extend update handler to handle `.caibx` and `.caidx` suffix image types in bundle - Added `--detailed` argument to `rauc status` to obtain newly added slot status information - Added D-Bus Methods `GetSlotStatus` to obtain collected status of all slots - Extended information stored in slot status files (installed bundle info, installation and activation timestamps and counters) - Optionally use a central status file located in a storage location not touched during RAUC updates instead of per-slot files (enabled by setting `statusfile` key in `[system]` section of `system.conf`). - Add `write-slot` command to write images directly to defined slots (for use during development) **Bug fixes** - Fix documentation out-of-tree builds - Fixed packaging for dbus wrapper script rauc-service.sh - Some double-free and error handling fixes **Testing** - Create uncrustify report during Travis run **Code** - Unified hash table iteration and variable usage - Add uncrustify code style configuration checker script to gain consistent coding style. Committed changes revealed by initial run. **Documentation** - Updated and extended D-Bus interface documentation - Added documentation for newly added features (casync, central slot status, etc.) - Fixed and extended Yocto (meta-rauc) integration documentation - Add link to IRC/Matrix channel - Some minor spelling errors fixed -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
Re: [RAUC] Regarding booting problem ,when booting manually
On 10/18/18 7:29 AM, Middelschulte, Leif wrote:
Hello Abhishek,
Am Donnerstag, den 18.10.2018, 10:46 +0530 schrieb Abhishek Kumar Rai:
Hi Team,
I am facing one issue after doing following steps:
1. flashing any image in appfs.
2. rauc status mark-active rootfs.0.(Activated rootfs.0)
Is this update considered successful by rauc? What do the logs say? If you're
using systemd, you might want to check using `journalctl -u rauc`.
3. reboot
It is booting from rootfs.1,instead of rootfs.0 which has been marked active.
If your update was indeed succesful, your boot target's `remaining_attempts`
(see [0]) are 0.
I fear when using U-Boot he does not have the chance to use such a
sophisticated boot selection framework as barebox has ;)
But it would be worth making sure that the U-Boot scripts perform as expected.
For debugging, one can also take a look at the raw output of fw_printenv in
userspace
before and after performing mark-good to see if the variables changed according
to your expectation.
It could also help verifying if the variables look the same in U-Boot as they
do in userspace.
It seems that rauc status mark-active rootfs.0 is having some issue ?
Again, you might want to check rauc's logs on this.
Yes, should be really hard to say where the issue comes from with the current
information.
Another crucial information that we need: Which version of RAUC do you use?
Regards, Enrico
[0]
https://www.barebox.org/doc/latest/user/bootchooser.html#the-bootchooser-algorithm
BR,
Leif
Please find system.conf content below
{{{
$ cat /etc/rauc/system.conf
[system]
compatible=eximius
bootloader=uboot
mountprefix=/mnt/rauc
statusfile=/factory/rauc.status
[keyring]
path=cert.pem
[slot.rootfs.0]
#device=/dev/mmcblk1p1
device=/dev/disk/by-path/platform-219c000.usdhc-part1
type=ext4
bootname=A
[slot.rootfs.1]
#device=/dev/mmcblk1p2
device=/dev/disk/by-path/platform-219c000.usdhc-part2
type=ext4
bootname=B
[slot.appfs.0]
#device=/dev/mmcblk1p5
device=/dev/disk/by-path/platform-219c000.usdhc-part5
type=ext4
bootname=app
}}}
Please provide your valuable input or suggestions on the above problem.
Regards,
Abhishek Rai
The information contained in this e-mail message (including any attachments)
may be confidential, proprietary, privileged, or otherwise exempt from
disclosure under applicable laws. It is intended
to be conveyed only to the designated recipient(s). Any use, dissemination,
distribution, printing, retaining or copying of this e-mail (including its
attachments) by unintended recipient(s) is
strictly prohibited and may be unlawful. If you are not an intended recipient
of this e-mail, or believe that you have received this e-mail in error, please
notify the sender immediately (by
replying to this e-mail), delete any and all copies of this e-mail (including
any attachments) from your system, and do not disclose the content of this
e-mail to any other person. Thank you for
your cooperation.
This e-mail message (including any attachments) may be confidential,
proprietary, privileged, or otherwise exempt from disclosure under applicable
laws. If you are not an intended recipient, please
delete this message. Thank you.
___
RAUC mailing list
___
RAUC mailing list
--
Pengutronix e.K. | Enrico Jörns|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
RAUC mailing list
[RAUC] [ANNOUNCE] RAUC v1.0 Release Candidate 1 Available
Hi, we are (really) proud to announce that we've just prepared the first release candidate for RAUC v1.0: https://github.com/rauc/rauc/releases/tag/v1.0-rc1 This version adds several enhancements and new features concerning signing and signature handling. One of the most important improvements is the support for passing Keys/Certificates stored on PKCS#11 tokens (e.g. for using a smart card or HSM). Also the boot selection interface gained several fixes and enhancements, especially concerning the U-Boot integration that now implements the full feature set of obtaining and setting the boot status. Several extensions of the D-Bus API and some code refactoring now allow 'rauc status' to fully work over D-Bus (if enabled) and finalizes the clear separation between client and service. Another topic that got a lot attention is easing RAUC debugging by providing more targeted debugging and error messages, adding documentation, etc. It is important to note that also several potential issues for the actual installation process were fixed, e.g. by adding proper fsync() handling, using O_EXCL for opening devices, or by fixing uid/gid handling during tar extraction. RAUC now also fully supports using file:// URI's and allows to open bundles that have a custom file name extensions for cases where this really mandatory of any reason. The rest are 'only' minor new options, bug fixes, documentation updates, typo fixes, etc. Find more details in the full changes list below. Note, as this is an RC for the upcoming 1.0 version of RAUC, please help by testing this pre-release on all environments you want it to work in and give us feedback in case of any issues. Best regards and happy (and robust) updating, The RAUC Team --- RELEASE 1.0-RC1 (RELEASED OCT 12, 2018) ENHANCEMENTS - Bundle creation - Add support for passing Keys/Certificates stored on PKCS#11 tokens (e.g. for using a smart card or HSM). See the PKCS#11 Support section for details. - Print a warning during signing if a certificate in the chain will expire within one month - If keyring is given during bundle creation, automatically verify bundle signature and trust chain - Configuration (see the reference for the [system],[keyring] and [slot.*.*] sections for details) - Add extra-mount-opts argument to slot config to allow passing custom options to mount calls (such as user_xattr or seclabel) - Implement support for readonly slots that are part of the slot description but should never be written by RAUC - Add option use-bundle-signing-time to use singing time for verification instead of the current time - Introduce max-bundle-download-size config setting (by Michael Heimpold) - Rename confusing force-install-same flag to ignore-checksum (old remains valid of course) (by Jan Remmet) - Add strict parsing of config files as we do for manifests already. This will reject configs with invalid keys, groups, etc. to prevent unintentional behavior - Installation - Remove strict requirement of using .raucb file extension, although it is still recommended - Export RAUC slot type to handlers and hooks (by Rasmus Villemoes) - Add *.squashfs to raw slot handling (by Emmanuel Roullit) - Add checking of RAUC bundle identifier (squashfs identifier) - *.img files can now be installed to ext4, ubifs or vfat slots (by Michael Heimpold) - Warn if downloaded bundle could not be deleted - Expose system information (variant, compatible, booted slot) over D-Bus (by Jan Remmet) - The rauc status command line call now only uses the D-Bus API (when enabled) to obtain status information instead of loading configuration and performing operations itself. This finalizes the clear separations between client and service and also allows calling the command line client wihout requiring any configuration. - Add debug log domain rauc-subprocess for printing RAUC subprocess invocations. This can be activated bysetting the environment variable G_MESSAGES_DEBUG=rauc-subprocess. See the Debugging RAUC section for details. - Enhancement of many debug and error messages to be more precise and helpful - Let U-Boot boot selection handler remove slot from BOOT_ORDER when marking it bad - Implemented obtaining state and primary information for U-Boot boot selection interface (by Timothy Lee) - Also show certificate validity times when the certificate chain is displayed - Added a simple CGI as an example on how to code against the D-Bus API in RAUC contrib/ folder. (by Bastian Stender) BUG FIXES - Bootchooser EFI handler error messages and segfault fixed (by Arnaud Rebillout) - Fix preserving of primary errors while printing follow-up errors in update_handlers (by Rasmus Villemoes) - Make not finding
Re: [RAUC] RAUC
Hi Taimir, On 10/29/18 11:27 AM, Taimir Aguacil wrote: Dear RAUC team, I attended the embedded Linux conference, and got to know you and see your demo there! There were still some few open questions that I am putting in this email. It would be very helpful to get the answers. Right now bundle and network modes are supported, is an update over USB supported ? If not, are there any plans to do so ? maybe this needs some clarification: 'Bundle' is the data/archive format that we use for packing or unpacking the update artifacts and meta information. This is not tied to any update *source*, which (potentially) could be quite everything from a µSD Card, over a USB stick to a network upload or whatever. The real 'network mode' you might refer to, is deprecated in RAUC and will not gain further development. This in fact was a 'non-bundle mode' using a signed manifest and requiring to download the install artifacts separately from a server. However, this does not limit usage over network. Rather, it has been replaced by the more powerful usage of casync for chunked delta-like downloads. In most cases the right way to go is to let an independent unit handle the provisioning of the bundle, e.g. by mounting a USB stick, downloading a file over network / internet, or whatever, and then trigger RAUC (using D-Bus or CLI) with the path tho this (local or remote) bundle and let it do the rest of the work. We have some examples code for some scenarios, e.g. for using a CGI or interacting with hawkbit, but our opinion is that the bundle source handling is quite use-case specific. Furthermore, for an update over the air (Using cellular or WLAN), is it possible ? Or do I need to include a mechanism for the bundle download and then use the bundle mode where the bundle is on a partition ? This basically picks up the same questions I hopefully answered on the previous question already. In general, when you download an update, there are two options: (1) either you need to have some temporary storage for the entire artifact (e.g. a data partition, or RAM) or (2) you can stream the data directly into your target device / partition. The latter is what casync bundles [1][2] offer you. Also note that when using tar and compression the downloaded image might be much smaller than the actual partition it should be installed to. I hope that answers your question. Please also consider subscribing to this Mailing list as, by default, it does not allow non-members to post questions (to prevent Spam). Best regards, Enrico [1] https://rauc.readthedocs.io/en/latest/advanced.html#rauc-casync-support [2] http://0pointer.net/blog/casync-a-tool-for-distributing-file-system-images.html -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
Re: [RAUC] RAUC
Hi Taimir, On 10/30/18 12:27 PM, Taimir Aguacil wrote: Hi Enrico, Thank you for your detailed answer. This clarified some confusions. great :) How do I subscribe to the mailing list ? Either visit the mailto-links here: https://www.rauc.io/pages/support.html or 'manually' send a Mail with subject 'subscribe' to rauc-requ...@pengutronix.de. Best regards Enrico BR Taimir From: Enrico Joerns Sent: Tuesday, October 30, 2018 8:39 AM To: Taimir Aguacil Cc: rauc@pengutronix.de Subject: Re: [RAUC] RAUC Hi Taimir, On 10/29/18 11:27 AM, Taimir Aguacil wrote: Dear RAUC team, I attended the embedded Linux conference, and got to know you and see your demo there! There were still some few open questions that I am putting in this email. It would be very helpful to get the answers. Right now bundle and network modes are supported, is an update over USB supported ? If not, are there any plans to do so ? maybe this needs some clarification: 'Bundle' is the data/archive format that we use for packing or unpacking the update artifacts and meta information. This is not tied to any update *source*, which (potentially) could be quite everything from a µSD Card, over a USB stick to a network upload or whatever. The real 'network mode' you might refer to, is deprecated in RAUC and will not gain further development. This in fact was a 'non-bundle mode' using a signed manifest and requiring to download the install artifacts separately from a server. However, this does not limit usage over network. Rather, it has been replaced by the more powerful usage of casync for chunked delta-like downloads. In most cases the right way to go is to let an independent unit handle the provisioning of the bundle, e.g. by mounting a USB stick, downloading a file over network / internet, or whatever, and then trigger RAUC (using D-Bus or CLI) with the path tho this (local or remote) bundle and let it do the rest of the work. We have some examples code for some scenarios, e.g. for using a CGI or interacting with hawkbit, but our opinion is that the bundle source handling is quite use-case specific. Furthermore, for an update over the air (Using cellular or WLAN), is it possible ? Or do I need to include a mechanism for the bundle download and then use the bundle mode where the bundle is on a partition ? This basically picks up the same questions I hopefully answered on the previous question already. In general, when you download an update, there are two options: (1) either you need to have some temporary storage for the entire artifact (e.g. a data partition, or RAM) or (2) you can stream the data directly into your target device / partition. The latter is what casync bundles [1][2] offer you. Also note that when using tar and compression the downloaded image might be much smaller than the actual partition it should be installed to. I hope that answers your question. Please also consider subscribing to this Mailing list as, by default, it does not allow non-members to post questions (to prevent Spam). Best regards, Enrico [1] https://rauc.readthedocs.io/en/latest/advanced.html#rauc-casync-support [2] http://0pointer.net/blog/casync-a-tool-for-distributing-file-system-images.html -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
Re: [RAUC] Issues when executing rauc ,while booting from usb
Hi Abhishek, I fear I left this mail uncommented.. On 10/23/18 11:16 AM, Abhishek Kumar Rai wrote: Hi Enrico, Thanks for your prompt reply. For us the 'realpath' command is working fine. The devices do exist at the respective location. Below are the logs from our end for the post-boot scenario and the bootargs. It seems RAUC is trying to look for device '-01' whereas the actual device is '1b325bba-01'.__Is there a way we can configure RAUC in userspace to look for device 1b32bba-01 in place of -01?_ _*Kernel bootargs*_ _*MMC: *_ Kernel command line: console=ttymxc0,115200 root=PARTUUID=*1b325bba*-01 rootwait rw *rauc.slot=A* video=mxcfb0:dev=lcd,TRULY-WVGA,if=RGB24,rotate =3 consoleblank=0 vt.global_cursor_default=0 _*USB:*_ Kernel command line: console=ttymxc0,115200 root=PARTUUID=**-01 rootwait rw video=mxcfb0:dev=lcd,TRULY-WVGA,if=RGB24,rotate=3 consolebl ank=0 vt.global_cursor_default=0 In USB boot, PARTUUID is and realpath won't work for this. You need to set a valid disk id in your USB MBR in order to make this work. _*USB post-boot logs*_ *root@test:~# mount* /dev/sda1 on / type ext4 (rw,relatime,data=ordered) ... ... root@test:~# root@test:~# root@test:~# *root@test:~# ls /dev/disk/by-partuuid/** /dev/disk/by-partuuid/1b325bba-01 /dev/disk/by-partuuid/1b325bba-03 /dev/disk/by-partuuid/1b325bba-05 /dev/disk/by-partuuid/1b325bba-02 /dev/disk/by-partuuid/1b325bba-04 root@test:~# root@test:~# *root@test:~# realpath /dev/disk/by-partuuid/** /dev/mmcblk1p1 /dev/mmcblk1p2 /dev/mmcblk1p3 /dev/mmcblk1p4 /dev/mmcblk1p5 Your logs show that there are definitely no /dev/disk/by-partuuid-symlinks for the USB stick (and thus that realpath does not work for USB; as you can see there are only mmc-symlinks). Of course your eMMC is still fine, but you do not boot from it. root@test:~# root@test:~# *root@test:~# rauc status* rauc-Message: Failed to resolve realpath for '/dev/disk/by-partuuid/**-01' Failed to determine slot states: Did not find booted slot Yes, RAUC needs to detect where it is booted from to operate safely. One option is to obtain this info from the root= by finding the appropriate root device. Another (actually the preferred) option of identifying the booted device in RAUC is to pass this information explictily from the bootloader via kernel command line arg 'rauc.slot='. _*MMC post-boot logs*_ *root@test:~# mount* /dev/mmcblk1p1 on / type ext4 (rw,relatime,data=ordered) ... ... root@test:~# ls /dev/disk/by-partuuid/* /dev/disk/by-partuuid/1b325bba-01 /dev/disk/by-partuuid/1b325bba-03 /dev/disk/by-partuuid/1b325bba-05 /dev/disk/by-partuuid/1b325bba-02 /dev/disk/by-partuuid/1b325bba-04 root@test:~# root@test:~# *root@test:~# realpath /dev/disk/by-partuuid/* *** /dev/mmcblk1p1 /dev/mmcblk1p2 /dev/mmcblk1p3 /dev/mmcblk1p4 /dev/mmcblk1p5 root@test:~# root@test:~# root@test:~# root@test:~# *root@test:~# rauc status* Compatible: klondike-test Variant: (null) Booted from: A Activated: rootfs.0 slot states: rootfs.0: class=rootfs, device=/dev/disk/by-path/platform-219c000.usdhc-part1, type=ext4, bootname=A state=booted, description=, parent=(none), mountpoint=(none) boot status=good rootfs.1: class=rootfs, device=/dev/disk/by-path/platform-219c000.usdhc-part2, type=ext4, bootname=B state=inactive, description=, parent=(none), mountpoint=(none) boot status=bad root@test:~# Ok, this works fine as expected :) Best regards, Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
Re: [RAUC] Regarding usage of hook
Hi Abhishek,
On 9/26/18 1:59 PM, Abhishek Kumar Rai wrote:
Abhishek Kumar Rai mailto:abhish...@eximiusdesign.com>>
5:12 PM (16 minutes ago)
to rauc-request
Hi team ,
I am new to rauc .Please solve my query
I have written system.conf file
{{{
abhishek@abhishek-Latitude-5490:~$ cat system.conf
[system]
compatible=eximius
bootloader=uboot
mountprefix=/mnt/rauc
statusfile=/factory/rauc.status
[keyring]
path=cert.pem
[...]
[slot.appdata.0]
#device=/dev/mmcblk1p8
device=/dev/disk/by-path/platform-219c000.usdhc-part8
type=ext4
parent=rootfs.0
[slot.appdata.1]
#device=/dev/mmcblk1p9
device=/dev/disk/by-path/platform-219c000.usdhc-part9
type=ext4
parent=rootfs.1
}}}
how to use hook in order to preserve the data of appdata0, while installing
bundle .
In which file i have to give hook option?
Hooks are part of the bundle, thus you have to define them in the bundle's
manifest, e.g.:
[hooks]
filename=yourhookscript.sh
[image.appdata]
image=foo.img
hooks=install
Note that your bundle generation has to place yourhookscript.sh into the bundle
in order to make this work.
Potentially, you could also do this in a post-install hook for your appfs in
case you know where your appdata copies are located.
Best regards,
Enrico
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be
conveyed only to the designated recipient(s). Any use, dissemination,
distribution, printing, retaining or copying of this e-mail (including its
attachments) by unintended recipient(s) is strictly prohibited and may
be unlawful.
Not sure if I will get in prison when replying on this mail on a
world-accessible mailing list... ;)
--
Pengutronix e.K. | Enrico Jörns|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
RAUC mailing list
Re: [RAUC] Regarding usage of hook
Hi Abhishek, On 9/26/18 5:30 PM, Abhishek Kumar Rai wrote: Hi Enrico, Thanks for your prompt reply. In my design , I have to do following things. - Create a RAUC bundle consisting of App images and dbs -> ProductControl.bin, Controls.bin, Operations.bin, ProductControl.db, Controls.db, Operations.db etc. ->*Bundle.raucb* - On installation, both the images and db should go into AppFS. DataFS should remain unaffected. -“Post Install Hook” in RAUC shall be used to copy configuration data from the current slot of DataFS to the newly installed slot. Can we achieve above scenario(with system.conf in previous mail) using “Post Install Hook” in manifest file. ? note that ATM, there is only a per-slot post-install hook. But, we have a post per-installation post-install *handler*. This means, the hook will be executed right after, e.g., your App image is copied and could be used to also write additional files you have in the bundle to the same slot (despite I would assume to have .db files in the datafs instead of appfs). For copying DataFS content, you might want to join the discussion we have here: https://github.com/rauc/rauc/issues/333 Maybe the discussion in https://github.com/rauc/rauc/issues/325 is also something that might be useful for your purposes. Best regards, Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
Re: [RAUC] Query regarding rauc
Hi Abhishek, On 12/4/18 12:12 PM, Abhishek Kumar Rai wrote: Hi Team, To achieve a specific requirement for us the "rauc install" command won't work i.e due to a configuration that we have the rauc install would fail. Though we would still like to go ahead and flashload to that partition. We would like to know if the approach below is correct Our understanding of rauc install suggests that it does the following things: 1. Verify signature of the bundle 2. Run partition selection algorithm 3. Extract the tar balls from the bundle 4. Create new ext4 FS on the selected partition 5. Write appropriate tar ball to the partition Since "rauc install" would give us errors due to our configuration we plan to achieve this using the steps below: 1. Verify signature of the bundle (rauc info ...) 2. Partition selection algorithm (we would like to skip this) 3. Extract the tar balls from the bundle (rauc extract ..) 4. Create new ext4 FS on the selected partition + Write appropriate tar ball to the partition (rauc write-slot ... ) how do you trigger the custom installation? Do you use the full-custom RAUC install handler? Extracting the tar's should not be required in all cases. With the full-custom handler you will already have it mounted, otherwise you can simply mount the bundle after verification as it is basically a squashfs. For rauc write-slot you also rely on parts of the system.conf, but not in the fixed scheme. If that is where your issue resides, you should be fine with that. Could you give me a hint what forces you to do this kind of manual handling? Maybe then we can think about a possible solution more targeted. But basically it should work as described above, yes. One thing will miss, depending on what you actually try to do. The key for atomic updates is to deactivate the bootable slot you write your image to before writing and set it as primary after successful writing. You can achieve this behavior with rauc status mark-bad [ perform update ] rauc status mark-active Best regards, Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
Re: [RAUC] Query regarding rauc
Hi Abhishek, On 12/4/18 1:06 PM, Abhishek Kumar Rai wrote: Hi Enrico, Thanks for the prompt response! Please find our responses inline (blue colored) you're lucky that I've a graphical mailer... ;) Better use standard mail quoting. Our understanding of rauc install suggests that it does the following things: 1. Verify signature of the bundle 2. Run partition selection algorithm 3. Extract the tar balls from the bundle 4. Create new ext4 FS on the selected partition 5. Write appropriate tar ball to the partition Since "rauc install" would give us errors due to our configuration we plan to achieve this using the steps below: 1. Verify signature of the bundle (rauc info ...) 2. Partition selection algorithm (we would like to skip this) 3. Extract the tar balls from the bundle (rauc extract ..) 4. Create new ext4 FS on the selected partition + Write appropriate tar ball to the partition (rauc write-slot ... ) how do you trigger the custom installation? Do you use the full-custom RAUC install handler? No for now we have replaced the "rauc install" call with the calls to the commands "rauc info + rauc extract + rauc write-slot". We were thinking that we might not get control due to slot selection algorithm. But we will explore this further starting today. Get a feeling it would be what we want. Though we read in the documentation that the pre/post install hooks would not work with full custom install. We might need them. Not too sure though. We might be able to merge the "post-install" hook work with the "install" hook You want to have a look at this sections: https://rauc.readthedocs.io/en/latest/using.html#full-custom-update Extracting the tar's should not be required in all cases. With the full-custom handler you will already have it mounted, otherwise you can simply mount the bundle after verification as it is basically a squashfs. Sure.. For rauc write-slot you also rely on parts of the system.conf, but not in the fixed scheme. If that is where your issue resides, you should be fine with that. Sure. We were also considering referring to the manifest file when the bundle gets mounted Could you give me a hint what forces you to do this kind of manual handling? Maybe then we can think about a possible solution more targeted. * For now, we have 4 partitions containing rfs.0, rfs.1, appfs.0 and appfs.1. We would like to have a scheme where only the partition that has been flashed with bundle data is changed i.e lets say currently we are using rfs.0 and appfs.0. Now if we flash a bundle containing appfs, on next reboot, system should use rfs.0 and appfs.*1*. Similarly for rfs. * To achieve this we started without a parent child relationship in system.conf. So when we are executing from appfs.0 and rfs.0 and we try to flash a bundle containing appfs, it would try to write to appfs.0 which would already be in use and hence we would get errors. So we introduced the parent child relationship * Now _with_ parent child relationship the issue above would be resolved. Now when we boot from "rfs.0" and execute apps from "appfs.0" and flash a appfs bundle it would write to appfs.1. On reboot, as per our scheme we would boot from "rfs.0" and execute apps from "appfs.1". Now when we try to do a rauc install it would write to "appfs.1" as it would consider appfs.0 as active partition due to parent-child relationship. * Hence as we were running into all these issues we felt that it would help our cause if we had our own slot selection logic. Hence the deviation to rauc info + rauc extract + rauc write-slot. Ok, I think I got your base motivation. What do you do to assure that the right appfs is used? Is that mechanism atomic? I.e. when you are interrupted between update of appfs, does it still boot the valid one? In general, as you might have read, our strict design case and recommendation is that you only install well-tested sets of all pieces of software. If you use it as an 'app store' maybe that is note a task for RAUC? But, what speaks against having both rootfs and appfs updated together? Is that installation time / bundle size? Note that RAUC will skip the actual update of the rootfs anyway if the slot's hash matches the hash of the image to install. Thus if you do not change the rootfs content across multiple instalations, it will skip the rootfs writing, anyway. Another concept to thinks about is (if you insist on updating the appfs separately), if you do not move the switching point entirely to be in the rootfs. Then RAUC would incorporate with the appfs-selection logic you currently use. Might need some extension for using custom boot selection scripts, but this is on our list anyway. The open question would be if you also intend to update your rootfs and if it is ok to never update the appfs and rootfs together, as this would not work with my approach. Regards, Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions
Re: [RAUC] Porting RAUC to OpenWRT
Hi Andreas, On 12/6/18 2:45 PM, Andreas Kurzkurt wrote: Hello We are trying to port the RAUC client to our OpenWRT system. But we are facing many problems at this moment. Our OpenWRT Version is „DESIGNATED DRIVER (Bleeding Edge, 12009)“. Does anybody have experience in porting RAUC to another Linux distribution and can help us. The RAUC client depends on many different libraries that we do not have in our system. RAUC should be relatively distribution-independent. Which libraries does it depend on that you do not have available? It mainly needs glib as base library and openssl for all (mandatory) crypto stuff. For (optional) network handling it also needs libcurl. But I wouldn't call that 'many different libraries'... ;) Best Regards, Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
Re: [RAUC] Query regarding rauc
Hi Abhishek, On 12/6/18 10:24 AM, Abhishek Kumar Rai wrote: Hi Team, Please provide your valuable suggestion regarding the above query . please do not put too much pressure on community mailing lists. There are business support channels available for this. > > Extracting the tar's should not be required in all cases. With the > > full-custom handler you will already have it mounted, otherwise you > > can simply mount the bundle after verification as it is basically a > > squashfs. Sure.. > > > > For rauc write-slot you also rely on parts of the system.conf, but > > not in the fixed scheme. If that is where your issue resides, you > > should be fine with that. Sure. We were also considering referring to > > the manifest file when the bundle gets mounted > > > > Could you give me a hint what forces you to do this kind of manual > > handling? Maybe then we can think about a possible solution more > > targeted. > > > > * For now, we have 4 partitions containing rfs.0, rfs.1, appfs.0 and > > appfs.1. We would like to have a scheme where only the partition that > > has been flashed with bundle data is changed i.e lets say currently > > we are using rfs.0 and appfs.0. Now if we flash a bundle containing > > appfs, on next reboot, system should use rfs.0 and appfs.*1*. > > Similarly for rfs. > > > > * To achieve this we started without a parent child relationship in > > system.conf. So when we are executing from appfs.0 and rfs.0 and we > > try to flash a bundle containing appfs, it would try to write to > > appfs.0 which would already be in use and hence we would get errors. > > So we introduced the parent child relationship > > > > * Now _with_ parent child relationship the issue above would be > > resolved. Now when we boot from "rfs.0" and execute apps from > > "appfs.0" and flash a appfs bundle it would write to appfs.1. On > > reboot, as per our scheme we would boot from "rfs.0" and execute apps > > from "appfs.1". Now when we try to do a rauc install it would write > > to "appfs.1" as it would consider appfs.0 as active partition due to > > parent-child relationship. > > > > * Hence as we were running into all these issues we felt that it > > would help our cause if we had our own slot selection logic. Hence > > the deviation to rauc info + rauc extract + rauc write-slot. > > Ok, I think I got your base motivation. > > What do you do to assure that the right appfs is used? > Is that mechanism atomic? I.e. when you are interrupted between update > of appfs, does it still boot the valid one? > We have yet not reached a stage where we would start releasing out the app bundles. Probably we would do it in a month or two. Yes if we are interrupted between update of appfs we would not switch to using the target partition and continue using the same appfs partition Where do you store the information about the active partition? As you cannot place it in the rootfs... > In general, as you might have read, our strict design case and > recommendation is that you only install well-tested sets of all pieces > of software. If you use it as an 'app store' maybe that is note a task > for RAUC? > Ohh. But we are able to achieve the appfs upgrades by mending rauc a little bit. Isnt that ok? Would you be able to provide more details as to why it might not be a good idea to use rauc for app-only upgrades? It's not mainly about using RAUC, it's mainly about how to setup a reliable system and a reliable redundancy boot! Basically, we have 2 options: 1) Using the application together with the rootfs it was tested for (highly recommended)! For this you need to assure that rootfs and appfs contain the exact same state that you used for testing and the default behavior for RAUC is valid. 2) Using the application on any rootfs (NOT recommended) This is what you probably do on consumer systems such as Android but what is really not recommended if you want to deliver a system that is proven to work. This would help us better design our update scheme. The core idea behind all the experiments is we wish to maintain symmetry and across reboots change only the partition that has been updated. So thats how the idea of having a rfs.0 + appfs.1 combination in place of rfs.1 + appfs.1 comes into the picture. For now, we have 3 use-cases (that might increase) - rfs only updates - appfs only updates - rfs + appfs updates Note that if these are all special cases, you also have to test all these special cases and the more they become the more your testing vector and thus effort will grow! RAUC is also explicitly not designed to handle these 3 cases differently. You could have appfs and rootfs as two
Re: [RAUC] Regarding using --conf option while using rauc
Hi Abhishek,
On 11/20/18 11:15 AM, Abhishek Kumar Rai wrote:
Hi Team,
I want to use my_system.conf for my customized system.conf setting while
installing rauc bundle
{{{
root:~# cat /etc/rauc/system.conf
[system]
compatible=Eximius
bootloader=uboot
mountprefix=/mnt/rauc
statusfile=/factory/rauc.status
[handlers]
pre-install=/usr/bin/rauc-pre-install.sh
post-install=/usr/bin/rauc-post-install.sh
[keyring]
path=cert.pem
[slot.rootfs.0]
device=/dev/disk/by-path/platform-219c000.usdhc-part1
type=ext4
bootname=A
}}}
{{{
root:~# cat my_system.conf
[system]
compatible=Eximius
bootloader=uboot
mountprefix=/mnt/rauc
statusfile=/factory/rauc.status
[handlers]
pre-install=/usr/bin/rauc-pre-install.sh
post-install=/usr/bin/rauc-post-install.sh
[keyring]
path=cert.pem
[slot.rootfs.0]
device=/dev/disk/by-path/platform-219c000.usdhc-part1
type=ext4
bootname=A
[slot.rootfs.1]
device=/dev/disk/by-path/platform-219c000.usdhc-part2
type=ext4
bootname=B
}}}
The bundle present in below command(rauc_bundle.raucb) consist of rootfs.
$ rauc install --conf=my_system.conf rauc_bundle.raucb
Can i use the above command to do that. if yes can i give partition information
also in my_system.conf .Or this is not possible .
Please provide your views regarding this.
The `rauc install` calls the CLI in client mode.
However, the config is read and evaluated by the service.
Thus a `rauc install --config` ist meaningless for the service that performs
the actual installation.
One exception is when compiling RAUC in non-service mode (without D-Bus).
What would work instead is stopping the rauc service and using
rauc service --config ..
when restarting.
Could you point out your use case for using 2 different system.conf's here?
I bet there is a valid solution using only one system.conf.
Best regards, Enrico
--
Pengutronix e.K. | Enrico Jörns|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
RAUC mailing list
Re: [RAUC] RAUC fails to mark slot as good --> fw_utils access error on mmc
Hi Steffen, On 4/24/19 4:17 PM, Steffen Kothe wrote: Hello mailinglist, Following error message occured after start of system. Log output comes from systemd (rauc.service) systemctl status rauc.service Apr 24 13:48:43 pixi-cdl100 rauc[478]: Write error on /dev/mmcblk3boot0: Operation not permitted > Apr 24 13:48:43 pixi-cdl100 rauc[478]: Error: can't write fw_env to flash > Apr 24 13:48:43 pixi-cdl100 rauc[478]: [[0;1;39mrauc mark: Failed marking 'rootfs.0' as good: Failed to run fw_setenv: Child process ex> ited with code 1[[0m > Apr 24 13:53:51 fw_utils have the correct setup, a manual call of fw_utils shows the correct environment of uboot. I fixed this problem with a script, starting before the rauc daemon, forcing the mmcblk3bootX devices to enable read/write. Why do I need to set the "force_ro" to 0, before rauc can access the u- boot environment? Why RAUC does not handle the "force_ro" after start? Attached the script, which is triggered before the rauc daemon. #!/bin/bash echo 0 > /sys/block/mmcblk3boot0/force_ro echo 0 $gt;> /sys/block/mmcblk3boot1/force_ro sorry for being a bit unresponsive, but I was only rarely in the office the last weeks. Did you resolve your issue? Is that intentionally that you have the environment in the eMMC boot partitions? Don't you loose the state after updating the bootloader? We had a similar question as issue on GitHub some time ago: https://github.com/rauc/rauc/issues/165 Best regards, Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
Re: [RAUC] Question about mounting application FS
Hi Patrick, On 7/11/19 9:42 AM, Patrick Schneider wrote: Hi there, we are currently using RAUC in A + B mode with rootFS and appFS in each slot. So far so good, integration worked and RAUC does its job in updating all the slots and communicating with barebox. Now we wondered what is best practice in mounting the right appFS for the corresponding rootFS? When rootFS0 boots the appFS0 has to be mounted and when rootFS1 boots we need appFS1. We couldn’t find a hint how to do that properly in the RAUC documentation. this can be done using proper udev rules for creating device aliases (symlinks) that are then used for mounting. How this is to be solved in detail depends a little on which storage type you are actually using and how you boot. Maybe you can add some more details here. We have a work-in-progress Pull-Request targeting a documentation update for this. It actually handles data partition mounting but the considerations are valid for an appfs, too. https://github.com/rauc/rauc/pull/370 Best regards, Enrico P.S: I've moderated your mail free, but please consider subscribing to the mailing list to ease sending / receiving messages to / from this list. -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
Re: [RAUC] Update a single file within rootfs
On 10/14/19 3:47 PM, Yazdani, Reyhaneh wrote: Hello everyone, The RAUC documentation describes: In RAUC, everything that can be updated is a slot. Thus a slot can either be a full device, a partition, a volume or simply a file. Now, I have two systems: system0 and system1, each of them defined as a partition on eMMC. I want to update a single file in my rootfs, for example the binary file of the application. How should I setup my system.conf and manifest? I could update the whole partition as an image, but just one file, I could not find any example about that. I would appreciate, if someone could help me. Just FTR: This was not forgotten. The actual discussion on this takes place in the opened GitHub Issue https://github.com/rauc/rauc/issues/497 Regards, Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ RAUC mailing list
Re: [RAUC] [PATCH] Add suport for bare flash
Hi ladis,
Mind if I play the GitHub bridge?
On 12/6/19 3:43 PM, Ladislav Michl wrote:
Add handler to write images using flashcp. Used to update barebox on at91
based board with dataflash.
Signed-off-by: Ladislav Michl
There we have all the checking and testing infrastructure. Patches via mailing
list are not officially supported as you know.
Or did you take the chance of creating an account already?
Regards, Enrico
---
src/update_handler.c | 72
1 file changed, 72 insertions(+)
diff --git a/src/update_handler.c b/src/update_handler.c
index 0415c92..8385096 100644
--- a/src/update_handler.c
+++ b/src/update_handler.c
@@ -497,6 +497,42 @@ out:
return res;
}
+static gboolean flash_write_slot(const gchar *image, const gchar *device, GError **error)
+{
+ g_autoptr(GSubprocess) sproc = NULL;
+ GError *ierror = NULL;
+ gboolean res = FALSE;
+ g_autoptr(GPtrArray) args = g_ptr_array_new_full(5, g_free);
+
+ g_ptr_array_add(args, g_strdup("flashcp"));
+ g_ptr_array_add(args, g_strdup(image));
+ g_ptr_array_add(args, g_strdup(device));
+ g_ptr_array_add(args, NULL);
+
+ r_debug_subprocess(args);
+ sproc = g_subprocess_newv((const gchar * const *)args->pdata,
+ G_SUBPROCESS_FLAGS_NONE, );
+ if (sproc == NULL) {
+ g_propagate_prefixed_error(
+ error,
+ ierror,
+ "failed to start flashcp: ");
+ goto out;
+ }
+
+ res = g_subprocess_wait_check(sproc, NULL, );
+ if (!res) {
+ g_propagate_prefixed_error(
+ error,
+ ierror,
+ "failed to run flashcp: ");
+ goto out;
+ }
+
+out:
+ return res;
+}
+
static gboolean nand_format_slot(const gchar *device, GError **error)
{
g_autoptr(GSubprocess) sproc = NULL;
@@ -1046,6 +1082,41 @@ out:
return res;
}
+static gboolean img_to_flash_handler(RaucImage *image, RaucSlot *dest_slot, const gchar *hook_name, GError **error)
+{
+ GError *ierror = NULL;
+ gboolean res = FALSE;
+
+ /* run slot pre install hook if enabled */
+ if (hook_name && image->hooks.pre_install) {
+ res = run_slot_hook(hook_name, R_SLOT_HOOK_PRE_INSTALL, NULL,
dest_slot, );
+ if (!res) {
+ g_propagate_error(error, ierror);
+ goto out;
+ }
+ }
+
+ /* write */
+ g_message("writing slot device %s", dest_slot->device);
+ res = flash_write_slot(image->filename, dest_slot->device, );
+ if (!res) {
+ g_propagate_error(error, ierror);
+ goto out;
+ }
+
+ /* run slot post install hook if enabled */
+ if (hook_name && image->hooks.post_install) {
+ res = run_slot_hook(hook_name, R_SLOT_HOOK_POST_INSTALL, NULL,
dest_slot, );
+ if (!res) {
+ g_propagate_error(error, ierror);
+ goto out;
+ }
+ }
+
+out:
+ return res;
+}
+
static gboolean img_to_nand_handler(RaucImage *image, RaucSlot *dest_slot,
const gchar *hook_name, GError **error)
{
GError *ierror = NULL;
@@ -1496,6 +1567,7 @@ RaucUpdatePair updatepairs[] = {
{"*.ubifs", "ubivol", img_to_ubivol_handler},
{"*.ubifs", "ubifs", img_to_ubifs_handler},
{"*.img", "ext4", img_to_fs_handler},
+ {"*.img", "flash", img_to_flash_handler},
{"*.img", "nand", img_to_nand_handler},
{"*.img", "ubifs", img_to_ubifs_handler},
{"*.img", "ubivol", img_to_ubivol_handler},
--
Pengutronix e.K.| Enrico Jörns|
Embedded Linux Consulting & Support | Teamleiter Integration |
Steuerwalder Str. 21| http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686| Fax: +49-5121-206917- |
___
RAUC mailing list
Re: [meta-rauc] Source of RAUC in build directory
On 9/18/19 11:02 AM, Ahmad Fatoum wrote: Hello Reyhaneh, On 9/18/19 10:25 AM, Yazdani, Reyhaneh wrote: Hello everyone, I am working to use RAUC in our system as updating framework. I am using meta-rauc layer in yocto and everything works correctly. The point is, now I want to do some changes in Rauc and I cannot find any source of it in my build directory! It is only the compiled files. Do you have RM_WORK enabled by chance? That would clean up the directory when it's no longer needed. There's also a devtool program that comes with bitbake that's quite useful for such things. Oh, you were faster than me :D Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ meta-rauc mailing list
Re: [meta-rauc] Source of RAUC in build directory
Hi Reyhaneh, On 9/18/19 10:25 AM, Yazdani, Reyhaneh wrote: Hello everyone, I am working to use RAUC in our system as updating framework. I am using meta-rauc layer in yocto and everything works correctly. The point is, now I want to do some changes in Rauc and I cannot find any source of it in my build directory! It is only the compiled files. It is strange, although in all RAUC-recipes, SRC_URI is set to the github, it means I should see the downloaded source in my build directory. does anyone have an idea? How can I apply my patch to the RAUC? by default you should find the source in the work directory which is something like tmp/work//rauc/1.1-r0/rauc-1.1/ However, the sources won't be present if you build with having rm_work[1] enabled. The simplest way to modify rauc out of Yocto is to use the 'devtool' [2] devtool modify rauc which will create a 'workspace' layer and unpack the sources, etc. there. You can also automatically create patches from this or deploy the updated tool to the target via ssh. Best regards Enrico Note: To receive updates from this mailing list and to send mails without ending up in the moderation queue, consider subscribing [3] to it. [1] https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-classes-rm-work [2] https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-devtool-reference [3] mailto:rauc-requ...@pengutronix.de?subject=subscribe -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ meta-rauc mailing list
