Re: [RAUC] RAUC Support for Nvidia Jetson Family

[Leon Anavi]

Hi Ziad,

I have added a RAUC integration for NVIDIA Jetson TX2 in layer 
meta-rauc-community/meta-rauc-tegra:


https://github.com/rauc/meta-rauc-community/tree/master/meta-rauc-tegra


Best regards,
Leon


On 5.05.22 г. 11:30 ч., Ziad Hussein wrote:

Dear Pengutronix Team,

I would like to ask if you have plans in the near future to extend 
RAUC to support Nvidia products, so that one can use RAUC to update 
remotely or locally for example a Jetson board (Nvidia AGX Xavier, 
TX2, ...) using RAUC tool.


Best Regards,
Ziad


--
Leon Anavi
Software Engineer
konsulko.com

[RAUC] RAUC Support for Nvidia Jetson Family

[Ziad Hussein]

Dear Pengutronix Team,

I would like to ask if you have plans in the near future to extend RAUC to 
support Nvidia products, so that one can use RAUC to update remotely or locally 
for example a Jetson board (Nvidia AGX Xavier, TX2, ...) using RAUC tool.

Best Regards,
Ziad

Re: [RAUC] RAUC update systems with release keys

[Yazdani, Reyhaneh]

> On Mon, 2022-03-14 at 09:40 +, Yazdani, Reyhaneh wrote:
> > Hi Jan,
> >
> > Thanks for quick response.
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Jan Lübbe 
> > > Gesendet: Montag, 14. März 2022 09:39
> > > An: Yazdani, Reyhaneh ;
> rauc@pengutronix.de
> > > Betreff: Re: [RAUC] RAUC update systems with release keys
> > >
> > > Hi Reyhaneh,
> > >
> > > On Mon, 2022-03-14 at 08:08 +, Yazdani, Reyhaneh wrote:
> > > > Hello,
> > > >
> > > > Currently we have some devices which are programmed with
> > > > development keys in the past.
> > > > Now, we need to use them as final devices with bundle signed with
> > > > release keys.
> > > > I copied cert file manually to the certificate path in rootfs and
> > > > try to use rauc install command to program the device with
> > > > release-bundle,
> > > but it fails.
> > >
> > > Just to avoid misunderstandings: You replaced your
> > > /etc/rauc/keyring.pem (or another keyring path as configured in your
> > > system.com) with the release keyring?
> >
> > [Reyhaneh] Yes, I replaced the old /etc/rauc/rauc.cert.pem (which the path
> is defined in system.conf) with the new one.
> > >
> > > Did you restart the rauc service?
> > [Reyhaneh] Yes. I ran systemctl restart rauc
> 
> Good. Which error output do you see from the rauc service in the journal?

[Reyhaneh] I found the issue. The time on the device was pretty older than the 
date of the machine I signed the bundle.
> 
> > > > What would be the correct procedure to bring development-devices
> > > > into
> > > > final- devices?
> > >
> > > Your approach should work in general, but there are others.
> > >
> > > You could also have the release CA certificate as a second cert in
> > > the development image keyring. In that case, you should be careful
> > > with migrations, though, as you probably want to avoid unexpected
> > > leftovers from development software.
> 
> > If I want to do resign the bundle instead of bitbaking to have new
> > bundle with release key, then I should use "rauc resign" command. Yes? Is
> the below command correct?
> >
> > rauc resign --cert=new-cert --key=new-key --keyring=old-keyring
> > input-bundle output-bundle
> 
> You could add --signing-keyring=new-keyring let RAUC check that the
> resulting signature can be verified with the new keyring.
> 
> Also, please note that when you use 'rauc resign', you need to select the
> correct keyring file in a hook. (otherwise you're probably installing just the
> development keyring). There is an example in https://imsva91-
> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2frauc.re
> adthedocs.io%2fen%2flatest%2fadvanced.html%23switching%2dthe%2dkeyri
> ng%2dspki%2dhashes=07C22091-DA2B-1A05-8189-
> 56774350CEC9=162296ff492f363ddb29ca454338bb84627996db-
> ac0e575946bd47fec19217e57318402469ade90c

[Reyhaneh] Thanks for the hint.

Best regards,
Reyhaneh
> 
> Regards,
> Jan
> --
> Pengutronix e.K.   | |
> Steuerwalder Str. 21   | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
RAUC mailing list

Re: [RAUC] RAUC update systems with release keys

[Jan Lübbe]

On Mon, 2022-03-14 at 09:40 +, Yazdani, Reyhaneh wrote:
> Hi Jan,
> 
> Thanks for quick response.
> 
> > -Ursprüngliche Nachricht-
> > Von: Jan Lübbe 
> > Gesendet: Montag, 14. März 2022 09:39
> > An: Yazdani, Reyhaneh ; rauc@pengutronix.de
> > Betreff: Re: [RAUC] RAUC update systems with release keys
> > 
> > Hi Reyhaneh,
> > 
> > On Mon, 2022-03-14 at 08:08 +, Yazdani, Reyhaneh wrote:
> > > Hello,
> > > 
> > > Currently we have some devices which are programmed with development
> > > keys in the past.
> > > Now, we need to use them as final devices with bundle signed with
> > > release keys.
> > > I copied cert file manually to the certificate path in rootfs and try
> > > to use rauc install command to program the device with release-bundle,
> > but it fails.
> > 
> > Just to avoid misunderstandings: You replaced your /etc/rauc/keyring.pem
> > (or another keyring path as configured in your system.com) with the release
> > keyring?
> 
> [Reyhaneh] Yes, I replaced the old /etc/rauc/rauc.cert.pem (which the path is 
> defined in system.conf) with the new one.
> > 
> > Did you restart the rauc service?
> [Reyhaneh] Yes. I ran systemctl restart rauc

Good. Which error output do you see from the rauc service in the journal?

> > > What would be the correct procedure to bring development-devices into
> > > final- devices?
> > 
> > Your approach should work in general, but there are others.
> > 
> > You could also have the release CA certificate as a second cert in the
> > development image keyring. In that case, you should be careful with
> > migrations, though, as you probably want to avoid unexpected leftovers
> > from development software.

> If I want to do resign the bundle instead of bitbaking to have new bundle 
> with release key, then I should use 
> "rauc resign" command. Yes? Is the below command correct?
> 
> rauc resign --cert=new-cert --key=new-key --keyring=old-keyring input-bundle 
> output-bundle

You could add --signing-keyring=new-keyring let RAUC check that the resulting
signature can be verified with the new keyring.

Also, please note that when you use 'rauc resign', you need to select the
correct keyring file in a hook. (otherwise you're probably installing just the
development keyring). There is an example in
https://rauc.readthedocs.io/en/latest/advanced.html#switching-the-keyring-spki-hashes

Regards,
Jan
-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
RAUC mailing list

Re: [RAUC] RAUC update systems with release keys

[Yazdani, Reyhaneh]

Hi Jan,

Thanks for quick response.

> -Ursprüngliche Nachricht-
> Von: Jan Lübbe 
> Gesendet: Montag, 14. März 2022 09:39
> An: Yazdani, Reyhaneh ; rauc@pengutronix.de
> Betreff: Re: [RAUC] RAUC update systems with release keys
> 
> Hi Reyhaneh,
> 
> On Mon, 2022-03-14 at 08:08 +, Yazdani, Reyhaneh wrote:
> > Hello,
> >
> > Currently we have some devices which are programmed with development
> > keys in the past.
> > Now, we need to use them as final devices with bundle signed with
> > release keys.
> > I copied cert file manually to the certificate path in rootfs and try
> > to use rauc install command to program the device with release-bundle,
> but it fails.
> 
> Just to avoid misunderstandings: You replaced your /etc/rauc/keyring.pem
> (or another keyring path as configured in your system.com) with the release
> keyring?

[Reyhaneh] Yes, I replaced the old /etc/rauc/rauc.cert.pem (which the path is 
defined in system.conf) with the new one.
> 
> Did you restart the rauc service?
[Reyhaneh] Yes. I ran systemctl restart rauc
> 
> > What would be the correct procedure to bring development-devices into
> > final- devices?
> 
> Your approach should work in general, but there are others.
> 
> You could also have the release CA certificate as a second cert in the
> development image keyring. In that case, you should be careful with
> migrations, though, as you probably want to avoid unexpected leftovers
> from development software.
If I want to do resign the bundle instead of bitbaking to have new bundle with 
release key, then I should use 
"rauc resign" command. Yes? Is the below command correct?

rauc resign --cert=new-cert --key=new-key --keyring=old-keyring input-bundle 
output-bundle

Best regards,
Reyhaneh

> 
> Regards,
> Jan
> --
> Pengutronix e.K.   | |
> Steuerwalder Str. 21   | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
RAUC mailing list

Re: [RAUC] RAUC update systems with release keys

[Jan Lübbe]

Hi Reyhaneh,

On Mon, 2022-03-14 at 08:08 +, Yazdani, Reyhaneh wrote:
> Hello,
>  
> Currently we have some devices which are programmed with development keys in
> the past.
> Now, we need to use them as final devices with bundle signed with release
> keys. 
> I copied cert file manually to the certificate path in rootfs and try to use
> rauc install command to program the device with release-bundle, but it fails.

Just to avoid misunderstandings: You replaced your /etc/rauc/keyring.pem (or
another keyring path as configured in your system.com) with the release keyring?

Did you restart the rauc service?

> What would be the correct procedure to bring development-devices into final-
> devices?

Your approach should work in general, but there are others.

You could also have the release CA certificate as a second cert in the
development image keyring. In that case, you should be careful with migrations,
though, as you probably want to avoid unexpected leftovers from development
software.

Regards,
Jan
-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
RAUC mailing list

[RAUC] RAUC update systems with release keys

[Yazdani, Reyhaneh]

Hello,

Currently we have some devices which are programmed with development keys in 
the past.
Now, we need to use them as final devices with bundle signed with release keys.
I copied cert file manually to the certificate path in rootfs and try to use 
rauc install command to program
the device with release-bundle, but it fails.

What would be the correct procedure  to bring development-devices into 
final-devices?

Best regards,
Reyhaneh

___
RAUC mailing list

Re: [RAUC] RAUC Install issue with disk partitioning

[Charles Steinkuehler]

On 3/10/2022 4:50 PM, Charles Steinkuehler wrote:


When I attempt to update the bootfs, I get the following.  The exact 
same commands worked before I changed the partition layout (adding the 
rescue & upload partitions, forcing the use of an extended partition 
table):


I verified if there are no unused primary partitions, RAUC will happily 
update the boot partition:


https://github.com/cdsteinkuehler/br2rauc/commit/7cee82983653e3645810a204ecdd0bf54ffda722

--
Charles Steinkuehler
char...@steinkuehler.net

___
RAUC mailing list

[RAUC] RAUC Install issue with disk partitioning

[Charles Steinkuehler]

I am working through my Buildroot + RAUC example project[1] and after 
modifying the HDD partitioning I can no longer install updates to the 
boot partition however updates to the rootfs partition still work.


My boot filesystem is using boot-mbr-switch and it seems to be getting 
confused by the fact that I have extended partitions but no primary 
partition #4.  The partition layout is:


P1 = Boot loader (with space reserved for boot-mbr-switch)
P2 = Rescue partition
P3 = Extended partition
P4 = 
E5 = Rootfs.0
E6 = Rootfs.1
E7 = Uploads (bulk data, unsafe across reboots)
E8 = Persistent data (fully journaled, safe)

When I attempt to update the bootfs, I get the following.  The exact 
same commands worked before I changed the partition layout (adding the 
rescue & upload partitions, forcing the use of an extended partition table):



$ rauc install /mnt/bootfs.raucb
installing
  0% Installing
  0% Determining slot states
 20% Determining slot states done.
 20% Checking bundle
 20% Verifying signature
 40% Verifying signature done.
 40% Checking bundle done.
 40% Checking manifest contents
 60% Checking manifest contents done.
 60% Determining target install group
 80% Determining target install group done.
 80% Updating slots
 80% Checking slot bootloader.0
 90% Checking slot bootloader.0 done.
 90% Copying image to bootloader.0
100% Copying image to bootloader.0 failed.
100% Updating slots failed.
100% Installing failed.
LastError: Installation error: Failed updating slot bootloader.0: Region 
start address 0x40 is in area of partition 4 (0x0 - 0x)

Installing `/mnt/bootfs.raucb` failed
$
$ sudo fdisk -ul /dev/mmcblk0
Disk /dev/mmcblk0: 59 GB, 63864569856 bytes, 124735488 sectors
1948992 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device   Boot StartLBA EndLBASectors  Size Id Type
/dev/mmcblk0p1 *  8192 532479 524288  256M  c Win95 FAT32 (LBA)
/dev/mmcblk0p2 10567681581055 524288  256M 83 Linux
/dev/mmcblk0p3 158105673728035791748 2828M  f Win95 Ext'd (LBA)
/dev/mmcblk0p5 158105734242561843200  900M 83 Linux
/dev/mmcblk0p6 342425852674571843200  900M 83 Linux
/dev/mmcblk0p7 526745971106581843200  900M 83 Linux
/dev/mmcblk0p8 71106607372803 262144  128M 83 Linux


Any idea why rauc is complaining that an unused partition overlaps my 
boot partition?


I'll probably just shuffle things around and move the persistent data 
partition to P3 and let the extended partition table take P4, but this 
seems like it's a bug.


[1] https://github.com/cdsteinkuehler/br2rauc

--
Charles Steinkuehler
char...@steinkuehler.net

___
RAUC mailing list

[RAUC] RAUC dbus question

[Gary Huband]

I have RAUC integrated with a Yocto Morty build (Linux 4.14) running on an 
iMX7D (arm).  I'm trying to verify that the RAUC dbus interface is working, but 
I get an error when I use dbus-send:

# dbus-send --system --dest=de.pengutronix.rauc --type=method_call 
--print-reply /de/pengutronix/rauc de.pengutronix.rauc.GetSlotStatusError 
org.freedesktop.DBus.Error.UnknownMethod: No such interface 
'de.pengutronix.rauc' on object at path /de/pengutronix/rauc

When I try introspection:

# dbus-send --system --dest=de.pengutronix.rauc --type=method_call 
--print-reply /de/pengutronix/rauc 
org.freedesktop.DBus.Introspectable.Introspect
method return time=1605228956.729035 sender=:1.6 -> destination=:1.8 serial=8 
reply_serial=2
   string "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd;>



"

The RAUC service is on the system bus:

# dbus-send --system --dest=org.freedesktop.DBus --type=method_call 
--print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames
method return time=1605229469.748648 sender=org.freedesktop.DBus -> 
destination=:1.13 serial=3 reply_serial=2
   array [
  string "org.freedesktop.DBus"
  string "org.freedesktop.login1"
  string "org.freedesktop.systemd1"
  string "de.pengutronix.rauc"
  string "org.freedesktop.Avahi"
  string ":1.13"
  string ":1.0"
  string ":1.1"
  string "org.freedesktop.network1"
  string ":1.2"
  string ":1.3"
  string "org.freedesktop.resolve1"
  string ":1.4"
  string ":1.6"
   ]

Any help with what I am doing wrong is appreciated.

Gary


Gary Huband
Sr. Software and Systems Engineer

Office: 434.284.8071 x720
Direct: 434.260.4995
g...@missionsecure.com

Follow Us!
LinkedIn  |  
Blog
  |  
Website

: : : : : : : : : : : : : : : : : : : : : : : : : : :

[MSi]

This email and any files transmitted with it are confidential and proprietary 
and intended solely for the use of the individual or entity to whom they are 
addressed. Any dissemination, distribution or copying of this communication is 
strictly prohibited without our prior permission. If you received this in 
error, please contact the sender and delete the material from any computer.

___
RAUC mailing list

Re: [RAUC] RAUC dbus question

[Enrico Jörns]

Hi Gary,

Am Montag, dem 15.02.2021 um 23:13 + schrieb Gary Huband:
> I have RAUC integrated with a Yocto Morty build (Linux 4.14) running on an
> iMX7D (arm).  I'm trying to verify that the RAUC dbus interface is working,
> but I get an error when I use dbus-send:

do you do recent development on morty? This *very* old now. Don't you have to
option to switch to a recent release?

> # dbus-send --system --dest=de.pengutronix.rauc --type=method_call --print-
> reply /de/pengutronix/rauc de.pengutronix.rauc.GetSlotStatusError
> org.freedesktop.DBus.Error.UnknownMethod: No such interface
> 'de.pengutronix.rauc' on object at path /de/pengutronix/rauc

The proper call would be:

   dbus-send --system --dest=de.pengutronix.rauc --type=method_call --print-
reply / de.pengutronix.rauc.Installer.GetSlotStatus

So, the issue is that the object path in RAUC is only "/", which is possible but
actually not the convention for D-Bus interfaces and does not allow versioned
interfaces, etc.

In the documentation we have some examples using the D-Bus API with
'busctl': https://rauc.readthedocs.io/en/latest/using.html#using-the-d-bus-api


Hope that helps?

Best regards

Enrico

> When I try introspection:
> 
> # dbus-send --system --dest=de.pengutronix.rauc --type=method_call --print-
> reply /de/pengutronix/rauc org.freedesktop.DBus.Introspectable.Introspect
> method return time=1605228956.729035 sender=:1.6 -> destination=:1.8 serial=8
> reply_serial=2
>    string " Introspection 1.0//EN"
>                      
> "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd;>
> 
> 
> 
> "
> 
> The RAUC service is on the system bus:
> 
> # dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-
> reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames
> method return time=1605229469.748648 sender=org.freedesktop.DBus ->
> destination=:1.13 serial=3 reply_serial=2
>    array [
>       string "org.freedesktop.DBus"
>       string "org.freedesktop.login1"
>       string "org.freedesktop.systemd1"
>       string "de.pengutronix.rauc"
>       string "org.freedesktop.Avahi"
>       string ":1.13"
>       string ":1.0"
>       string ":1.1"
>       string "org.freedesktop.network1"
>       string ":1.2"
>       string ":1.3"
>       string "org.freedesktop.resolve1"
>       string ":1.4"
>       string ":1.6"
>    ]
> 
> Any help with what I am doing wrong is appreciated.
> 
> Gary
> 
> 
> Gary Huband
> Sr. Software and Systems Engineer
> 
> Office: 434.284.8071 x720 
> Direct: 434.260.4995 
> g...@missionsecure.com
> 
> Follow Us!
> LinkedIn  |  Blog  |  Website
> 
> : : : : : : : : : : : : : : : : : : : : : : : : : : : 
> 
> MSi
> 
> This email and any files transmitted with it are confidential and proprietary
> and intended solely for the use of the individual or entity to whom they are
> addressed. Any dissemination, distribution or copying of this communication is
> strictly prohibited without our prior permission. If you received this in
> error, please contact the sender and delete the material from any computer.
> 
> ___
> RAUC mailing list

-- 
Pengutronix e.K.   | Enrico Jörns|
Embedded Linux Consulting & Support| https://www.pengutronix.de/ |
Steuerwalder Str. 21   | Phone: +49-5121-206917-180  |
31137 Hildesheim, Germany  | Fax:   +49-5121-206917-9|
___
RAUC mailing list

Re: [meta-rauc] Rauc 1.4 with Yocto Zeus

[Martin Hollingsworth]

Hello Enrico,
thanks for your evaluation.

> Updating to RAUC 1.4 should be possible without any issues. There were
> no major changes that would affect compatibility. Simply copy the RAUC
> recipes from current master as there were some recipe-internal reworks
> that you should take with.

Motivated by the infos in LAYERSERIES_COMPAT_rauc  I have integrated branch 
Dunfell into my Zeus project and it works fine. Just FYI for who might stumple 
upon this.

Regards,
Martin Hollingsworth
___
meta-rauc mailing list

Re: [meta-rauc] Rauc 1.4 with Yocto Zeus

[Enrico Jörns]

Hi Martin,

Am Dienstag, den 17.11.2020, 13:26 + schrieb Martin Hollingsworth:
> Hello community,
> I would like to use the latest RAUC release (v1.4) with my project, which is 
> stuck on Yocto Zeus 3.0.x.  However meta-rauc branch “zeus” integrates only 
> Rauc v1.2.

If this project is still in development I would encourage to move at
least to the dunfell LTS as zeus is already out of support.
 
> Has anyone tried to update to the latest RAUC version? Any pitfalls with Zeus?

Updating to RAUC 1.4 should be possible without any issues. There were
no major changes that would affect compatibility. Simply copy the RAUC
recipes from current master as there were some recipe-internal reworks
that you should take with.


Best regards

Enrico

> Thanks and regards,
> Martin Hollingsworth
> ___
> meta-rauc mailing list
-- 
Pengutronix e.K.   | Enrico Jörns|
Embedded Linux Consulting & Support| https://www.pengutronix.de/ |
Steuerwalder Str. 21   | Phone: +49-5121-206917-180  |
31137 Hildesheim, Germany  | Fax:   +49-5121-206917-9|


___
meta-rauc mailing list

[meta-rauc] Rauc 1.4 with Yocto Zeus

[Martin Hollingsworth]

Hello community,

I would like to use the latest RAUC release (v1.4) with my project, which is 
stuck on Yocto Zeus 3.0.x.  However meta-rauc branch "zeus" integrates only 
Rauc v1.2.



Has anyone tried to update to the latest RAUC version? Any pitfalls with Zeus?



Thanks and regards,

Martin Hollingsworth

___
meta-rauc mailing list

Re: [RAUC] RAUC install

[Matt Campbell]

I am able to follow those instructions on a Ubuntu 20.04 system with no
issues and build the rauc tools for native x86. Note that you will have to
install some deps (like toolchain and possibly some dev packages). Can you
provide output from the terminal where you are encountering issues? Without
that I'm afraid it's going to be very hard to help you debug this.

~MAtt

On Wed, Aug 5, 2020 at 7:36 AM Robert Schwebel 
wrote:

> Hello Imre,
>
> On Mon, Jul 27, 2020 at 07:31:20PM +0200, Imre Dobany wrote:
> > Hello RAUC colleagues,
> >
> > please support me with install RAUC
> > as it is written in 'README.rst'  below, but none of them work-->
> > git clone https://github.com/rauc/rauc
> > cd rauc
> > ./autogen.sh
> > ./configure
> > make
> >
> > or
> >  make install
>
> Are you sure you are sitting in front of a computer?
> Does it have internet?
>
> rsc
> --
> Pengutronix e.K.   | Dipl.-Ing. Robert Schwebel  |
> Steuerwalder Str. 21   | https://www.pengutronix.de/ |
> 31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917-9|
>
> ___
> RAUC mailing list
>


-- 
Matthew Campbell
Senior Embedded Systems Engineer
mcampb...@izotope.com

iZotope, Inc.
www.izotope.com
___
RAUC mailing list

Re: [RAUC] RAUC install

[Robert Schwebel]

Hello Imre,

On Mon, Jul 27, 2020 at 07:31:20PM +0200, Imre Dobany wrote:
> Hello RAUC colleagues,
> 
> please support me with install RAUC 
> as it is written in 'README.rst'  below, but none of them work--> 
>     git clone https://github.com/rauc/rauc
>     cd rauc
>     ./autogen.sh
>     ./configure
>     make
> 
> or 
>  make install

Are you sure you are sitting in front of a computer?
Does it have internet?

rsc
-- 
Pengutronix e.K.   | Dipl.-Ing. Robert Schwebel  |
Steuerwalder Str. 21   | https://www.pengutronix.de/ |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917-9|

___
RAUC mailing list

[RAUC] RAUC install

[Imre Dobany]

Hello RAUC colleagues,

please support me with install RAUC
as it is written in 'README.rst'  below, but none of them work-->
git clone https://github.com/rauc/rauc
cd rauc
./autogen.sh
./configure
make

or
 make install


Thanks,
Imre Dobany
___
RAUC mailing list

Re: [RAUC] RAUC with nanopi board

[Mikhail]

Finally I’ve managed to to make it work on both SD card and eMMC. I used Yocto 
with the latest mainline U-boot instead of Friendlyarm approach to build the 
image.
 
Thanks,
Mikhail
  
>Среда, 18 марта 2020, 21:01 +03:00 от Arti Zirk :
> 
>On N, 2020-03-12 at 15:53 +0300, Mikhail wrote:
>> The system (with Ubuntu 18) is installed on EMMC and it uses rockchip
>> u-boot as bootloader Have you looked into how Armbian has done support for 
>> this board?
>https://www.armbian.com/nanopi-neo4/
>  
 
 
--
. .
 ___
RAUC mailing list

Re: [RAUC] RAUC with nanopi board

[Mikhail]

Hi Arti,
 
Yes, this page contains instruction from FrienlyArm on how to create flashing 
sd-card to create the image on emmc:
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO4
I’ve read it and that’s actually how I flash emmc now. But I did not find a way 
to customize boot script to integrate RAUC.
 
Best regards,
Mikhail
  
>Среда, 18 марта 2020, 21:01 +03:00 от Arti Zirk :
> 
>On N, 2020-03-12 at 15:53 +0300, Mikhail wrote:
>> The system (with Ubuntu 18) is installed on EMMC and it uses rockchip
>> u-boot as bootloader Have you looked into how Armbian has done support for 
>> this board?
>https://www.armbian.com/nanopi-neo4/
>  
 
 
--
. .
 ___
RAUC mailing list

Re: [RAUC] RAUC with nanopi board

[Mikhail]

Hi,
Yes, I’ve seen the example script for boot selection. The problem is I don’t 
know where to integrate it. The image flashed on emmc has no boot partition 
which would usually be mounted at /boot and contain boot.scr script. Instead, 
bootloader, kernel image and other components are placed to separate raw 
partitions at the beginning of the emmc. Then go rootfs and data ext4 
partitions. Here is the layout:
 
flash=mmc,1:loader:idb:0x8000,0x28:idbloader.img;
flash=mmc,1:env:env:0x3F8000,0x8000;
flash=mmc,1:parm:parm:0x40,0x040:param4sd.txt;
flash=mmc,1:uboot:raw:0x80,0x040:uboot.img;
flash=mmc,1:trust:raw:0xC0,0x040:trust.img;
flash=mmc,1:misc:raw:0x100,0x040;
flash=mmc,1:resc:raw:0x140,0x0C0:resource.img;
flash=mmc,1:kern:raw:0x200,0x200:kernel.img;
flash=mmc,1:boot:raw:0x400,0x200:boot.img;
flash=mmc,1:rootfs:ext4:0x600,0x11780:rootfs.img;
flash=mmc,1:userdata:ext4:0x11D80,0x0:userdata.img;
 
Best regards,
Mikhail
  
>Среда, 18 марта 2020, 3:14 +03:00 от Enrico Jörns :
> 
>Hi Mikhail,
>
>Am 12.03.20 um 13:53 schrieb Mikhail:
>> Hi,
>>  
>> I need to implement a solution for rootfs/app update with nanopi neo4
>> board. The system (with Ubuntu 18) is installed on EMMC and it uses
>> rockchip u-boot as bootloader. This board seems to use special approach
>> for defining partitions: the command line defining mtd partitions is
>> hard-coded at specific block address on EMMC, and it also tells which
>> partition is the rootfs (e.g. "root=/dev/mmcblk1p7 … mtdparts=…"). Since
>> it looks hard-coded, I don’t know how to change rootfs partition by
>> using u-boot environment variables. So even though I’ve managed to setup
>> RAUC and successfully used it to update roofs in an inactive partition,
>> I can’t make my board switch to the new rootfs partition after reboot.
>>  
>> Since I’m new to the topic, maybe I’m missing something. I’d be grateful
>> for any advice.
>> Are there any success stories of using RAUC with nanopi boards
>> (especially Neo4)?
>an example script for implementing boot device selection with u-boot can
>be found here:
>
>https://github.com/rauc/rauc/blob/master/contrib/uboot.sh
>
>A more detailed guide on how to integrate this we have in the documentation:
>
>https://rauc.readthedocs.io/en/latest/integration.html#id4
>
>Does this help already?
>
>
>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 with nanopi board

[Arti Zirk]

On N, 2020-03-12 at 15:53 +0300, Mikhail wrote:
> The system (with Ubuntu 18) is installed on EMMC and it uses rockchip
> u-boot as bootloader
Have you looked into how Armbian has done support for this board? 
https://www.armbian.com/nanopi-neo4/


___
RAUC mailing list

Re: [RAUC] RAUC with nanopi board

[Enrico Jörns]

Hi Mikhail,

Am 12.03.20 um 13:53 schrieb Mikhail:
> Hi,
>  
> I need to implement a solution for rootfs/app update with nanopi neo4
> board. The system (with Ubuntu 18) is installed on EMMC and it uses
> rockchip u-boot as bootloader. This board seems to use special approach
> for defining partitions: the command line defining mtd partitions is
> hard-coded at specific block address on EMMC, and it also tells which
> partition is the rootfs (e.g. "root=/dev/mmcblk1p7 … mtdparts=…"). Since
> it looks hard-coded, I don’t know how to change rootfs partition by
> using u-boot environment variables. So even though I’ve managed to setup
> RAUC and successfully used it to update roofs in an inactive partition,
> I can’t make my board switch to the new rootfs partition after reboot.
>  
> Since I’m new to the topic, maybe I’m missing something. I’d be grateful
> for any advice.
> Are there any success stories of using RAUC with nanopi boards
> (especially Neo4)?

an example script for implementing boot device selection with u-boot can
be found here:

https://github.com/rauc/rauc/blob/master/contrib/uboot.sh

A more detailed guide on how to integrate this we have in the documentation:

https://rauc.readthedocs.io/en/latest/integration.html#id4

Does this help already?


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] RAUC with nanopi board

[Mikhail]

Hi,
 
I need to implement a solution for rootfs/app update with nanopi neo4 board. 
The system (with Ubuntu 18) is installed on EMMC and it uses rockchip u-boot as 
bootloader. This board seems to use special approach for defining partitions: 
the command line defining mtd partitions is hard-coded at specific block 
address on EMMC, and it also tells which partition is the rootfs (e.g. 
"root=/dev/mmcblk1p7 … mtdparts=…"). Since it looks hard-coded, I don’t know 
how to change rootfs partition by using u-boot environment variables. So even 
though I’ve managed to setup RAUC and successfully used it to update roofs in 
an inactive partition, I can’t make my board switch to the new rootfs partition 
after reboot.
 
Since I’m new to the topic, maybe I’m missing something. I’d be grateful for 
any advice.
Are there any success stories of using RAUC with nanopi boards (especially 
Neo4)?
 
Best regards,
Mikhail___
RAUC mailing list

Re: [RAUC] Rauc usage hints needed

[Mauro Condarelli]

Thanks Joerns,
I'm also very late answering, but I've been very busy (see below)

On 12/12/19 12:50 AM, Enrico Jörns wrote:
> Hi Mauro,
>
> sorry for being a bit late in answering. It turns out that the less of
> the year remains, the more is still to be done until it ends ;)
I know ;)

> Am 01.12.19 um 11:55 schrieb Mauro Condarelli:
>> Hi All,
>> I'm trying to decide if rauch is the right tool for my project.
> Please, says 'rauc' (or even better 'RAUC'). 'rauch' in german means
> 'smoke' and this should not be the connotation :D
Fully understood (I should have known, clumsy fingers...)


>> My target is an embedded Linux with:
>> - SPI Flash for booting (paleolithic version of U-Boot) and possibly a
>> initramfs/recovery (16M total)
First good news is I managed to port current (actually "next"!)
u-boot to my board and thus many of the limitations are lifted.


>> - A sizable SD card (8G).
>>
>> Bad problem is SD is very sensitive to "unexpected" shutdowns which I
>> cannot prevent.
>>
>> Slots should include:
>>
>> - uboot (possibly never updated)
>>   allocated in first Flash partition: /dev/mtd1
> Never say never, as bootloaders may fail updating more recent kernels
> depending on how much they interact with device tree loading etc.
Agreed.

- two very small (4k) partitions holding fallback U-Boot ENV and
  serialization data (serial#, MAC addr, ...).
>> - linux kernel (rarely upgraded, if ever)
>>   allocated in third Flash partition: /dev/mtd3
It will become /dev/mtd4.
This Linux kernel is for exclusive use of the recovery system,
in case SD card is completely unusable.

>> - recovery (possibly never updated)
>>   allocated in fourth Flash partition: /dev/mtd4
>>   probably a SquashFS, but could also be a initramfs (cpio)
>>   copies of rauc modules could be stored in first SD partition (vfat)
>> /dev/mmcblk1
> Note that because of security concerns, it might require being updated,
> too. But from the general concept of a recovery system, yes it should be
> rarely updated.
>
> What about saving one partition and using a kernel with built-in initramfs?
As said: recovery system should not be actually used (hopefully ;) )
I don't think to provide updates for that is a priority: if we touch it
we face chance to brick the system, quite the opposite of what a
recovery system is meant to be.

My system (mips MT7628) can see part (first 4MiB) of the SPI NOR
as memory and thus I'm "booting from RAM". InitramFS has limited
size while using SquashFS I can cram much more data in it.

>> - system (rarely upgraded)
>>   allocated in SD, redundant probably /dev/mmcblk0p2 and /dev/mmcblk0p3
>>   ext4
> Does that bring its own kernel or the one from /dev/mtd3?
> Updating the kernel is a definitive use case!
Of course!
Idea would be to have multiple copies of Kernel (along with some
backup copies of RootFS) in the first (FAT formatted) SD partition
(/dev/mmcblk0p1) easily accessible from both U-Boot and Linux.

I also moved U-Boot ENV to this partition so that "normal" (non
recovery) boot could have a completely different environment.
Recovery should mainly rely on "compiled-in" default ENV.
Moving to SD also benefits from Wear-Leveling, so I can update
ENV at each boot attempt to keep the boot-counter needed for
automatic fallback (I'm still unsure on how to implement this in
U-Boot; if there are "best practices" available...).

>> - application (often upgraded)
>>   allocated in SD, redundant probably /dev/mmcblk0p5 and /dev/mmcblk0p6
>>   ext4 mounted on /home
It could be quite small.


>> - accumulated data (initially empty; should be preserved at all cost)
>>   allocated in SD, not redundant, but possibly backed-up before upgrade.
>>   ext4 mounted on /srv
We could allocate a small partition just to store RAUC Update
Artifacts without any interference with "live" system. Would this
buy us some added robustness, in practice?

>> At first documentation perusal I saw no direct support for MTD.
> There were patches from ladis on this list recently that you might have
> seen if you're subscribed. Otherwise you could use a hook script first
> of all.
I just recently subscribed, I'll search the archives.

>> My current "solution" relies on a bunch of scripts that are rapidly growing
>> and a rather complex usage of OverlayFS.
>> I am thus looking for a "more structured" solution, possibly rauch.
> Yes, that is the exact reason why one wants to use an (open source)
> framework for these kind of things. And RAUC should be able to cover
> your use case of asymmetric A+recovery update. See minimal example:
>
> https://rauc.readthedocs.io/en/latest/scenarios.html#asymmetric-slots
I've seen that.
As I'm resuming work now on update system I will send my
tentative architecture (and RAUC Configuration Files) to
have an expert advise.

> The good on this is, that even if there is some small aspect still
> missing, it could be implemented and then be maintained in a shared and
> more well-tested environment than a custom script 

[RAUC] rauc with a remote signing service

[Daniel Ammann]

Hi all

From looking at the documentation and the source code, I get the impression
that signing the bundle using a remote service (crypto applicance) is not
possible.
Is this correct or did I overlook something?

Thanks and kind regards

Daniel

___
RAUC mailing list

Re: [meta-rauc] [RAUC] [Yocto] Rauc certificate expiration management advices

[Thorsten Scherer]

Hello Adrien,

On Wed, Aug 14, 2019 at 03:56:07PM +, Adrien Martin wrote:
> Hello,
> 
> My name is Adrien Martin, embedded system engineer at STIMIO and I am facing 
> an issue with rauc update security.
> Just to let you know, I don't have much experience with security concepts in 
> general.
> 
> I am using Rauc (v0.4, quite old I admit) for an embedded linux system 
> (imx6ul) with barebox bootloader, all images / bundles are generated via 
> Yocto (Poky)
> 
> Following the documentation, you need to set :
> 
>   *   RAUC_KEY_FILE = "path/to/key.pem" # What I call the private key
>   *   RAUC_CERT_FILE = "path/to/cert.pem" # What I call the certificate 
> (public key)
> 
> As a result, when generating your image and bundle, you get :
> 
>   *   A linux image with /etc/rauc/cert.pem integrated to your rootfs
>   *   A signed bundle with the key.pem
> 
> My problem is what happens when the certificate is expired ?
> 
> My initial though was, I just have to generate a new cert.pem, based on the 
> same private key.pem with a new valid lifetime period and set up this new 
> cert in the yocto recipe.
> Then, I generate the bundle via Yocto and try to install it.
> 
> This doesn't work and gives me :
> # rauc info /var/volatile/original/msdi-bundle-msdi-imx6-1.raucb
> rauc-Message: Reading bundle: 
> /var/volatile/original/msdi-bundle-msdi-imx6-1.raucb
> rauc-Message: Verifying bundle...
> signature verification failed: Verify error:self signed certificate
> 
> It looks like a bundle can only be use with the cert file set in the yocto 
> recipe. This bundle will keep this cert file in /etc/rauc/ folder so all 
> future bundle installations will need the exact same certificate.
> 
> Could you explain me what am I missing ? What method do you recommand to 
> manage certificates expirations over time ?

I guess you're trying to replace the expired certificate in a "Single
Key" scenario, which is not possible [1].  The documentaion lists some
other variants, though I am not sure which one applies best to your
use-case (maybe install hooks??).

> 
> Thank you very much.
> 
> Best regards,
> 
> Adrien MARTIN
> Ingénieur Système Embarqué STIMIO
> adrien.mar...@stimio.fr
> 1 Avenue du Professeur Jean Rouxel, ZAC de la Fleuriaye, 44470 Carquefou
> www.stimio.fr
> [stimio_logo]
> 
> ___
> RAUC mailing list

Best regards,
Thorsten

[1] https://rauc.readthedocs.io/en/latest/advanced.html#single-key

--
Thorsten Scherer 

___
meta-rauc mailing list

[RAUC] RAUC disable_counting logic

[Andreas Pretzsch]

Dear Enrico,
dear Patrick,

while integrating RAUC, I came across the same issue described in RAUC
github PR 346 [1] resp. barebox-ML [2].
I'd say this is a generic issue for all, especially embedded targets.

For barebox, Patrick Huesmann sketched and implemented a solution in PR
346 in Oct. 2018, extending RAUC bootchooser code and using barebox
features. But as far as I can see, neither this, nor a similar solution
got merged.

In my case, I need a comparable implementation for U-Boot (used on the
target device, customer decision). So I will go ahead and implement.
But in advance, I'd like to ask:
Is there (already) a mainline strategy how to handle this logic ?
Someone has (incomplete) code snippets to share ?

Also, it seems like all RAUC discussions are happening at github, not
via this mailing list. Is github the preferred tool here ?

Thanks in advance,
  Andreas

[1] https://github.com/rauc/rauc/pull/346
[2] http://lists.infradead.org/pipermail/barebox/2018-October/034961.html

-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas PretzschTel. +49-(0)7307-936088-1
Lange Strasse 28a   Fax: +49-(0)7307-936088-9
89250 Senden, Germany   email: a...@cn-eng.de


___
RAUC mailing list

Re: [RAUC] RAUC fails to mark slot as good --> fw_utils access error on mmc

[Enrico Joerns]

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] RAUC

[Enrico Joerns]

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] RAUC

[Taimir Aguacil]

Hi Enrico, 

Thank you for your detailed answer. This clarified some confusions. 

How do I subscribe to the mailing list ? 

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- |


___
RAUC mailing list

Re: [RAUC] RAUC

[Enrico Joerns]

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

[RAUC] RAUC

[Taimir Aguacil]

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 ?
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 ?

Thank you in advance.
Best Regards

Taimir Aguacil
Sr. Development Engineer
Radio & Communication Networks

Trapeze Switzerland GmbH
Industrieplatz 3 | 8212 Neuhausen | Switzerland

phone +41 58 911 17 92
fax +41 58 911 11 12
taimir.agua...@trapezegroup.com
www.trapezegroup.com
___
Proprietary and confidential. Distribution only by express authority of 
Constellation Software Inc. or its subsidiaries.


___
RAUC mailing list

[RAUC] Rauc in Commercial Product - Open Devices

[Djalal Harouni]

Hi Rauc hackers, Pengutronix,

I am Djalal Harouni I met you guys at several conferences, I am one of
the maintainers of systemd project, linux kernel security contributor
etc.

We did launch a startup in Berlin opendevices.io/ and we are going to
announce a beta version of our IoT Platform that targets Linux IoT
Devices. I have a hacky system updater experimental based on scripts,
but we are planning to use Rauc in our production solution.

I see that Rauc is under LPGL where we can use it, but as an Open
Source Software Developer, I have to inform you before. If our
business succeed, we may contribute patches back and even maybe
finance and help Rauc, as right now and unless you do not agree, our
long-term plan for system updates will be based solely on Rauc!  We
will produce updates, host them using simple nginx solution and
distribute notification and bundles using one of our agents, then
apply with Rauc. I think that should work.

Please if you have any comment or note do not hesitate!

The only thing that I can say: thank you for producing such robust
Software and making it Open Source!

Much appreciated!

All best,
Djalal

-- 
Open Devices IoT - Secure Light Linux-IoT

opendevices.io

___
RAUC mailing list

Re: [RAUC] RAUC bundle encryption, design question

[Evan Edstrom]

Thank you for the helpful feedback. I like the direction of this
design quite a bit. Agree with implementing the encryption using
OpenSSL in user-space. I will expand a little on our specific use
case, I'd like to dig a bit deeper on the CMS message contents.

We have a crypto key storage chip on our embedded device, an
ATSHA204A. We want to feed it a salt, and it will generate a key from
the given salt and its internal secret key. In our case all of the
devices, given the same salt, will produce the same key. I'd like to
use this key to decrypt the CMS message. Other users of RAUC may want
to handle this differently. I wasn't quite clear how you were
picturing RAUC being delivered a key for the CMS message in a generic
way.

Regardless, to use this approach we would need a portion of the bundle
metadata which is not encrypted to store the salt. Since this may
differ from user to user, I would propose allowing a user to pass a
file to the bundle generator which would be stored in the bundle
signed but not encrypted. On the device, we would need a handler to
deliver the data so we could  send it to the crypto device, then
provide the resulting key to RAUC to open the bundle. RAUC would then
have everything it needed to decrypt the message and in turn mount the
encrypted squashfs partition. A RAUC user wouldn't have to leverage
this, but a custom data section coupled with a handler between the
start and decrypt steps would be widely accommodating.

My other proposal is to either move or include a copy of the manifest
in the unencrypted but signed portion of the bundle metadata. Since
decrypting and mounting a bundle could take a little time, having it
easily accessible would allow getting a quick response from "rauc
info", it would be nice to do compatibility checks at this time too.
You could also inspect a bundle off-device to see what it was. For
example on a artifact storage server or web interface.

I drew a crude diagram. Wasn't sure if all mail clients rendering in
fixed width was a good assumption, so I put it here:
http://file.evanedstrom.com/osrc/rauc/misc/bundle_logic1.txt

Evan

On Thu, Aug 23, 2018 at 2:04 AM Jan Lübbe wrote:
> On Wed, 2018-08-22 at 13:27 -0700, Evan Edstrom wrote:
> > On Tue, Aug 21, 2018 at 1:03 AM, Jan Lübbe wrote:
> > > On Mon, 2018-08-20 at 11:39 -0700, Evan Edstrom wrote:
> > I agree building in encryption support is nice, though successful
> > implementation of encryption and security for embedded devices
> > requires some level of custom hardware.
> What kind of custom hardware are you thinking about? I'd prefer to
> reuse and integrate with existing HW/SW as much as possible.

Just mean that two embedded devices from different companies are
likely to look extremely different in terms of how they handle
security. Specifically key storage or generation (see use case above).

> > This is going to be very
> > device specific and I'm worried forcing the use of a specific
> > procedure may be too limiting. I wonder if we would still need to
> > provide some user customizability in the form of a handler somewhere.
> You want to use a random payload key for every bundle to avoid problems
> with key/IV reuse. So I think the (encrypted) payload key needs to be
> contained in the bundle metadata. If you have a fixed (shared secret)
> key on the devices, this could still be handle by passing it as a
> password to the CMS decryption.

I do like this idea of having a random payload key stored in an
encrypted CMS message. But somehow OpenSSL needs to get a key to
decrypt the CMS message. I am worried about the potential variety in
this area across devices.

___
RAUC mailing list

Re: [RAUC] RAUC bundle encryption, design question

[Jan Lübbe]

Hi Evan,

thanks for starting this discussion!

On Mon, 2018-08-20 at 11:39 -0700, Evan Edstrom wrote:
> I am using RAUC for a commercial product, and one of the things we
> need to accomplish is to encrypt our update bundles. I've manually
> created an encrypted rauc bundle using a LUKS container. Once the
> container is opened it can be mounted like normal as a squashfs
> partition and used by RAUC.

A normal RAUC bundle looks (mostly) like this:
[ squashfs ][ CMS signature over hash of squashfs ]

I expect that your LUKS container wraps both:
[ LUKS header ][ LUKS encrpytion ( RAUC bundle ) ]

So you get symmetric encryption of whole bundle with a password (i.e. a
shared secret), right?

While this setup is pretty straight forward, I see some downsides:
- RAUC cannot read any information about the bundle before decryption
- With a single shared secret, there is no way to revoke a compromised
key (for example extracted from a single device in the field)

> This seems generally useful; if this is something you'd like to see in
> the project I'd be happy to contribute and submit a pull request. I
> wanted to seek your input before I begin about the proper scope for
> this, as it could be achieved in many different ways. Here are the two
> methods I've narrowed in on.
> 
> * Option 1:
> Provide an optional "decryption handler" for the user to implement
> which provides the bundle path and mount point. A user would implement
> their decrypt and mount steps as needed. If the config file defines
> this handler, the update process would essentially run the handler
> instead of r_mount_loop() in bundle.c.

r_mount_loop() only runs after reading and verifying the bundle
signature, so it would need a different layout than the one above.
Something like:
[ LUKS header ][ LUKS encrpytion ( squashfs ) ] CMS signature over hash
of LUKS header+encrypted data ]

> This gives a user the most flexibility as they're not locked into any
> particular encryption method or even bundle format. Bundle creation gets
> a little more tricky as there isn't a concept of handlers built in. Could have
> an optional argument which provides a mounted and empty bundle.

A squashfs is generated by using mksquashfs. The result would then be
copied into a fresh LUKS container. So creating encrypted bundles would
required root.

> * Option 2:
> Implement encryption support directly into RAUC as a compile option.
> This could create an encrypted bundle and decrypt and mount during
> install time.
> 
> This is much easier to use and allows easy encrypted bundle creation,
> but is quite a bit less flexible. It also adds a dependency, like
> cryptsetup, to the project.

I'd definitely prefer built-in encryption support. Mainly because:
- It can be integrated with the existing CMS-based signatures, so we
get support for multiple recipient devices with individual private
keys.
- It's easier to use (you don't need to write a handler).
- By using dm-crypt without LUKS, we can generate the encrypted bundle
without requiring root privileges (via OpenSSL).
- When using per device private keys, we can also store them in a TPM
or a PKCS#11 token/smartcard, so they can't be easily extracted.

> For either option, there is the possibility of inspecting a bundle
> file's header and knowing whether to run the default mount function or
> the handler. This would be useful if you thought clients should be
> able to accept either encrypted or unencrypted bundles.
Yes. We'd also need an option in the system.conf to configure which key
to use for decryption.

> Perhaps there is a much better way to do this than I've thought of.
> I'd love to hear your thoughts on this.

As we use CMS [1] for signing, we can potentially support everything
the OpenSSL cms tool (see 'man cms') supports (N-of-M signatures,
encryption with shared secrets and/or public/private keys).

So my current concept would be to use a differemt payload in the CMS
message (instead of a hash over the squashfs), consisting of
information about the encryption (algorithm, parameters and payload
key) and the payload hash (or dm-verity root hash). The CMS message
would then be encrypted in addition to being signed.

When opening the bundle, OpenSSL would detect that the CMS message is
encrypted, look for the matching private key and decrypt. Then we have
the information to configure dm-crypt and/or dm-verity on top of the
loop device. The rest of the installation would proceed as usual.

So the only places that would need to change are bundle opening (setup
OpenSSL for decryption and configure device mapper targets) and bundle
creation (optionally encrypt, optionally use veritysetup and use
OpenSSL for CMS encyption).

What do you think about this apporach?

[1] https://tools.ietf.org/html/rfc5652
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: 

Re: [RAUC] Rauc and Hawkbit server

[Enrico Joerns]

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

[RAUC] Rauc and Hawkbit server

[Laurent GUILLIER]

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!

Regards

Laurent



___
RAUC mailing list