cip-dev.lists.cip-project.org archive mirror
 help / color / mirror / Atom feed
* [cip-dev] CIP IRC weekly meeting today
@ 2019-03-14  1:55 SZ Lin (林上智)
  2019-03-14  4:38 ` Nobuhiro Iwamatsu
  2019-03-14  7:26 ` daniel.sangorrin at toshiba.co.jp
  0 siblings, 2 replies; 40+ messages in thread
From: SZ Lin (林上智) @ 2019-03-14  1:55 UTC (permalink / raw)
  To: cip-dev

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that IRC meeting was rescheduled to 18:00 (JST) starting from the first week of Nov. according to F2F meeting discussion in ELCE.*

US-West US-East? UK??? DE???? TW???? JP
02:00??? 05:00?? 09:00?? 10:00?? 17:00?? 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Agenda:

* AI review
#action Iwamatsu-san will create a template page and send the link via mailing list afterward
#action Please send configuration file of kernel 4.19 to cip-dev before end of March.?

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update?
* AOB

The meeting will take 30 min although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,

SZ Lin, Moxa.

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-14  1:55 [cip-dev] CIP IRC weekly meeting today SZ Lin (林上智)
@ 2019-03-14  4:38 ` Nobuhiro Iwamatsu
  2019-03-14  7:26 ` daniel.sangorrin at toshiba.co.jp
  1 sibling, 0 replies; 40+ messages in thread
From: Nobuhiro Iwamatsu @ 2019-03-14  4:38 UTC (permalink / raw)
  To: cip-dev

Hi, SZ
I can not join IRC meeting today by personal reason.

2019?3?14?(?) 10:55 SZ Lin (???) <SZ.Lin@moxa.com>:
>
> Hi all,
>
> Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.
>
> *Please note that IRC meeting was rescheduled to 18:00 (JST) starting from the first week of Nov. according to F2F meeting discussion in ELCE.*
>
> US-West US-East  UK    DE     TW     JP
> 02:00    05:00   09:00   10:00   17:00   18:00
>
> Channel:
> * irc:chat.freenode.net:6667/cip
>
> Agenda:
>
> * AI review
> #action Iwamatsu-san will create a template page and send the link via mailing list afterward

I sent a mail about this.

> #action Please send configuration file of kernel 4.19 to cip-dev before end of March.
>
> * Kernel maintenance updates

I have no update.
I am working on releasing a new CIP kernel, but this is delayed.


> * Kernel testing
> * CIP Core
> * Software update
> * AOB
>
> The meeting will take 30 min although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.
>
> Best regards,
>
> SZ Lin, Moxa.

Best regards,
  Nobuhiro

> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-14  1:55 [cip-dev] CIP IRC weekly meeting today SZ Lin (林上智)
  2019-03-14  4:38 ` Nobuhiro Iwamatsu
@ 2019-03-14  7:26 ` daniel.sangorrin at toshiba.co.jp
  2019-03-14  9:19   ` Chris Paterson
                     ` (2 more replies)
  1 sibling, 3 replies; 40+ messages in thread
From: daniel.sangorrin at toshiba.co.jp @ 2019-03-14  7:26 UTC (permalink / raw)
  To: cip-dev

Hello SZ,

I can't attend today. I will write here a few updates

- I have added usbutils to CIP Core (Deby) for Patryk to use lsusb in his tests
   - it seems to work fine now: https://lava.ciplatform.org/scheduler/job/725
   - here is the YAML I used to test pwd, uname and lsusb. Anyone with an account can use it by clicking on "Resubmit" and optionally change the test: https://lava.ciplatform.org/scheduler/job/725/definition

- Suzuki-san has found a couple of issues in ISAR CIP Core.
  - when building ISAR for the beaglebone black it complains that "/debootstrap/debootstrap is not found" (or something like that). He will post a new issue on the Gitlab web page with the complete log.
  - after building ISAR for qemu succesfully, he tried to run start-qemu.sh x86_64 and there was an issue with --nographics that required to add ttyS0 (or something like that) to the qemu parameters. He will be sending a patch soon.
[Note] we are planning to develop the SWUpdate demo using ISAR, any advice or news about how to build SWUpdate on ISAR with the right U-Boot environment?

- Regarding SWUpdate we hit an issue that we had not expected before. Suzuki-san was trying to update the standard BBB debian image (or a yocto-made one), but there were many warnings about orphan nodes etc. After some investigation the reason seems to be that the rootfs is modified during the first boot (or something like that). This is probably one of the biggest problems with updating images instead of files.

# Sorry for the "something like that"s, I have not verified by myself everything

#action I have to upload to the wiki the SW updates tool comparison document
#action Mae please add a link to the SW updates wiki page from the embedded world CIP release page
https://www.linuxfoundation.org/press-release/2019/02/civil-infrastructure-platform-announces-new-super-long-term-support-kernel-that-advances-automation-machine-learning-and-artificial-intelligence/

Thanks,
Daniel

> -----Original Message-----
> From: cip-dev-bounces at lists.cip-project.org <cip-dev-bounces@lists.cip-project.org> On Behalf Of SZ Lin (?
> ??)
> Sent: Thursday, March 14, 2019 10:55 AM
> To: cip-dev at lists.cip-project.org
> Subject: [cip-dev] CIP IRC weekly meeting today
> 
> Hi all,
> 
> Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.
> 
> *Please note that IRC meeting was rescheduled to 18:00 (JST) starting from the first week of Nov. according to
> F2F meeting discussion in ELCE.*
> 
> US-West US-East? UK??? DE???? TW???? JP
> 02:00??? 05:00?? 09:00?? 10:00?? 17:00?? 18:00
> 
> Channel:
> * irc:chat.freenode.net:6667/cip
> 
> Agenda:
> 
> * AI review
> #action Iwamatsu-san will create a template page and send the link via mailing list afterward
> #action Please send configuration file of kernel 4.19 to cip-dev before end of March.
> 
> * Kernel maintenance updates
> * Kernel testing
> * CIP Core
> * Software update
> * AOB
> 
> The meeting will take 30 min although it can be extended to an hour if it makes sense and those involved in the
> topics can stay. Otherwise, the topic will be taken offline or in the next meeting.
> 
> Best regards,
> 
> SZ Lin, Moxa.
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-14  7:26 ` daniel.sangorrin at toshiba.co.jp
@ 2019-03-14  9:19   ` Chris Paterson
  2019-03-14  9:23   ` Patryk Mungai Ndungu
  2019-03-15  9:24   ` Jan Kiszka
  2 siblings, 0 replies; 40+ messages in thread
From: Chris Paterson @ 2019-03-14  9:19 UTC (permalink / raw)
  To: cip-dev

Hello Daniel,

> From: cip-dev-bounces at lists.cip-project.org <cip-dev-bounces@lists.cip-
> project.org> On Behalf Of daniel.sangorrin at toshiba.co.jp
> Sent: 14 March 2019 07:27
> 
> Hello SZ,
> 
> I can't attend today. I will write here a few updates
> 
> - I have added usbutils to CIP Core (Deby) for Patryk to use lsusb in his tests
>    - it seems to work fine now: https://lava.ciplatform.org/scheduler/job/725
>    - here is the YAML I used to test pwd, uname and lsusb. Anyone with an
> account can use it by clicking on "Resubmit" and optionally change the test:
> https://lava.ciplatform.org/scheduler/job/725/definition
Thank you for adding lsusb, and thank you for doing a trial run on the LAVA master. It's very helpful for everyone to see examples.

Kind regards, Chris

> 
> - Suzuki-san has found a couple of issues in ISAR CIP Core.
>   - when building ISAR for the beaglebone black it complains that
> "/debootstrap/debootstrap is not found" (or something like that). He will
> post a new issue on the Gitlab web page with the complete log.
>   - after building ISAR for qemu succesfully, he tried to run start-qemu.sh
> x86_64 and there was an issue with --nographics that required to add ttyS0
> (or something like that) to the qemu parameters. He will be sending a patch
> soon.
> [Note] we are planning to develop the SWUpdate demo using ISAR, any
> advice or news about how to build SWUpdate on ISAR with the right U-Boot
> environment?
> 
> - Regarding SWUpdate we hit an issue that we had not expected before.
> Suzuki-san was trying to update the standard BBB debian image (or a yocto-
> made one), but there were many warnings about orphan nodes etc. After
> some investigation the reason seems to be that the rootfs is modified during
> the first boot (or something like that). This is probably one of the biggest
> problems with updating images instead of files.
> 
> # Sorry for the "something like that"s, I have not verified by myself
> everything
> 
> #action I have to upload to the wiki the SW updates tool comparison
> document
> #action Mae please add a link to the SW updates wiki page from the
> embedded world CIP release page
> https://www.linuxfoundation.org/press-release/2019/02/civil-
> infrastructure-platform-announces-new-super-long-term-support-kernel-
> that-advances-automation-machine-learning-and-artificial-intelligence/
> 
> Thanks,
> Daniel
> 
> > -----Original Message-----
> > From: cip-dev-bounces at lists.cip-project.org <cip-dev-bounces@lists.cip-
> project.org> On Behalf Of SZ Lin (?
> > ??)
> > Sent: Thursday, March 14, 2019 10:55 AM
> > To: cip-dev at lists.cip-project.org
> > Subject: [cip-dev] CIP IRC weekly meeting today
> >
> > Hi all,
> >
> > Kindly be reminded to attend the weekly meeting through IRC to discuss
> technical topics with CIP kernel today.
> >
> > *Please note that IRC meeting was rescheduled to 18:00 (JST) starting from
> the first week of Nov. according to
> > F2F meeting discussion in ELCE.*
> >
> > US-West US-East? UK??? DE???? TW???? JP
> > 02:00??? 05:00?? 09:00?? 10:00?? 17:00?? 18:00
> >
> > Channel:
> > * irc:chat.freenode.net:6667/cip
> >
> > Agenda:
> >
> > * AI review
> > #action Iwamatsu-san will create a template page and send the link via
> mailing list afterward
> > #action Please send configuration file of kernel 4.19 to cip-dev before end
> of March.
> >
> > * Kernel maintenance updates
> > * Kernel testing
> > * CIP Core
> > * Software update
> > * AOB
> >
> > The meeting will take 30 min although it can be extended to an hour if it
> makes sense and those involved in the
> > topics can stay. Otherwise, the topic will be taken offline or in the next
> meeting.
> >
> > Best regards,
> >
> > SZ Lin, Moxa.
> > _______________________________________________
> > cip-dev mailing list
> > cip-dev at lists.cip-project.org
> > https://lists.cip-project.org/mailman/listinfo/cip-dev
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-14  7:26 ` daniel.sangorrin at toshiba.co.jp
  2019-03-14  9:19   ` Chris Paterson
@ 2019-03-14  9:23   ` Patryk Mungai Ndungu
  2019-03-15  9:24   ` Jan Kiszka
  2 siblings, 0 replies; 40+ messages in thread
From: Patryk Mungai Ndungu @ 2019-03-14  9:23 UTC (permalink / raw)
  To: cip-dev

Hello Daniel,

> -----Original Message-----
> From: daniel.sangorrin at toshiba.co.jp <daniel.sangorrin@toshiba.co.jp>
> Sent: 14 March 2019 07:27
> To: SZ.Lin at moxa.com; cip-dev at lists.cip-project.org
> Cc: Patryk Mungai Ndungu <patryk.mungai-ndungu.kx@renesas.com>;
> akihiro27.suzuki at toshiba.co.jp; maemalynn at linuxfoundation.org
> Subject: RE: CIP IRC weekly meeting today
> 
> Hello SZ,
> 
> I can't attend today. I will write here a few updates
> 
> - I have added usbutils to CIP Core (Deby) for Patryk to use lsusb in his tests
>    - it seems to work fine now: https://lava.ciplatform.org/scheduler/job/725
>    - here is the YAML I used to test pwd, uname and lsusb. Anyone with an
> account can use it by clicking on "Resubmit" and optionally change the test:
> https://lava.ciplatform.org/scheduler/job/725/definition
> 

Thank you for adding lsusb. Sorry for not getting back to you earlier. I'll try running the integration tests I pushed the other week using the updated cip-core.

In terms of internal testing, these are the packages we add to our RFS Yocto build in order to run tests:

bonnie++ e2fsprogs-mke2fs alsa-utils pciutils ethtool i2c-tools util-linux procps libpng imagemagick


Kind Regards,
Patryk


> - Suzuki-san has found a couple of issues in ISAR CIP Core.
>   - when building ISAR for the beaglebone black it complains that
> "/debootstrap/debootstrap is not found" (or something like that). He will
> post a new issue on the Gitlab web page with the complete log.
>   - after building ISAR for qemu succesfully, he tried to run start-qemu.sh
> x86_64 and there was an issue with --nographics that required to add ttyS0
> (or something like that) to the qemu parameters. He will be sending a patch
> soon.
> [Note] we are planning to develop the SWUpdate demo using ISAR, any
> advice or news about how to build SWUpdate on ISAR with the right U-Boot
> environment?
> 
> - Regarding SWUpdate we hit an issue that we had not expected before.
> Suzuki-san was trying to update the standard BBB debian image (or a yocto-
> made one), but there were many warnings about orphan nodes etc. After
> some investigation the reason seems to be that the rootfs is modified during
> the first boot (or something like that). This is probably one of the biggest
> problems with updating images instead of files.
> 
> # Sorry for the "something like that"s, I have not verified by myself
> everything
> 
> #action I have to upload to the wiki the SW updates tool comparison
> document
> #action Mae please add a link to the SW updates wiki page from the
> embedded world CIP release page
> https://www.linuxfoundation.org/press-release/2019/02/civil-
> infrastructure-platform-announces-new-super-long-term-support-kernel-
> that-advances-automation-machine-learning-and-artificial-intelligence/
> 
> Thanks,
> Daniel
> 
> > -----Original Message-----
> > From: cip-dev-bounces at lists.cip-project.org <cip-dev-bounces@lists.cip-
> project.org> On Behalf Of SZ Lin (?
> > ??)
> > Sent: Thursday, March 14, 2019 10:55 AM
> > To: cip-dev at lists.cip-project.org
> > Subject: [cip-dev] CIP IRC weekly meeting today
> >
> > Hi all,
> >
> > Kindly be reminded to attend the weekly meeting through IRC to discuss
> technical topics with CIP kernel today.
> >
> > *Please note that IRC meeting was rescheduled to 18:00 (JST) starting from
> the first week of Nov. according to
> > F2F meeting discussion in ELCE.*
> >
> > US-West US-East? UK??? DE???? TW???? JP
> > 02:00??? 05:00?? 09:00?? 10:00?? 17:00?? 18:00
> >
> > Channel:
> > * irc:chat.freenode.net:6667/cip
> >
> > Agenda:
> >
> > * AI review
> > #action Iwamatsu-san will create a template page and send the link via
> mailing list afterward
> > #action Please send configuration file of kernel 4.19 to cip-dev before end
> of March.
> >
> > * Kernel maintenance updates
> > * Kernel testing
> > * CIP Core
> > * Software update
> > * AOB
> >
> > The meeting will take 30 min although it can be extended to an hour if it
> makes sense and those involved in the
> > topics can stay. Otherwise, the topic will be taken offline or in the next
> meeting.
> >
> > Best regards,
> >
> > SZ Lin, Moxa.
> > _______________________________________________
> > cip-dev mailing list
> > cip-dev at lists.cip-project.org
> > https://lists.cip-project.org/mailman/listinfo/cip-dev

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-14  7:26 ` daniel.sangorrin at toshiba.co.jp
  2019-03-14  9:19   ` Chris Paterson
  2019-03-14  9:23   ` Patryk Mungai Ndungu
@ 2019-03-15  9:24   ` Jan Kiszka
  2019-03-15  9:48     ` akihiro27.suzuki at toshiba.co.jp
  2019-03-18  8:42     ` [cip-dev] CIP IRC weekly meeting today Christian Storm
  2 siblings, 2 replies; 40+ messages in thread
From: Jan Kiszka @ 2019-03-15  9:24 UTC (permalink / raw)
  To: cip-dev

On 14.03.19 08:26, daniel.sangorrin at toshiba.co.jp wrote:
> - Suzuki-san has found a couple of issues in ISAR CIP Core.
>    - when building ISAR for the beaglebone black it complains that "/debootstrap/debootstrap is not found" (or something like that). He will post a new issue on the Gitlab web page with the complete log.

Has this been resolved locally?

>    - after building ISAR for qemu succesfully, he tried to run start-qemu.sh x86_64 and there was an issue with --nographics that required to add ttyS0 (or something like that) to the qemu parameters. He will be sending a patch soon.

Thanks, already commented.

> [Note] we are planning to develop the SWUpdate demo using ISAR, any advice or news about how to build SWUpdate on ISAR with the right U-Boot environment?
> 
> - Regarding SWUpdate we hit an issue that we had not expected before. Suzuki-san was trying to update the standard BBB debian image (or a yocto-made one), but there were many warnings about orphan nodes etc. After some investigation the reason seems to be that the rootfs is modified during the first boot (or something like that). This is probably one of the biggest problems with updating images instead of files.

Christian, any remarks?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-15  9:24   ` Jan Kiszka
@ 2019-03-15  9:48     ` akihiro27.suzuki at toshiba.co.jp
  2019-03-15 10:50       ` Jan Kiszka
  2019-03-18  8:42     ` [cip-dev] CIP IRC weekly meeting today Christian Storm
  1 sibling, 1 reply; 40+ messages in thread
From: akihiro27.suzuki at toshiba.co.jp @ 2019-03-15  9:48 UTC (permalink / raw)
  To: cip-dev

Hi Jan,

> On 14.03.19 08:26, daniel.sangorrin at toshiba.co.jp wrote:
> > - Suzuki-san has found a couple of issues in ISAR CIP Core.
> >    - when building ISAR for the beaglebone black it complains that
> "/debootstrap/debootstrap is not found" (or something like that). He will
> post a new issue on the Gitlab web page with the complete log.
> 
> Has this been resolved locally?
When I tried to build isar-cip-core on another 2 machines, the error didn't occur.
So, my machine which occurred the error may have some problem.
I will check it when I have the time.

Best regards,
Suzuki

---
Akihiro Suzuki
Corporate Software Engineering & Technology Center
Toshiba Corporation
Tel: +81-44-549-2476
E-mail: akihiro27.suzuki at toshiba.co.jp 

> -----Original Message-----
> From: cip-dev-bounces at lists.cip-project.org
> [mailto:cip-dev-bounces at lists.cip-project.org] On Behalf Of Jan Kiszka
> Sent: Friday, March 15, 2019 6:24 PM
> To: sangorrin daniel(????? ???? ????????)
> <daniel.sangorrin@toshiba.co.jp>; SZ.Lin at moxa.com;
> cip-dev at lists.cip-project.org; Christian Storm
> <christian.storm@siemens.com>
> Subject: Re: [cip-dev] CIP IRC weekly meeting today
> 
> On 14.03.19 08:26, daniel.sangorrin at toshiba.co.jp wrote:
> > - Suzuki-san has found a couple of issues in ISAR CIP Core.
> >    - when building ISAR for the beaglebone black it complains that
> "/debootstrap/debootstrap is not found" (or something like that). He will
> post a new issue on the Gitlab web page with the complete log.
> 
> Has this been resolved locally?
> 
> >    - after building ISAR for qemu succesfully, he tried to run
> start-qemu.sh x86_64 and there was an issue with --nographics that
> required to add ttyS0 (or something like that) to the qemu parameters.
> He will be sending a patch soon.
> 
> Thanks, already commented.
> 
> > [Note] we are planning to develop the SWUpdate demo using ISAR, any
> advice or news about how to build SWUpdate on ISAR with the right U-Boot
> environment?
> >
> > - Regarding SWUpdate we hit an issue that we had not expected before.
> Suzuki-san was trying to update the standard BBB debian image (or a
> yocto-made one), but there were many warnings about orphan nodes etc.
> After some investigation the reason seems to be that the rootfs is modified
> during the first boot (or something like that). This is probably one of
> the biggest problems with updating images instead of files.
> 
> Christian, any remarks?
> 
> Jan
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-15  9:48     ` akihiro27.suzuki at toshiba.co.jp
@ 2019-03-15 10:50       ` Jan Kiszka
  2019-03-18  1:42         ` akihiro27.suzuki at toshiba.co.jp
  2019-03-18  2:53         ` [cip-dev] CIP IRC weekly meeting today akihiro27.suzuki at toshiba.co.jp
  0 siblings, 2 replies; 40+ messages in thread
From: Jan Kiszka @ 2019-03-15 10:50 UTC (permalink / raw)
  To: cip-dev

On 15.03.19 10:48, akihiro27.suzuki at toshiba.co.jp wrote:
> Hi Jan,
> 
>> On 14.03.19 08:26, daniel.sangorrin at toshiba.co.jp wrote:
>>> - Suzuki-san has found a couple of issues in ISAR CIP Core.
>>>     - when building ISAR for the beaglebone black it complains that
>> "/debootstrap/debootstrap is not found" (or something like that). He will
>> post a new issue on the Gitlab web page with the complete log.
>>
>> Has this been resolved locally?
> When I tried to build isar-cip-core on another 2 machines, the error didn't occur.
> So, my machine which occurred the error may have some problem.

Were you building natively on Debian or inside the kas container?

> I will check it when I have the time.

OK, thanks.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-15 10:50       ` Jan Kiszka
@ 2019-03-18  1:42         ` akihiro27.suzuki at toshiba.co.jp
  2019-03-18  9:05           ` [cip-dev] debootrap error (was: Re: CIP IRC weekly meeting today) Jan Kiszka
  2019-03-18  2:53         ` [cip-dev] CIP IRC weekly meeting today akihiro27.suzuki at toshiba.co.jp
  1 sibling, 1 reply; 40+ messages in thread
From: akihiro27.suzuki at toshiba.co.jp @ 2019-03-18  1:42 UTC (permalink / raw)
  To: cip-dev

Hi Jan,

> Were you building natively on Debian or inside the kas container?
I was executing following commands according to the README.md at isar-cip-core,
so I think I was building inside the kas container.

    $ wget https://raw.githubusercontent.com/siemens/kas/master/kas-docker
    $ chmod a+x kas-docker
    $ sudo ./kas-docker --isar build kas.yml:board-bbb.yml

The error is as follows (from log.do_bootstrap of isar-bootstrap-target):

    DEBUG: Executing shell function do_bootstrap
    I: Running command: debootstrap --arch armhf --foreign --verbose --variant=minbase --include=locales --components=main,contrib,non-free stretch /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/rootfs http://ftp.de.debian.org/debian
    I: Retrieving InRelease 
    I: Retrieving Release 
    I: Retrieving Release.gpg 
    I: Checking Release signature
    I: Valid Release signature (key id 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500)
    I: Retrieving Packages 
    I: Validating Packages 
    I: Retrieving Packages 
    I: Validating Packages 
    I: Retrieving Packages 
    I: Validating Packages 
    I: Resolving dependencies of required packages...
    I: Resolving dependencies of base packages...
    I: Found additional required dependencies: libaudit1 libaudit-common libbz2-1.0 libcap-ng0 libdb5.3 libdebconfclient0 libgcrypt20 libgpg-error0 liblz4-1 libncursesw5 libsemanage1 libsemanage-common libsystemd0 libudev1 libustr-1.0-1 
    I: Found additional base dependencies: adduser debian-archive-keyring gpgv libapt-pkg5.0 libc-l10n libstdc++6 
    I: Checking component main on http://ftp.de.debian.org/debian...
    I: Retrieving libacl1 2.2.52-3+b1
    I: Validating libacl1 2.2.52-3+b1
    I: Retrieving adduser 3.115
    I: Validating adduser 3.115
    I: Retrieving apt 1.4.9
    I: Validating apt 1.4.9
    I: Retrieving libapt-pkg5.0 1.4.9
    I: Validating libapt-pkg5.0 1.4.9
    I: Retrieving libattr1 1:2.4.47-2+b2
    I: Validating libattr1 1:2.4.47-2+b2
    I: Retrieving libaudit-common 1:2.6.7-2
    I: Validating libaudit-common 1:2.6.7-2
    I: Retrieving libaudit1 1:2.6.7-2
    I: Validating libaudit1 1:2.6.7-2
    I: Retrieving base-files 9.9+deb9u8
    I: Validating base-files 9.9+deb9u8
    I: Retrieving base-passwd 3.5.43
    I: Validating base-passwd 3.5.43
    I: Retrieving bash 4.4-5
    I: Validating bash 4.4-5
    I: Retrieving libbz2-1.0 1.0.6-8.1
    I: Validating libbz2-1.0 1.0.6-8.1
    I: Retrieving libdebconfclient0 0.227
    I: Validating libdebconfclient0 0.227
    I: Retrieving coreutils 8.26-3
    I: Validating coreutils 8.26-3
    I: Retrieving dash 0.5.8-2.4
    I: Validating dash 0.5.8-2.4
    I: Retrieving libdb5.3 5.3.28-12+deb9u1
    I: Validating libdb5.3 5.3.28-12+deb9u1
    I: Retrieving debconf 1.5.61
    I: Validating debconf 1.5.61
    I: Retrieving debian-archive-keyring 2017.5
    I: Validating debian-archive-keyring 2017.5
    I: Retrieving debianutils 4.8.1.1
    I: Validating debianutils 4.8.1.1
    I: Retrieving diffutils 1:3.5-3
    I: Validating diffutils 1:3.5-3
    I: Retrieving dpkg 1.18.25
    I: Validating dpkg 1.18.25
    I: Retrieving e2fslibs 1.43.4-2
    I: Validating e2fslibs 1.43.4-2
    I: Retrieving e2fsprogs 1.43.4-2
    I: Validating e2fsprogs 1.43.4-2
    I: Retrieving libcomerr2 1.43.4-2
    I: Validating libcomerr2 1.43.4-2
    I: Retrieving libss2 1.43.4-2
    I: Validating libss2 1.43.4-2
    I: Retrieving findutils 4.6.0+git+20161106-2
    I: Validating findutils 4.6.0+git+20161106-2
    I: Retrieving gcc-6-base 6.3.0-18+deb9u1
    I: Validating gcc-6-base 6.3.0-18+deb9u1
    I: Retrieving libgcc1 1:6.3.0-18+deb9u1
    I: Validating libgcc1 1:6.3.0-18+deb9u1
    I: Retrieving libstdc++6 6.3.0-18+deb9u1
    I: Validating libstdc++6 6.3.0-18+deb9u1
    I: Retrieving libc-bin 2.24-11+deb9u4
    I: Validating libc-bin 2.24-11+deb9u4
    I: Retrieving libc-l10n 2.24-11+deb9u4
    I: Validating libc-l10n 2.24-11+deb9u4
    I: Retrieving libc6 2.24-11+deb9u4
    I: Validating libc6 2.24-11+deb9u4
    I: Retrieving locales 2.24-11+deb9u4
    I: Validating locales 2.24-11+deb9u4
    I: Retrieving multiarch-support 2.24-11+deb9u4
    I: Validating multiarch-support 2.24-11+deb9u4
    I: Retrieving gpgv 2.1.18-8~deb9u4
    I: Validating gpgv 2.1.18-8~deb9u4
    I: Retrieving grep 2.27-2
    I: Validating grep 2.27-2
    I: Retrieving gzip 1.6-5+b1
    I: Validating gzip 1.6-5+b1
    I: Retrieving hostname 3.18+b1
    I: Validating hostname 3.18+b1
    I: Retrieving init-system-helpers 1.48
    I: Validating init-system-helpers 1.48
    I: Retrieving libcap-ng0 0.7.7-3+b1
    I: Validating libcap-ng0 0.7.7-3+b1
    I: Retrieving libgcrypt20 1.7.6-2+deb9u3
    I: Validating libgcrypt20 1.7.6-2+deb9u3
    I: Retrieving libgpg-error0 1.26-2
    I: Validating libgpg-error0 1.26-2
    I: Retrieving libselinux1 2.6-3+b3
    I: Validating libselinux1 2.6-3+b3
    I: Retrieving libsemanage-common 2.6-2
    I: Validating libsemanage-common 2.6-2
    I: Retrieving libsemanage1 2.6-2
    I: Validating libsemanage1 2.6-2
    I: Retrieving libsepol1 2.6-2
    I: Validating libsepol1 2.6-2
    I: Retrieving lsb-base 9.20161125
    I: Validating lsb-base 9.20161125
    I: Retrieving liblz4-1 0.0~r131-2+b1
    I: Validating liblz4-1 0.0~r131-2+b1
    I: Retrieving mawk 1.3.3-17+b3
    I: Validating mawk 1.3.3-17+b3
    I: Retrieving libncursesw5 6.0+20161126-1+deb9u2
    I: Validating libncursesw5 6.0+20161126-1+deb9u2
    I: Retrieving libtinfo5 6.0+20161126-1+deb9u2
    I: Validating libtinfo5 6.0+20161126-1+deb9u2
    I: Retrieving ncurses-base 6.0+20161126-1+deb9u2
    I: Validating ncurses-base 6.0+20161126-1+deb9u2
    I: Retrieving ncurses-bin 6.0+20161126-1+deb9u2
    I: Validating ncurses-bin 6.0+20161126-1+deb9u2
    I: Retrieving libpam-modules 1.1.8-3.6
    I: Validating libpam-modules 1.1.8-3.6
    I: Retrieving libpam-modules-bin 1.1.8-3.6
    I: Validating libpam-modules-bin 1.1.8-3.6
    I: Retrieving libpam-runtime 1.1.8-3.6
    I: Validating libpam-runtime 1.1.8-3.6
    I: Retrieving libpam0g 1.1.8-3.6
    I: Validating libpam0g 1.1.8-3.6
    I: Retrieving libpcre3 2:8.39-3
    I: Validating libpcre3 2:8.39-3
    I: Retrieving perl-base 5.24.1-3+deb9u5
    I: Validating perl-base 5.24.1-3+deb9u5
    I: Retrieving sed 4.4-1
    I: Validating sed 4.4-1
    I: Retrieving sensible-utils 0.0.9+deb9u1
    I: Validating sensible-utils 0.0.9+deb9u1
    I: Retrieving login 1:4.4-4.1
    I: Validating login 1:4.4-4.1
    I: Retrieving passwd 1:4.4-4.1
    I: Validating passwd 1:4.4-4.1
    I: Retrieving libsystemd0 232-25+deb9u8
    I: Validating libsystemd0 232-25+deb9u8
    I: Retrieving libudev1 232-25+deb9u8
    I: Validating libudev1 232-25+deb9u8
    I: Retrieving sysvinit-utils 2.88dsf-59.9
    I: Validating sysvinit-utils 2.88dsf-59.9
    I: Retrieving tar 1.29b-1.1
    I: Validating tar 1.29b-1.1
    I: Retrieving tzdata 2018i-0+deb9u1
    I: Validating tzdata 2018i-0+deb9u1
    I: Retrieving libustr-1.0-1 1.0.4-6
    I: Validating libustr-1.0-1 1.0.4-6
    I: Retrieving bsdutils 1:2.29.2-1+deb9u1
    I: Validating bsdutils 1:2.29.2-1+deb9u1
    I: Retrieving libblkid1 2.29.2-1+deb9u1
    I: Validating libblkid1 2.29.2-1+deb9u1
    I: Retrieving libfdisk1 2.29.2-1+deb9u1
    I: Validating libfdisk1 2.29.2-1+deb9u1
    I: Retrieving libmount1 2.29.2-1+deb9u1
    I: Validating libmount1 2.29.2-1+deb9u1
    I: Retrieving libsmartcols1 2.29.2-1+deb9u1
    I: Validating libsmartcols1 2.29.2-1+deb9u1
    I: Retrieving libuuid1 2.29.2-1+deb9u1
    I: Validating libuuid1 2.29.2-1+deb9u1
    I: Retrieving mount 2.29.2-1+deb9u1
    I: Validating mount 2.29.2-1+deb9u1
    I: Retrieving util-linux 2.29.2-1+deb9u1
    I: Validating util-linux 2.29.2-1+deb9u1
    I: Retrieving liblzma5 5.2.2-1.2+b1
    I: Validating liblzma5 5.2.2-1.2+b1
    I: Retrieving zlib1g 1:1.2.8.dfsg-5
    I: Validating zlib1g 1:1.2.8.dfsg-5
    I: Chosen extractor for .deb packages: dpkg-deb
    I: Extracting libacl1...
    I: Extracting libattr1...
    I: Extracting libaudit-common...
    I: Extracting libaudit1...
    I: Extracting base-files...
    I: Extracting base-passwd...
    I: Extracting bash...
    I: Extracting libbz2-1.0...
    I: Extracting libdebconfclient0...
    I: Extracting coreutils...
    I: Extracting dash...
    I: Extracting libdb5.3...
    I: Extracting debconf...
    I: Extracting debianutils...
    I: Extracting diffutils...
    I: Extracting dpkg...
    I: Extracting e2fslibs...
    I: Extracting e2fsprogs...
    I: Extracting libcomerr2...
    I: Extracting libss2...
    I: Extracting findutils...
    I: Extracting gcc-6-base...
    I: Extracting libgcc1...
    I: Extracting libc-bin...
    I: Extracting libc6...
    I: Extracting multiarch-support...
    I: Extracting grep...
    I: Extracting gzip...
    I: Extracting hostname...
    I: Extracting init-system-helpers...
    I: Extracting libcap-ng0...
    I: Extracting libgcrypt20...
    I: Extracting libgpg-error0...
    I: Extracting libselinux1...
    I: Extracting libsemanage-common...
    I: Extracting libsemanage1...
    I: Extracting libsepol1...
    I: Extracting lsb-base...
    I: Extracting liblz4-1...
    I: Extracting mawk...
    I: Extracting libncursesw5...
    I: Extracting libtinfo5...
    I: Extracting ncurses-base...
    I: Extracting ncurses-bin...
    I: Extracting libpam-modules...
    I: Extracting libpam-modules-bin...
    I: Extracting libpam-runtime...
    I: Extracting libpam0g...
    I: Extracting libpcre3...
    I: Extracting perl-base...
    I: Extracting sed...
    I: Extracting sensible-utils...
    I: Extracting login...
    I: Extracting passwd...
    I: Extracting libsystemd0...
    I: Extracting libudev1...
    I: Extracting sysvinit-utils...
    I: Extracting tar...
    I: Extracting tzdata...
    I: Extracting libustr-1.0-1...
    I: Extracting bsdutils...
    I: Extracting libblkid1...
    I: Extracting libfdisk1...
    I: Extracting libmount1...
    I: Extracting libsmartcols1...
    I: Extracting libuuid1...
    I: Extracting mount...
    I: Extracting util-linux...
    I: Extracting liblzma5...
    I: Extracting zlib1g...
    I: Running command: chroot /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/rootfs /debootstrap/debootstrap --second-stage
    chroot: failed to run command ?/debootstrap/debootstrap?: No such file or directory
    WARNING: exit code 127 from a shell command.
    ERROR: Function failed: do_bootstrap (log file is located at /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/temp/log.do_bootstrap.316)

Best regards,
Suzuki


> -----Original Message-----
> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
> Sent: Friday, March 15, 2019 7:50 PM
> To: suzuki akihiro(?? ?? ????????)
> <akihiro27.suzuki@toshiba.co.jp>; sangorrin daniel(????? ???
> ? ????????) <daniel.sangorrin@toshiba.co.jp>;
> SZ.Lin at moxa.com; cip-dev at lists.cip-project.org;
> christian.storm at siemens.com
> Subject: Re: [cip-dev] CIP IRC weekly meeting today
> 
> On 15.03.19 10:48, akihiro27.suzuki at toshiba.co.jp wrote:
> > Hi Jan,
> >
> >> On 14.03.19 08:26, daniel.sangorrin at toshiba.co.jp wrote:
> >>> - Suzuki-san has found a couple of issues in ISAR CIP Core.
> >>>     - when building ISAR for the beaglebone black it complains that
> >> "/debootstrap/debootstrap is not found" (or something like that). He
> will
> >> post a new issue on the Gitlab web page with the complete log.
> >>
> >> Has this been resolved locally?
> > When I tried to build isar-cip-core on another 2 machines, the error
> didn't occur.
> > So, my machine which occurred the error may have some problem.
> 
> Were you building natively on Debian or inside the kas container?
> 
> > I will check it when I have the time.
> 
> OK, thanks.
> 
> Jan
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-15 10:50       ` Jan Kiszka
  2019-03-18  1:42         ` akihiro27.suzuki at toshiba.co.jp
@ 2019-03-18  2:53         ` akihiro27.suzuki at toshiba.co.jp
  2019-03-18  8:56           ` [cip-dev] debootstrap error (was: Re: CIP IRC weekly meeting today) Jan Kiszka
  1 sibling, 1 reply; 40+ messages in thread
From: akihiro27.suzuki at toshiba.co.jp @ 2019-03-18  2:53 UTC (permalink / raw)
  To: cip-dev

>     $ sudo ./kas-docker --isar build kas.yml:board-bbb.yml
I made a mistake. We don't need sudo to run kas-docker.

Suzuki

> -----Original Message-----
> From: suzuki akihiro(?? ?? ????????)
> Sent: Monday, March 18, 2019 10:42 AM
> To: Jan Kiszka <jan.kiszka@siemens.com>; sangorrin daniel(????? ?
> ??? ????????) <daniel.sangorrin@toshiba.co.jp>;
> SZ.Lin at moxa.com; cip-dev at lists.cip-project.org;
> christian.storm at siemens.com
> Subject: RE: [cip-dev] CIP IRC weekly meeting today
> 
> Hi Jan,
> 
> > Were you building natively on Debian or inside the kas container?
> I was executing following commands according to the README.md at
> isar-cip-core,
> so I think I was building inside the kas container.
> 
>     $ wget
> https://raw.githubusercontent.com/siemens/kas/master/kas-docker
>     $ chmod a+x kas-docker
>     $ sudo ./kas-docker --isar build kas.yml:board-bbb.yml
> 
> The error is as follows (from log.do_bootstrap of isar-bootstrap-target):
> 
>     DEBUG: Executing shell function do_bootstrap
>     I: Running command: debootstrap --arch armhf --foreign --verbose
> --variant=minbase --include=locales
> --components=main,contrib,non-free stretch
> /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/rootfs
> http://ftp.de.debian.org/debian
>     I: Retrieving InRelease
>     I: Retrieving Release
>     I: Retrieving Release.gpg
>     I: Checking Release signature
>     I: Valid Release signature (key id
> 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500)
>     I: Retrieving Packages
>     I: Validating Packages
>     I: Retrieving Packages
>     I: Validating Packages
>     I: Retrieving Packages
>     I: Validating Packages
>     I: Resolving dependencies of required packages...
>     I: Resolving dependencies of base packages...
>     I: Found additional required dependencies: libaudit1
> libaudit-common libbz2-1.0 libcap-ng0 libdb5.3 libdebconfclient0
> libgcrypt20 libgpg-error0 liblz4-1 libncursesw5 libsemanage1
> libsemanage-common libsystemd0 libudev1 libustr-1.0-1
>     I: Found additional base dependencies: adduser
> debian-archive-keyring gpgv libapt-pkg5.0 libc-l10n libstdc++6
>     I: Checking component main on http://ftp.de.debian.org/debian...
>     I: Retrieving libacl1 2.2.52-3+b1
>     I: Validating libacl1 2.2.52-3+b1
>     I: Retrieving adduser 3.115
>     I: Validating adduser 3.115
>     I: Retrieving apt 1.4.9
>     I: Validating apt 1.4.9
>     I: Retrieving libapt-pkg5.0 1.4.9
>     I: Validating libapt-pkg5.0 1.4.9
>     I: Retrieving libattr1 1:2.4.47-2+b2
>     I: Validating libattr1 1:2.4.47-2+b2
>     I: Retrieving libaudit-common 1:2.6.7-2
>     I: Validating libaudit-common 1:2.6.7-2
>     I: Retrieving libaudit1 1:2.6.7-2
>     I: Validating libaudit1 1:2.6.7-2
>     I: Retrieving base-files 9.9+deb9u8
>     I: Validating base-files 9.9+deb9u8
>     I: Retrieving base-passwd 3.5.43
>     I: Validating base-passwd 3.5.43
>     I: Retrieving bash 4.4-5
>     I: Validating bash 4.4-5
>     I: Retrieving libbz2-1.0 1.0.6-8.1
>     I: Validating libbz2-1.0 1.0.6-8.1
>     I: Retrieving libdebconfclient0 0.227
>     I: Validating libdebconfclient0 0.227
>     I: Retrieving coreutils 8.26-3
>     I: Validating coreutils 8.26-3
>     I: Retrieving dash 0.5.8-2.4
>     I: Validating dash 0.5.8-2.4
>     I: Retrieving libdb5.3 5.3.28-12+deb9u1
>     I: Validating libdb5.3 5.3.28-12+deb9u1
>     I: Retrieving debconf 1.5.61
>     I: Validating debconf 1.5.61
>     I: Retrieving debian-archive-keyring 2017.5
>     I: Validating debian-archive-keyring 2017.5
>     I: Retrieving debianutils 4.8.1.1
>     I: Validating debianutils 4.8.1.1
>     I: Retrieving diffutils 1:3.5-3
>     I: Validating diffutils 1:3.5-3
>     I: Retrieving dpkg 1.18.25
>     I: Validating dpkg 1.18.25
>     I: Retrieving e2fslibs 1.43.4-2
>     I: Validating e2fslibs 1.43.4-2
>     I: Retrieving e2fsprogs 1.43.4-2
>     I: Validating e2fsprogs 1.43.4-2
>     I: Retrieving libcomerr2 1.43.4-2
>     I: Validating libcomerr2 1.43.4-2
>     I: Retrieving libss2 1.43.4-2
>     I: Validating libss2 1.43.4-2
>     I: Retrieving findutils 4.6.0+git+20161106-2
>     I: Validating findutils 4.6.0+git+20161106-2
>     I: Retrieving gcc-6-base 6.3.0-18+deb9u1
>     I: Validating gcc-6-base 6.3.0-18+deb9u1
>     I: Retrieving libgcc1 1:6.3.0-18+deb9u1
>     I: Validating libgcc1 1:6.3.0-18+deb9u1
>     I: Retrieving libstdc++6 6.3.0-18+deb9u1
>     I: Validating libstdc++6 6.3.0-18+deb9u1
>     I: Retrieving libc-bin 2.24-11+deb9u4
>     I: Validating libc-bin 2.24-11+deb9u4
>     I: Retrieving libc-l10n 2.24-11+deb9u4
>     I: Validating libc-l10n 2.24-11+deb9u4
>     I: Retrieving libc6 2.24-11+deb9u4
>     I: Validating libc6 2.24-11+deb9u4
>     I: Retrieving locales 2.24-11+deb9u4
>     I: Validating locales 2.24-11+deb9u4
>     I: Retrieving multiarch-support 2.24-11+deb9u4
>     I: Validating multiarch-support 2.24-11+deb9u4
>     I: Retrieving gpgv 2.1.18-8~deb9u4
>     I: Validating gpgv 2.1.18-8~deb9u4
>     I: Retrieving grep 2.27-2
>     I: Validating grep 2.27-2
>     I: Retrieving gzip 1.6-5+b1
>     I: Validating gzip 1.6-5+b1
>     I: Retrieving hostname 3.18+b1
>     I: Validating hostname 3.18+b1
>     I: Retrieving init-system-helpers 1.48
>     I: Validating init-system-helpers 1.48
>     I: Retrieving libcap-ng0 0.7.7-3+b1
>     I: Validating libcap-ng0 0.7.7-3+b1
>     I: Retrieving libgcrypt20 1.7.6-2+deb9u3
>     I: Validating libgcrypt20 1.7.6-2+deb9u3
>     I: Retrieving libgpg-error0 1.26-2
>     I: Validating libgpg-error0 1.26-2
>     I: Retrieving libselinux1 2.6-3+b3
>     I: Validating libselinux1 2.6-3+b3
>     I: Retrieving libsemanage-common 2.6-2
>     I: Validating libsemanage-common 2.6-2
>     I: Retrieving libsemanage1 2.6-2
>     I: Validating libsemanage1 2.6-2
>     I: Retrieving libsepol1 2.6-2
>     I: Validating libsepol1 2.6-2
>     I: Retrieving lsb-base 9.20161125
>     I: Validating lsb-base 9.20161125
>     I: Retrieving liblz4-1 0.0~r131-2+b1
>     I: Validating liblz4-1 0.0~r131-2+b1
>     I: Retrieving mawk 1.3.3-17+b3
>     I: Validating mawk 1.3.3-17+b3
>     I: Retrieving libncursesw5 6.0+20161126-1+deb9u2
>     I: Validating libncursesw5 6.0+20161126-1+deb9u2
>     I: Retrieving libtinfo5 6.0+20161126-1+deb9u2
>     I: Validating libtinfo5 6.0+20161126-1+deb9u2
>     I: Retrieving ncurses-base 6.0+20161126-1+deb9u2
>     I: Validating ncurses-base 6.0+20161126-1+deb9u2
>     I: Retrieving ncurses-bin 6.0+20161126-1+deb9u2
>     I: Validating ncurses-bin 6.0+20161126-1+deb9u2
>     I: Retrieving libpam-modules 1.1.8-3.6
>     I: Validating libpam-modules 1.1.8-3.6
>     I: Retrieving libpam-modules-bin 1.1.8-3.6
>     I: Validating libpam-modules-bin 1.1.8-3.6
>     I: Retrieving libpam-runtime 1.1.8-3.6
>     I: Validating libpam-runtime 1.1.8-3.6
>     I: Retrieving libpam0g 1.1.8-3.6
>     I: Validating libpam0g 1.1.8-3.6
>     I: Retrieving libpcre3 2:8.39-3
>     I: Validating libpcre3 2:8.39-3
>     I: Retrieving perl-base 5.24.1-3+deb9u5
>     I: Validating perl-base 5.24.1-3+deb9u5
>     I: Retrieving sed 4.4-1
>     I: Validating sed 4.4-1
>     I: Retrieving sensible-utils 0.0.9+deb9u1
>     I: Validating sensible-utils 0.0.9+deb9u1
>     I: Retrieving login 1:4.4-4.1
>     I: Validating login 1:4.4-4.1
>     I: Retrieving passwd 1:4.4-4.1
>     I: Validating passwd 1:4.4-4.1
>     I: Retrieving libsystemd0 232-25+deb9u8
>     I: Validating libsystemd0 232-25+deb9u8
>     I: Retrieving libudev1 232-25+deb9u8
>     I: Validating libudev1 232-25+deb9u8
>     I: Retrieving sysvinit-utils 2.88dsf-59.9
>     I: Validating sysvinit-utils 2.88dsf-59.9
>     I: Retrieving tar 1.29b-1.1
>     I: Validating tar 1.29b-1.1
>     I: Retrieving tzdata 2018i-0+deb9u1
>     I: Validating tzdata 2018i-0+deb9u1
>     I: Retrieving libustr-1.0-1 1.0.4-6
>     I: Validating libustr-1.0-1 1.0.4-6
>     I: Retrieving bsdutils 1:2.29.2-1+deb9u1
>     I: Validating bsdutils 1:2.29.2-1+deb9u1
>     I: Retrieving libblkid1 2.29.2-1+deb9u1
>     I: Validating libblkid1 2.29.2-1+deb9u1
>     I: Retrieving libfdisk1 2.29.2-1+deb9u1
>     I: Validating libfdisk1 2.29.2-1+deb9u1
>     I: Retrieving libmount1 2.29.2-1+deb9u1
>     I: Validating libmount1 2.29.2-1+deb9u1
>     I: Retrieving libsmartcols1 2.29.2-1+deb9u1
>     I: Validating libsmartcols1 2.29.2-1+deb9u1
>     I: Retrieving libuuid1 2.29.2-1+deb9u1
>     I: Validating libuuid1 2.29.2-1+deb9u1
>     I: Retrieving mount 2.29.2-1+deb9u1
>     I: Validating mount 2.29.2-1+deb9u1
>     I: Retrieving util-linux 2.29.2-1+deb9u1
>     I: Validating util-linux 2.29.2-1+deb9u1
>     I: Retrieving liblzma5 5.2.2-1.2+b1
>     I: Validating liblzma5 5.2.2-1.2+b1
>     I: Retrieving zlib1g 1:1.2.8.dfsg-5
>     I: Validating zlib1g 1:1.2.8.dfsg-5
>     I: Chosen extractor for .deb packages: dpkg-deb
>     I: Extracting libacl1...
>     I: Extracting libattr1...
>     I: Extracting libaudit-common...
>     I: Extracting libaudit1...
>     I: Extracting base-files...
>     I: Extracting base-passwd...
>     I: Extracting bash...
>     I: Extracting libbz2-1.0...
>     I: Extracting libdebconfclient0...
>     I: Extracting coreutils...
>     I: Extracting dash...
>     I: Extracting libdb5.3...
>     I: Extracting debconf...
>     I: Extracting debianutils...
>     I: Extracting diffutils...
>     I: Extracting dpkg...
>     I: Extracting e2fslibs...
>     I: Extracting e2fsprogs...
>     I: Extracting libcomerr2...
>     I: Extracting libss2...
>     I: Extracting findutils...
>     I: Extracting gcc-6-base...
>     I: Extracting libgcc1...
>     I: Extracting libc-bin...
>     I: Extracting libc6...
>     I: Extracting multiarch-support...
>     I: Extracting grep...
>     I: Extracting gzip...
>     I: Extracting hostname...
>     I: Extracting init-system-helpers...
>     I: Extracting libcap-ng0...
>     I: Extracting libgcrypt20...
>     I: Extracting libgpg-error0...
>     I: Extracting libselinux1...
>     I: Extracting libsemanage-common...
>     I: Extracting libsemanage1...
>     I: Extracting libsepol1...
>     I: Extracting lsb-base...
>     I: Extracting liblz4-1...
>     I: Extracting mawk...
>     I: Extracting libncursesw5...
>     I: Extracting libtinfo5...
>     I: Extracting ncurses-base...
>     I: Extracting ncurses-bin...
>     I: Extracting libpam-modules...
>     I: Extracting libpam-modules-bin...
>     I: Extracting libpam-runtime...
>     I: Extracting libpam0g...
>     I: Extracting libpcre3...
>     I: Extracting perl-base...
>     I: Extracting sed...
>     I: Extracting sensible-utils...
>     I: Extracting login...
>     I: Extracting passwd...
>     I: Extracting libsystemd0...
>     I: Extracting libudev1...
>     I: Extracting sysvinit-utils...
>     I: Extracting tar...
>     I: Extracting tzdata...
>     I: Extracting libustr-1.0-1...
>     I: Extracting bsdutils...
>     I: Extracting libblkid1...
>     I: Extracting libfdisk1...
>     I: Extracting libmount1...
>     I: Extracting libsmartcols1...
>     I: Extracting libuuid1...
>     I: Extracting mount...
>     I: Extracting util-linux...
>     I: Extracting liblzma5...
>     I: Extracting zlib1g...
>     I: Running command: chroot
> /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/rootfs
> /debootstrap/debootstrap --second-stage
>     chroot: failed to run command ?/debootstrap/debootstrap?: No such
> file or directory
>     WARNING: exit code 127 from a shell command.
>     ERROR: Function failed: do_bootstrap (log file is located at
> /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/temp/log.d
> o_bootstrap.316)
> 
> Best regards,
> Suzuki
> 
> 
> > -----Original Message-----
> > From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
> > Sent: Friday, March 15, 2019 7:50 PM
> > To: suzuki akihiro(?? ?? ????????)
> > <akihiro27.suzuki@toshiba.co.jp>; sangorrin daniel(????? ??
> ?
> > ? ????????) <daniel.sangorrin@toshiba.co.jp>;
> > SZ.Lin at moxa.com; cip-dev at lists.cip-project.org;
> > christian.storm at siemens.com
> > Subject: Re: [cip-dev] CIP IRC weekly meeting today
> >
> > On 15.03.19 10:48, akihiro27.suzuki at toshiba.co.jp wrote:
> > > Hi Jan,
> > >
> > >> On 14.03.19 08:26, daniel.sangorrin at toshiba.co.jp wrote:
> > >>> - Suzuki-san has found a couple of issues in ISAR CIP Core.
> > >>>     - when building ISAR for the beaglebone black it complains that
> > >> "/debootstrap/debootstrap is not found" (or something like that).
> He
> > will
> > >> post a new issue on the Gitlab web page with the complete log.
> > >>
> > >> Has this been resolved locally?
> > > When I tried to build isar-cip-core on another 2 machines, the error
> > didn't occur.
> > > So, my machine which occurred the error may have some problem.
> >
> > Were you building natively on Debian or inside the kas container?
> >
> > > I will check it when I have the time.
> >
> > OK, thanks.
> >
> > Jan
> >
> > --
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-15  9:24   ` Jan Kiszka
  2019-03-15  9:48     ` akihiro27.suzuki at toshiba.co.jp
@ 2019-03-18  8:42     ` Christian Storm
  2019-03-18  9:14       ` akihiro27.suzuki at toshiba.co.jp
  1 sibling, 1 reply; 40+ messages in thread
From: Christian Storm @ 2019-03-18  8:42 UTC (permalink / raw)
  To: cip-dev

Hi,

> > [Note] we are planning to develop the SWUpdate demo using ISAR, any
> > advice or news about how to build SWUpdate on ISAR with the right
> > U-Boot environment?
> > 
> > - Regarding SWUpdate we hit an issue that we had not expected
> > before. Suzuki-san was trying to update the standard BBB debian
> > image (or a yocto-made one), but there were many warnings about
> > orphan nodes etc. After some investigation the reason seems to be
> > that the rootfs is modified during the first boot (or something like
> > that). This is probably one of the biggest problems with updating
> > images instead of files.
> 
> Christian, any remarks?

Hm, did you check that you didn't flash the filesystem you have
currently booted, i.e., are you overwriting the currently running
root filesystem? I have seen such errors when I did this by accident.

Kind regards,
   Christian

-- 
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 M?nchen, Germany

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootstrap error (was: Re: CIP IRC weekly meeting today)
  2019-03-18  2:53         ` [cip-dev] CIP IRC weekly meeting today akihiro27.suzuki at toshiba.co.jp
@ 2019-03-18  8:56           ` Jan Kiszka
  2019-03-18  8:59             ` akihiro27.suzuki at toshiba.co.jp
  0 siblings, 1 reply; 40+ messages in thread
From: Jan Kiszka @ 2019-03-18  8:56 UTC (permalink / raw)
  To: cip-dev

On 18.03.19 03:53, akihiro27.suzuki at toshiba.co.jp wrote:
>>      $ sudo ./kas-docker --isar build kas.yml:board-bbb.yml
> I made a mistake. We don't need sudo to run kas-docker.
> 

Did that resolve the issue?

> Suzuki
> 
>> -----Original Message-----
>> From: suzuki akihiro(?? ?? ????????)
>> Sent: Monday, March 18, 2019 10:42 AM
>> To: Jan Kiszka <jan.kiszka@siemens.com>; sangorrin daniel(????? ?
>> ??? ????????) <daniel.sangorrin@toshiba.co.jp>;
>> SZ.Lin at moxa.com; cip-dev at lists.cip-project.org;
>> christian.storm at siemens.com
>> Subject: RE: [cip-dev] CIP IRC weekly meeting today
>>
>> Hi Jan,
>>
>>> Were you building natively on Debian or inside the kas container?
>> I was executing following commands according to the README.md at
>> isar-cip-core,
>> so I think I was building inside the kas container.
>>
>>      $ wget
>> https://raw.githubusercontent.com/siemens/kas/master/kas-docker
>>      $ chmod a+x kas-docker
>>      $ sudo ./kas-docker --isar build kas.yml:board-bbb.yml
>>
>> The error is as follows (from log.do_bootstrap of isar-bootstrap-target):
>>
>>      DEBUG: Executing shell function do_bootstrap
>>      I: Running command: debootstrap --arch armhf --foreign --verbose
>> --variant=minbase --include=locales
>> --components=main,contrib,non-free stretch
>> /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/rootfs
>> http://ftp.de.debian.org/debian
>>      I: Retrieving InRelease
>>      I: Retrieving Release
>>      I: Retrieving Release.gpg
>>      I: Checking Release signature
>>      I: Valid Release signature (key id
>> 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500)
>>      I: Retrieving Packages
>>      I: Validating Packages
>>      I: Retrieving Packages
>>      I: Validating Packages
>>      I: Retrieving Packages
>>      I: Validating Packages
>>      I: Resolving dependencies of required packages...
>>      I: Resolving dependencies of base packages...
>>      I: Found additional required dependencies: libaudit1
>> libaudit-common libbz2-1.0 libcap-ng0 libdb5.3 libdebconfclient0
>> libgcrypt20 libgpg-error0 liblz4-1 libncursesw5 libsemanage1
>> libsemanage-common libsystemd0 libudev1 libustr-1.0-1
>>      I: Found additional base dependencies: adduser
>> debian-archive-keyring gpgv libapt-pkg5.0 libc-l10n libstdc++6
>>      I: Checking component main on http://ftp.de.debian.org/debian...
>>      I: Retrieving libacl1 2.2.52-3+b1
>>      I: Validating libacl1 2.2.52-3+b1
>>      I: Retrieving adduser 3.115
>>      I: Validating adduser 3.115
>>      I: Retrieving apt 1.4.9
>>      I: Validating apt 1.4.9
>>      I: Retrieving libapt-pkg5.0 1.4.9
>>      I: Validating libapt-pkg5.0 1.4.9
>>      I: Retrieving libattr1 1:2.4.47-2+b2
>>      I: Validating libattr1 1:2.4.47-2+b2
>>      I: Retrieving libaudit-common 1:2.6.7-2
>>      I: Validating libaudit-common 1:2.6.7-2
>>      I: Retrieving libaudit1 1:2.6.7-2
>>      I: Validating libaudit1 1:2.6.7-2
>>      I: Retrieving base-files 9.9+deb9u8
>>      I: Validating base-files 9.9+deb9u8
>>      I: Retrieving base-passwd 3.5.43
>>      I: Validating base-passwd 3.5.43
>>      I: Retrieving bash 4.4-5
>>      I: Validating bash 4.4-5
>>      I: Retrieving libbz2-1.0 1.0.6-8.1
>>      I: Validating libbz2-1.0 1.0.6-8.1
>>      I: Retrieving libdebconfclient0 0.227
>>      I: Validating libdebconfclient0 0.227
>>      I: Retrieving coreutils 8.26-3
>>      I: Validating coreutils 8.26-3
>>      I: Retrieving dash 0.5.8-2.4
>>      I: Validating dash 0.5.8-2.4
>>      I: Retrieving libdb5.3 5.3.28-12+deb9u1
>>      I: Validating libdb5.3 5.3.28-12+deb9u1
>>      I: Retrieving debconf 1.5.61
>>      I: Validating debconf 1.5.61
>>      I: Retrieving debian-archive-keyring 2017.5
>>      I: Validating debian-archive-keyring 2017.5
>>      I: Retrieving debianutils 4.8.1.1
>>      I: Validating debianutils 4.8.1.1
>>      I: Retrieving diffutils 1:3.5-3
>>      I: Validating diffutils 1:3.5-3
>>      I: Retrieving dpkg 1.18.25
>>      I: Validating dpkg 1.18.25
>>      I: Retrieving e2fslibs 1.43.4-2
>>      I: Validating e2fslibs 1.43.4-2
>>      I: Retrieving e2fsprogs 1.43.4-2
>>      I: Validating e2fsprogs 1.43.4-2
>>      I: Retrieving libcomerr2 1.43.4-2
>>      I: Validating libcomerr2 1.43.4-2
>>      I: Retrieving libss2 1.43.4-2
>>      I: Validating libss2 1.43.4-2
>>      I: Retrieving findutils 4.6.0+git+20161106-2
>>      I: Validating findutils 4.6.0+git+20161106-2
>>      I: Retrieving gcc-6-base 6.3.0-18+deb9u1
>>      I: Validating gcc-6-base 6.3.0-18+deb9u1
>>      I: Retrieving libgcc1 1:6.3.0-18+deb9u1
>>      I: Validating libgcc1 1:6.3.0-18+deb9u1
>>      I: Retrieving libstdc++6 6.3.0-18+deb9u1
>>      I: Validating libstdc++6 6.3.0-18+deb9u1
>>      I: Retrieving libc-bin 2.24-11+deb9u4
>>      I: Validating libc-bin 2.24-11+deb9u4
>>      I: Retrieving libc-l10n 2.24-11+deb9u4
>>      I: Validating libc-l10n 2.24-11+deb9u4
>>      I: Retrieving libc6 2.24-11+deb9u4
>>      I: Validating libc6 2.24-11+deb9u4
>>      I: Retrieving locales 2.24-11+deb9u4
>>      I: Validating locales 2.24-11+deb9u4
>>      I: Retrieving multiarch-support 2.24-11+deb9u4
>>      I: Validating multiarch-support 2.24-11+deb9u4
>>      I: Retrieving gpgv 2.1.18-8~deb9u4
>>      I: Validating gpgv 2.1.18-8~deb9u4
>>      I: Retrieving grep 2.27-2
>>      I: Validating grep 2.27-2
>>      I: Retrieving gzip 1.6-5+b1
>>      I: Validating gzip 1.6-5+b1
>>      I: Retrieving hostname 3.18+b1
>>      I: Validating hostname 3.18+b1
>>      I: Retrieving init-system-helpers 1.48
>>      I: Validating init-system-helpers 1.48
>>      I: Retrieving libcap-ng0 0.7.7-3+b1
>>      I: Validating libcap-ng0 0.7.7-3+b1
>>      I: Retrieving libgcrypt20 1.7.6-2+deb9u3
>>      I: Validating libgcrypt20 1.7.6-2+deb9u3
>>      I: Retrieving libgpg-error0 1.26-2
>>      I: Validating libgpg-error0 1.26-2
>>      I: Retrieving libselinux1 2.6-3+b3
>>      I: Validating libselinux1 2.6-3+b3
>>      I: Retrieving libsemanage-common 2.6-2
>>      I: Validating libsemanage-common 2.6-2
>>      I: Retrieving libsemanage1 2.6-2
>>      I: Validating libsemanage1 2.6-2
>>      I: Retrieving libsepol1 2.6-2
>>      I: Validating libsepol1 2.6-2
>>      I: Retrieving lsb-base 9.20161125
>>      I: Validating lsb-base 9.20161125
>>      I: Retrieving liblz4-1 0.0~r131-2+b1
>>      I: Validating liblz4-1 0.0~r131-2+b1
>>      I: Retrieving mawk 1.3.3-17+b3
>>      I: Validating mawk 1.3.3-17+b3
>>      I: Retrieving libncursesw5 6.0+20161126-1+deb9u2
>>      I: Validating libncursesw5 6.0+20161126-1+deb9u2
>>      I: Retrieving libtinfo5 6.0+20161126-1+deb9u2
>>      I: Validating libtinfo5 6.0+20161126-1+deb9u2
>>      I: Retrieving ncurses-base 6.0+20161126-1+deb9u2
>>      I: Validating ncurses-base 6.0+20161126-1+deb9u2
>>      I: Retrieving ncurses-bin 6.0+20161126-1+deb9u2
>>      I: Validating ncurses-bin 6.0+20161126-1+deb9u2
>>      I: Retrieving libpam-modules 1.1.8-3.6
>>      I: Validating libpam-modules 1.1.8-3.6
>>      I: Retrieving libpam-modules-bin 1.1.8-3.6
>>      I: Validating libpam-modules-bin 1.1.8-3.6
>>      I: Retrieving libpam-runtime 1.1.8-3.6
>>      I: Validating libpam-runtime 1.1.8-3.6
>>      I: Retrieving libpam0g 1.1.8-3.6
>>      I: Validating libpam0g 1.1.8-3.6
>>      I: Retrieving libpcre3 2:8.39-3
>>      I: Validating libpcre3 2:8.39-3
>>      I: Retrieving perl-base 5.24.1-3+deb9u5
>>      I: Validating perl-base 5.24.1-3+deb9u5
>>      I: Retrieving sed 4.4-1
>>      I: Validating sed 4.4-1
>>      I: Retrieving sensible-utils 0.0.9+deb9u1
>>      I: Validating sensible-utils 0.0.9+deb9u1
>>      I: Retrieving login 1:4.4-4.1
>>      I: Validating login 1:4.4-4.1
>>      I: Retrieving passwd 1:4.4-4.1
>>      I: Validating passwd 1:4.4-4.1
>>      I: Retrieving libsystemd0 232-25+deb9u8
>>      I: Validating libsystemd0 232-25+deb9u8
>>      I: Retrieving libudev1 232-25+deb9u8
>>      I: Validating libudev1 232-25+deb9u8
>>      I: Retrieving sysvinit-utils 2.88dsf-59.9
>>      I: Validating sysvinit-utils 2.88dsf-59.9
>>      I: Retrieving tar 1.29b-1.1
>>      I: Validating tar 1.29b-1.1
>>      I: Retrieving tzdata 2018i-0+deb9u1
>>      I: Validating tzdata 2018i-0+deb9u1
>>      I: Retrieving libustr-1.0-1 1.0.4-6
>>      I: Validating libustr-1.0-1 1.0.4-6
>>      I: Retrieving bsdutils 1:2.29.2-1+deb9u1
>>      I: Validating bsdutils 1:2.29.2-1+deb9u1
>>      I: Retrieving libblkid1 2.29.2-1+deb9u1
>>      I: Validating libblkid1 2.29.2-1+deb9u1
>>      I: Retrieving libfdisk1 2.29.2-1+deb9u1
>>      I: Validating libfdisk1 2.29.2-1+deb9u1
>>      I: Retrieving libmount1 2.29.2-1+deb9u1
>>      I: Validating libmount1 2.29.2-1+deb9u1
>>      I: Retrieving libsmartcols1 2.29.2-1+deb9u1
>>      I: Validating libsmartcols1 2.29.2-1+deb9u1
>>      I: Retrieving libuuid1 2.29.2-1+deb9u1
>>      I: Validating libuuid1 2.29.2-1+deb9u1
>>      I: Retrieving mount 2.29.2-1+deb9u1
>>      I: Validating mount 2.29.2-1+deb9u1
>>      I: Retrieving util-linux 2.29.2-1+deb9u1
>>      I: Validating util-linux 2.29.2-1+deb9u1
>>      I: Retrieving liblzma5 5.2.2-1.2+b1
>>      I: Validating liblzma5 5.2.2-1.2+b1
>>      I: Retrieving zlib1g 1:1.2.8.dfsg-5
>>      I: Validating zlib1g 1:1.2.8.dfsg-5
>>      I: Chosen extractor for .deb packages: dpkg-deb
>>      I: Extracting libacl1...
>>      I: Extracting libattr1...
>>      I: Extracting libaudit-common...
>>      I: Extracting libaudit1...
>>      I: Extracting base-files...
>>      I: Extracting base-passwd...
>>      I: Extracting bash...
>>      I: Extracting libbz2-1.0...
>>      I: Extracting libdebconfclient0...
>>      I: Extracting coreutils...
>>      I: Extracting dash...
>>      I: Extracting libdb5.3...
>>      I: Extracting debconf...
>>      I: Extracting debianutils...
>>      I: Extracting diffutils...
>>      I: Extracting dpkg...
>>      I: Extracting e2fslibs...
>>      I: Extracting e2fsprogs...
>>      I: Extracting libcomerr2...
>>      I: Extracting libss2...
>>      I: Extracting findutils...
>>      I: Extracting gcc-6-base...
>>      I: Extracting libgcc1...
>>      I: Extracting libc-bin...
>>      I: Extracting libc6...
>>      I: Extracting multiarch-support...
>>      I: Extracting grep...
>>      I: Extracting gzip...
>>      I: Extracting hostname...
>>      I: Extracting init-system-helpers...
>>      I: Extracting libcap-ng0...
>>      I: Extracting libgcrypt20...
>>      I: Extracting libgpg-error0...
>>      I: Extracting libselinux1...
>>      I: Extracting libsemanage-common...
>>      I: Extracting libsemanage1...
>>      I: Extracting libsepol1...
>>      I: Extracting lsb-base...
>>      I: Extracting liblz4-1...
>>      I: Extracting mawk...
>>      I: Extracting libncursesw5...
>>      I: Extracting libtinfo5...
>>      I: Extracting ncurses-base...
>>      I: Extracting ncurses-bin...
>>      I: Extracting libpam-modules...
>>      I: Extracting libpam-modules-bin...
>>      I: Extracting libpam-runtime...
>>      I: Extracting libpam0g...
>>      I: Extracting libpcre3...
>>      I: Extracting perl-base...
>>      I: Extracting sed...
>>      I: Extracting sensible-utils...
>>      I: Extracting login...
>>      I: Extracting passwd...
>>      I: Extracting libsystemd0...
>>      I: Extracting libudev1...
>>      I: Extracting sysvinit-utils...
>>      I: Extracting tar...
>>      I: Extracting tzdata...
>>      I: Extracting libustr-1.0-1...
>>      I: Extracting bsdutils...
>>      I: Extracting libblkid1...
>>      I: Extracting libfdisk1...
>>      I: Extracting libmount1...
>>      I: Extracting libsmartcols1...
>>      I: Extracting libuuid1...
>>      I: Extracting mount...
>>      I: Extracting util-linux...
>>      I: Extracting liblzma5...
>>      I: Extracting zlib1g...
>>      I: Running command: chroot
>> /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/rootfs
>> /debootstrap/debootstrap --second-stage
>>      chroot: failed to run command ?/debootstrap/debootstrap?: No such
>> file or directory

This is weird: it's internal to debootstrap, and I don't see why it should happen.

>>      WARNING: exit code 127 from a shell command.
>>      ERROR: Function failed: do_bootstrap (log file is located at
>> /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/temp/log.d
>> o_bootstrap.316)
>>
>> Best regards,
>> Suzuki
>>
>>
>>> -----Original Message-----
>>> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
>>> Sent: Friday, March 15, 2019 7:50 PM
>>> To: suzuki akihiro(?? ?? ????????)
>>> <akihiro27.suzuki@toshiba.co.jp>; sangorrin daniel(????? ??
>> ?
>>> ? ????????) <daniel.sangorrin@toshiba.co.jp>;
>>> SZ.Lin at moxa.com; cip-dev at lists.cip-project.org;
>>> christian.storm at siemens.com
>>> Subject: Re: [cip-dev] CIP IRC weekly meeting today
>>>
>>> On 15.03.19 10:48, akihiro27.suzuki at toshiba.co.jp wrote:
>>>> Hi Jan,
>>>>
>>>>> On 14.03.19 08:26, daniel.sangorrin at toshiba.co.jp wrote:
>>>>>> - Suzuki-san has found a couple of issues in ISAR CIP Core.
>>>>>>      - when building ISAR for the beaglebone black it complains that
>>>>> "/debootstrap/debootstrap is not found" (or something like that).
>> He
>>> will
>>>>> post a new issue on the Gitlab web page with the complete log.
>>>>>
>>>>> Has this been resolved locally?
>>>> When I tried to build isar-cip-core on another 2 machines, the error
>>> didn't occur.
>>>> So, my machine which occurred the error may have some problem.
>>>
>>> Were you building natively on Debian or inside the kas container?
>>>
>>>> I will check it when I have the time.
>>>
>>> OK, thanks.
>>>
>>> Jan
>>>
>>> --
>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>>> Corporate Competence Center Embedded Linux

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootstrap error (was: Re: CIP IRC weekly meeting today)
  2019-03-18  8:56           ` [cip-dev] debootstrap error (was: Re: CIP IRC weekly meeting today) Jan Kiszka
@ 2019-03-18  8:59             ` akihiro27.suzuki at toshiba.co.jp
  0 siblings, 0 replies; 40+ messages in thread
From: akihiro27.suzuki at toshiba.co.jp @ 2019-03-18  8:59 UTC (permalink / raw)
  To: cip-dev

> On 18.03.19 03:53, akihiro27.suzuki at toshiba.co.jp wrote:
> >>      $ sudo ./kas-docker --isar build kas.yml:board-bbb.yml
> > I made a mistake. We don't need sudo to run kas-docker.
> >
> 
> Did that resolve the issue?
No. The error occurs with or without sudo.

Suzuki

> -----Original Message-----
> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
> Sent: Monday, March 18, 2019 5:57 PM
> To: suzuki akihiro(?? ?? ????????)
> <akihiro27.suzuki@toshiba.co.jp>; sangorrin daniel(????? ???
> ? ????????) <daniel.sangorrin@toshiba.co.jp>;
> SZ.Lin at moxa.com; cip-dev at lists.cip-project.org;
> christian.storm at siemens.com
> Subject: debootstrap error (was: Re: [cip-dev] CIP IRC weekly meeting
> today)
> 
> On 18.03.19 03:53, akihiro27.suzuki at toshiba.co.jp wrote:
> >>      $ sudo ./kas-docker --isar build kas.yml:board-bbb.yml
> > I made a mistake. We don't need sudo to run kas-docker.
> >
> 
> Did that resolve the issue?
> 
> > Suzuki
> >
> >> -----Original Message-----
> >> From: suzuki akihiro(?? ?? ????????)
> >> Sent: Monday, March 18, 2019 10:42 AM
> >> To: Jan Kiszka <jan.kiszka@siemens.com>; sangorrin daniel(????
> ? ?
> >> ??? ????????) <daniel.sangorrin@toshiba.co.jp>;
> >> SZ.Lin at moxa.com; cip-dev at lists.cip-project.org;
> >> christian.storm at siemens.com
> >> Subject: RE: [cip-dev] CIP IRC weekly meeting today
> >>
> >> Hi Jan,
> >>
> >>> Were you building natively on Debian or inside the kas container?
> >> I was executing following commands according to the README.md at
> >> isar-cip-core,
> >> so I think I was building inside the kas container.
> >>
> >>      $ wget
> >> https://raw.githubusercontent.com/siemens/kas/master/kas-docker
> >>      $ chmod a+x kas-docker
> >>      $ sudo ./kas-docker --isar build kas.yml:board-bbb.yml
> >>
> >> The error is as follows (from log.do_bootstrap of
> isar-bootstrap-target):
> >>
> >>      DEBUG: Executing shell function do_bootstrap
> >>      I: Running command: debootstrap --arch armhf --foreign --verbose
> >> --variant=minbase --include=locales
> >> --components=main,contrib,non-free stretch
> >> /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/rootfs
> >> http://ftp.de.debian.org/debian
> >>      I: Retrieving InRelease
> >>      I: Retrieving Release
> >>      I: Retrieving Release.gpg
> >>      I: Checking Release signature
> >>      I: Valid Release signature (key id
> >> 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500)
> >>      I: Retrieving Packages
> >>      I: Validating Packages
> >>      I: Retrieving Packages
> >>      I: Validating Packages
> >>      I: Retrieving Packages
> >>      I: Validating Packages
> >>      I: Resolving dependencies of required packages...
> >>      I: Resolving dependencies of base packages...
> >>      I: Found additional required dependencies: libaudit1
> >> libaudit-common libbz2-1.0 libcap-ng0 libdb5.3 libdebconfclient0
> >> libgcrypt20 libgpg-error0 liblz4-1 libncursesw5 libsemanage1
> >> libsemanage-common libsystemd0 libudev1 libustr-1.0-1
> >>      I: Found additional base dependencies: adduser
> >> debian-archive-keyring gpgv libapt-pkg5.0 libc-l10n libstdc++6
> >>      I: Checking component main on
> http://ftp.de.debian.org/debian...
> >>      I: Retrieving libacl1 2.2.52-3+b1
> >>      I: Validating libacl1 2.2.52-3+b1
> >>      I: Retrieving adduser 3.115
> >>      I: Validating adduser 3.115
> >>      I: Retrieving apt 1.4.9
> >>      I: Validating apt 1.4.9
> >>      I: Retrieving libapt-pkg5.0 1.4.9
> >>      I: Validating libapt-pkg5.0 1.4.9
> >>      I: Retrieving libattr1 1:2.4.47-2+b2
> >>      I: Validating libattr1 1:2.4.47-2+b2
> >>      I: Retrieving libaudit-common 1:2.6.7-2
> >>      I: Validating libaudit-common 1:2.6.7-2
> >>      I: Retrieving libaudit1 1:2.6.7-2
> >>      I: Validating libaudit1 1:2.6.7-2
> >>      I: Retrieving base-files 9.9+deb9u8
> >>      I: Validating base-files 9.9+deb9u8
> >>      I: Retrieving base-passwd 3.5.43
> >>      I: Validating base-passwd 3.5.43
> >>      I: Retrieving bash 4.4-5
> >>      I: Validating bash 4.4-5
> >>      I: Retrieving libbz2-1.0 1.0.6-8.1
> >>      I: Validating libbz2-1.0 1.0.6-8.1
> >>      I: Retrieving libdebconfclient0 0.227
> >>      I: Validating libdebconfclient0 0.227
> >>      I: Retrieving coreutils 8.26-3
> >>      I: Validating coreutils 8.26-3
> >>      I: Retrieving dash 0.5.8-2.4
> >>      I: Validating dash 0.5.8-2.4
> >>      I: Retrieving libdb5.3 5.3.28-12+deb9u1
> >>      I: Validating libdb5.3 5.3.28-12+deb9u1
> >>      I: Retrieving debconf 1.5.61
> >>      I: Validating debconf 1.5.61
> >>      I: Retrieving debian-archive-keyring 2017.5
> >>      I: Validating debian-archive-keyring 2017.5
> >>      I: Retrieving debianutils 4.8.1.1
> >>      I: Validating debianutils 4.8.1.1
> >>      I: Retrieving diffutils 1:3.5-3
> >>      I: Validating diffutils 1:3.5-3
> >>      I: Retrieving dpkg 1.18.25
> >>      I: Validating dpkg 1.18.25
> >>      I: Retrieving e2fslibs 1.43.4-2
> >>      I: Validating e2fslibs 1.43.4-2
> >>      I: Retrieving e2fsprogs 1.43.4-2
> >>      I: Validating e2fsprogs 1.43.4-2
> >>      I: Retrieving libcomerr2 1.43.4-2
> >>      I: Validating libcomerr2 1.43.4-2
> >>      I: Retrieving libss2 1.43.4-2
> >>      I: Validating libss2 1.43.4-2
> >>      I: Retrieving findutils 4.6.0+git+20161106-2
> >>      I: Validating findutils 4.6.0+git+20161106-2
> >>      I: Retrieving gcc-6-base 6.3.0-18+deb9u1
> >>      I: Validating gcc-6-base 6.3.0-18+deb9u1
> >>      I: Retrieving libgcc1 1:6.3.0-18+deb9u1
> >>      I: Validating libgcc1 1:6.3.0-18+deb9u1
> >>      I: Retrieving libstdc++6 6.3.0-18+deb9u1
> >>      I: Validating libstdc++6 6.3.0-18+deb9u1
> >>      I: Retrieving libc-bin 2.24-11+deb9u4
> >>      I: Validating libc-bin 2.24-11+deb9u4
> >>      I: Retrieving libc-l10n 2.24-11+deb9u4
> >>      I: Validating libc-l10n 2.24-11+deb9u4
> >>      I: Retrieving libc6 2.24-11+deb9u4
> >>      I: Validating libc6 2.24-11+deb9u4
> >>      I: Retrieving locales 2.24-11+deb9u4
> >>      I: Validating locales 2.24-11+deb9u4
> >>      I: Retrieving multiarch-support 2.24-11+deb9u4
> >>      I: Validating multiarch-support 2.24-11+deb9u4
> >>      I: Retrieving gpgv 2.1.18-8~deb9u4
> >>      I: Validating gpgv 2.1.18-8~deb9u4
> >>      I: Retrieving grep 2.27-2
> >>      I: Validating grep 2.27-2
> >>      I: Retrieving gzip 1.6-5+b1
> >>      I: Validating gzip 1.6-5+b1
> >>      I: Retrieving hostname 3.18+b1
> >>      I: Validating hostname 3.18+b1
> >>      I: Retrieving init-system-helpers 1.48
> >>      I: Validating init-system-helpers 1.48
> >>      I: Retrieving libcap-ng0 0.7.7-3+b1
> >>      I: Validating libcap-ng0 0.7.7-3+b1
> >>      I: Retrieving libgcrypt20 1.7.6-2+deb9u3
> >>      I: Validating libgcrypt20 1.7.6-2+deb9u3
> >>      I: Retrieving libgpg-error0 1.26-2
> >>      I: Validating libgpg-error0 1.26-2
> >>      I: Retrieving libselinux1 2.6-3+b3
> >>      I: Validating libselinux1 2.6-3+b3
> >>      I: Retrieving libsemanage-common 2.6-2
> >>      I: Validating libsemanage-common 2.6-2
> >>      I: Retrieving libsemanage1 2.6-2
> >>      I: Validating libsemanage1 2.6-2
> >>      I: Retrieving libsepol1 2.6-2
> >>      I: Validating libsepol1 2.6-2
> >>      I: Retrieving lsb-base 9.20161125
> >>      I: Validating lsb-base 9.20161125
> >>      I: Retrieving liblz4-1 0.0~r131-2+b1
> >>      I: Validating liblz4-1 0.0~r131-2+b1
> >>      I: Retrieving mawk 1.3.3-17+b3
> >>      I: Validating mawk 1.3.3-17+b3
> >>      I: Retrieving libncursesw5 6.0+20161126-1+deb9u2
> >>      I: Validating libncursesw5 6.0+20161126-1+deb9u2
> >>      I: Retrieving libtinfo5 6.0+20161126-1+deb9u2
> >>      I: Validating libtinfo5 6.0+20161126-1+deb9u2
> >>      I: Retrieving ncurses-base 6.0+20161126-1+deb9u2
> >>      I: Validating ncurses-base 6.0+20161126-1+deb9u2
> >>      I: Retrieving ncurses-bin 6.0+20161126-1+deb9u2
> >>      I: Validating ncurses-bin 6.0+20161126-1+deb9u2
> >>      I: Retrieving libpam-modules 1.1.8-3.6
> >>      I: Validating libpam-modules 1.1.8-3.6
> >>      I: Retrieving libpam-modules-bin 1.1.8-3.6
> >>      I: Validating libpam-modules-bin 1.1.8-3.6
> >>      I: Retrieving libpam-runtime 1.1.8-3.6
> >>      I: Validating libpam-runtime 1.1.8-3.6
> >>      I: Retrieving libpam0g 1.1.8-3.6
> >>      I: Validating libpam0g 1.1.8-3.6
> >>      I: Retrieving libpcre3 2:8.39-3
> >>      I: Validating libpcre3 2:8.39-3
> >>      I: Retrieving perl-base 5.24.1-3+deb9u5
> >>      I: Validating perl-base 5.24.1-3+deb9u5
> >>      I: Retrieving sed 4.4-1
> >>      I: Validating sed 4.4-1
> >>      I: Retrieving sensible-utils 0.0.9+deb9u1
> >>      I: Validating sensible-utils 0.0.9+deb9u1
> >>      I: Retrieving login 1:4.4-4.1
> >>      I: Validating login 1:4.4-4.1
> >>      I: Retrieving passwd 1:4.4-4.1
> >>      I: Validating passwd 1:4.4-4.1
> >>      I: Retrieving libsystemd0 232-25+deb9u8
> >>      I: Validating libsystemd0 232-25+deb9u8
> >>      I: Retrieving libudev1 232-25+deb9u8
> >>      I: Validating libudev1 232-25+deb9u8
> >>      I: Retrieving sysvinit-utils 2.88dsf-59.9
> >>      I: Validating sysvinit-utils 2.88dsf-59.9
> >>      I: Retrieving tar 1.29b-1.1
> >>      I: Validating tar 1.29b-1.1
> >>      I: Retrieving tzdata 2018i-0+deb9u1
> >>      I: Validating tzdata 2018i-0+deb9u1
> >>      I: Retrieving libustr-1.0-1 1.0.4-6
> >>      I: Validating libustr-1.0-1 1.0.4-6
> >>      I: Retrieving bsdutils 1:2.29.2-1+deb9u1
> >>      I: Validating bsdutils 1:2.29.2-1+deb9u1
> >>      I: Retrieving libblkid1 2.29.2-1+deb9u1
> >>      I: Validating libblkid1 2.29.2-1+deb9u1
> >>      I: Retrieving libfdisk1 2.29.2-1+deb9u1
> >>      I: Validating libfdisk1 2.29.2-1+deb9u1
> >>      I: Retrieving libmount1 2.29.2-1+deb9u1
> >>      I: Validating libmount1 2.29.2-1+deb9u1
> >>      I: Retrieving libsmartcols1 2.29.2-1+deb9u1
> >>      I: Validating libsmartcols1 2.29.2-1+deb9u1
> >>      I: Retrieving libuuid1 2.29.2-1+deb9u1
> >>      I: Validating libuuid1 2.29.2-1+deb9u1
> >>      I: Retrieving mount 2.29.2-1+deb9u1
> >>      I: Validating mount 2.29.2-1+deb9u1
> >>      I: Retrieving util-linux 2.29.2-1+deb9u1
> >>      I: Validating util-linux 2.29.2-1+deb9u1
> >>      I: Retrieving liblzma5 5.2.2-1.2+b1
> >>      I: Validating liblzma5 5.2.2-1.2+b1
> >>      I: Retrieving zlib1g 1:1.2.8.dfsg-5
> >>      I: Validating zlib1g 1:1.2.8.dfsg-5
> >>      I: Chosen extractor for .deb packages: dpkg-deb
> >>      I: Extracting libacl1...
> >>      I: Extracting libattr1...
> >>      I: Extracting libaudit-common...
> >>      I: Extracting libaudit1...
> >>      I: Extracting base-files...
> >>      I: Extracting base-passwd...
> >>      I: Extracting bash...
> >>      I: Extracting libbz2-1.0...
> >>      I: Extracting libdebconfclient0...
> >>      I: Extracting coreutils...
> >>      I: Extracting dash...
> >>      I: Extracting libdb5.3...
> >>      I: Extracting debconf...
> >>      I: Extracting debianutils...
> >>      I: Extracting diffutils...
> >>      I: Extracting dpkg...
> >>      I: Extracting e2fslibs...
> >>      I: Extracting e2fsprogs...
> >>      I: Extracting libcomerr2...
> >>      I: Extracting libss2...
> >>      I: Extracting findutils...
> >>      I: Extracting gcc-6-base...
> >>      I: Extracting libgcc1...
> >>      I: Extracting libc-bin...
> >>      I: Extracting libc6...
> >>      I: Extracting multiarch-support...
> >>      I: Extracting grep...
> >>      I: Extracting gzip...
> >>      I: Extracting hostname...
> >>      I: Extracting init-system-helpers...
> >>      I: Extracting libcap-ng0...
> >>      I: Extracting libgcrypt20...
> >>      I: Extracting libgpg-error0...
> >>      I: Extracting libselinux1...
> >>      I: Extracting libsemanage-common...
> >>      I: Extracting libsemanage1...
> >>      I: Extracting libsepol1...
> >>      I: Extracting lsb-base...
> >>      I: Extracting liblz4-1...
> >>      I: Extracting mawk...
> >>      I: Extracting libncursesw5...
> >>      I: Extracting libtinfo5...
> >>      I: Extracting ncurses-base...
> >>      I: Extracting ncurses-bin...
> >>      I: Extracting libpam-modules...
> >>      I: Extracting libpam-modules-bin...
> >>      I: Extracting libpam-runtime...
> >>      I: Extracting libpam0g...
> >>      I: Extracting libpcre3...
> >>      I: Extracting perl-base...
> >>      I: Extracting sed...
> >>      I: Extracting sensible-utils...
> >>      I: Extracting login...
> >>      I: Extracting passwd...
> >>      I: Extracting libsystemd0...
> >>      I: Extracting libudev1...
> >>      I: Extracting sysvinit-utils...
> >>      I: Extracting tar...
> >>      I: Extracting tzdata...
> >>      I: Extracting libustr-1.0-1...
> >>      I: Extracting bsdutils...
> >>      I: Extracting libblkid1...
> >>      I: Extracting libfdisk1...
> >>      I: Extracting libmount1...
> >>      I: Extracting libsmartcols1...
> >>      I: Extracting libuuid1...
> >>      I: Extracting mount...
> >>      I: Extracting util-linux...
> >>      I: Extracting liblzma5...
> >>      I: Extracting zlib1g...
> >>      I: Running command: chroot
> >> /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/rootfs
> >> /debootstrap/debootstrap --second-stage
> >>      chroot: failed to run command ?/debootstrap/debootstrap?: No
> such
> >> file or directory
> 
> This is weird: it's internal to debootstrap, and I don't see why it should
> happen.
> 
> >>      WARNING: exit code 127 from a shell command.
> >>      ERROR: Function failed: do_bootstrap (log file is located at
> >>
> /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/temp/log.d
> >> o_bootstrap.316)
> >>
> >> Best regards,
> >> Suzuki
> >>
> >>
> >>> -----Original Message-----
> >>> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
> >>> Sent: Friday, March 15, 2019 7:50 PM
> >>> To: suzuki akihiro(?? ?? ????????)
> >>> <akihiro27.suzuki@toshiba.co.jp>; sangorrin daniel(????? ?
> ?
> >> ?
> >>> ? ????????) <daniel.sangorrin@toshiba.co.jp>;
> >>> SZ.Lin at moxa.com; cip-dev at lists.cip-project.org;
> >>> christian.storm at siemens.com
> >>> Subject: Re: [cip-dev] CIP IRC weekly meeting today
> >>>
> >>> On 15.03.19 10:48, akihiro27.suzuki at toshiba.co.jp wrote:
> >>>> Hi Jan,
> >>>>
> >>>>> On 14.03.19 08:26, daniel.sangorrin at toshiba.co.jp wrote:
> >>>>>> - Suzuki-san has found a couple of issues in ISAR CIP Core.
> >>>>>>      - when building ISAR for the beaglebone black it complains
> that
> >>>>> "/debootstrap/debootstrap is not found" (or something like that).
> >> He
> >>> will
> >>>>> post a new issue on the Gitlab web page with the complete log.
> >>>>>
> >>>>> Has this been resolved locally?
> >>>> When I tried to build isar-cip-core on another 2 machines, the error
> >>> didn't occur.
> >>>> So, my machine which occurred the error may have some problem.
> >>>
> >>> Were you building natively on Debian or inside the kas container?
> >>>
> >>>> I will check it when I have the time.
> >>>
> >>> OK, thanks.
> >>>
> >>> Jan
> >>>
> >>> --
> >>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >>> Corporate Competence Center Embedded Linux
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error (was: Re: CIP IRC weekly meeting today)
  2019-03-18  1:42         ` akihiro27.suzuki at toshiba.co.jp
@ 2019-03-18  9:05           ` Jan Kiszka
  2019-03-18  9:11             ` Claudius Heine
  0 siblings, 1 reply; 40+ messages in thread
From: Jan Kiszka @ 2019-03-18  9:05 UTC (permalink / raw)
  To: cip-dev

On 18.03.19 02:42, akihiro27.suzuki at toshiba.co.jp wrote:
> Hi Jan,
> 
>> Were you building natively on Debian or inside the kas container?
> I was executing following commands according to the README.md at isar-cip-core,
> so I think I was building inside the kas container.
> 
>      $ wget https://raw.githubusercontent.com/siemens/kas/master/kas-docker
>      $ chmod a+x kas-docker
>      $ sudo ./kas-docker --isar build kas.yml:board-bbb.yml
> 
> The error is as follows (from log.do_bootstrap of isar-bootstrap-target):
> 
>      DEBUG: Executing shell function do_bootstrap
>      I: Running command: debootstrap --arch armhf --foreign --verbose --variant=minbase --include=locales --components=main,contrib,non-free stretch /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/rootfs http://ftp.de.debian.org/debian
>      I: Retrieving InRelease
>      I: Retrieving Release
>      I: Retrieving Release.gpg
>      I: Checking Release signature
>      I: Valid Release signature (key id 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500)
>      I: Retrieving Packages
>      I: Validating Packages
>      I: Retrieving Packages
>      I: Validating Packages
>      I: Retrieving Packages
>      I: Validating Packages
>      I: Resolving dependencies of required packages...
>      I: Resolving dependencies of base packages...
>      I: Found additional required dependencies: libaudit1 libaudit-common libbz2-1.0 libcap-ng0 libdb5.3 libdebconfclient0 libgcrypt20 libgpg-error0 liblz4-1 libncursesw5 libsemanage1 libsemanage-common libsystemd0 libudev1 libustr-1.0-1
>      I: Found additional base dependencies: adduser debian-archive-keyring gpgv libapt-pkg5.0 libc-l10n libstdc++6
>      I: Checking component main on http://ftp.de.debian.org/debian...
>      I: Retrieving libacl1 2.2.52-3+b1
>      I: Validating libacl1 2.2.52-3+b1
>      I: Retrieving adduser 3.115
>      I: Validating adduser 3.115
>      I: Retrieving apt 1.4.9
>      I: Validating apt 1.4.9
>      I: Retrieving libapt-pkg5.0 1.4.9
>      I: Validating libapt-pkg5.0 1.4.9
>      I: Retrieving libattr1 1:2.4.47-2+b2
>      I: Validating libattr1 1:2.4.47-2+b2
>      I: Retrieving libaudit-common 1:2.6.7-2
>      I: Validating libaudit-common 1:2.6.7-2
>      I: Retrieving libaudit1 1:2.6.7-2
>      I: Validating libaudit1 1:2.6.7-2
>      I: Retrieving base-files 9.9+deb9u8
>      I: Validating base-files 9.9+deb9u8
>      I: Retrieving base-passwd 3.5.43
>      I: Validating base-passwd 3.5.43
>      I: Retrieving bash 4.4-5
>      I: Validating bash 4.4-5
>      I: Retrieving libbz2-1.0 1.0.6-8.1
>      I: Validating libbz2-1.0 1.0.6-8.1
>      I: Retrieving libdebconfclient0 0.227
>      I: Validating libdebconfclient0 0.227
>      I: Retrieving coreutils 8.26-3
>      I: Validating coreutils 8.26-3
>      I: Retrieving dash 0.5.8-2.4
>      I: Validating dash 0.5.8-2.4
>      I: Retrieving libdb5.3 5.3.28-12+deb9u1
>      I: Validating libdb5.3 5.3.28-12+deb9u1
>      I: Retrieving debconf 1.5.61
>      I: Validating debconf 1.5.61
>      I: Retrieving debian-archive-keyring 2017.5
>      I: Validating debian-archive-keyring 2017.5
>      I: Retrieving debianutils 4.8.1.1
>      I: Validating debianutils 4.8.1.1
>      I: Retrieving diffutils 1:3.5-3
>      I: Validating diffutils 1:3.5-3
>      I: Retrieving dpkg 1.18.25
>      I: Validating dpkg 1.18.25
>      I: Retrieving e2fslibs 1.43.4-2
>      I: Validating e2fslibs 1.43.4-2
>      I: Retrieving e2fsprogs 1.43.4-2
>      I: Validating e2fsprogs 1.43.4-2
>      I: Retrieving libcomerr2 1.43.4-2
>      I: Validating libcomerr2 1.43.4-2
>      I: Retrieving libss2 1.43.4-2
>      I: Validating libss2 1.43.4-2
>      I: Retrieving findutils 4.6.0+git+20161106-2
>      I: Validating findutils 4.6.0+git+20161106-2
>      I: Retrieving gcc-6-base 6.3.0-18+deb9u1
>      I: Validating gcc-6-base 6.3.0-18+deb9u1
>      I: Retrieving libgcc1 1:6.3.0-18+deb9u1
>      I: Validating libgcc1 1:6.3.0-18+deb9u1
>      I: Retrieving libstdc++6 6.3.0-18+deb9u1
>      I: Validating libstdc++6 6.3.0-18+deb9u1
>      I: Retrieving libc-bin 2.24-11+deb9u4
>      I: Validating libc-bin 2.24-11+deb9u4
>      I: Retrieving libc-l10n 2.24-11+deb9u4
>      I: Validating libc-l10n 2.24-11+deb9u4
>      I: Retrieving libc6 2.24-11+deb9u4
>      I: Validating libc6 2.24-11+deb9u4
>      I: Retrieving locales 2.24-11+deb9u4
>      I: Validating locales 2.24-11+deb9u4
>      I: Retrieving multiarch-support 2.24-11+deb9u4
>      I: Validating multiarch-support 2.24-11+deb9u4
>      I: Retrieving gpgv 2.1.18-8~deb9u4
>      I: Validating gpgv 2.1.18-8~deb9u4
>      I: Retrieving grep 2.27-2
>      I: Validating grep 2.27-2
>      I: Retrieving gzip 1.6-5+b1
>      I: Validating gzip 1.6-5+b1
>      I: Retrieving hostname 3.18+b1
>      I: Validating hostname 3.18+b1
>      I: Retrieving init-system-helpers 1.48
>      I: Validating init-system-helpers 1.48
>      I: Retrieving libcap-ng0 0.7.7-3+b1
>      I: Validating libcap-ng0 0.7.7-3+b1
>      I: Retrieving libgcrypt20 1.7.6-2+deb9u3
>      I: Validating libgcrypt20 1.7.6-2+deb9u3
>      I: Retrieving libgpg-error0 1.26-2
>      I: Validating libgpg-error0 1.26-2
>      I: Retrieving libselinux1 2.6-3+b3
>      I: Validating libselinux1 2.6-3+b3
>      I: Retrieving libsemanage-common 2.6-2
>      I: Validating libsemanage-common 2.6-2
>      I: Retrieving libsemanage1 2.6-2
>      I: Validating libsemanage1 2.6-2
>      I: Retrieving libsepol1 2.6-2
>      I: Validating libsepol1 2.6-2
>      I: Retrieving lsb-base 9.20161125
>      I: Validating lsb-base 9.20161125
>      I: Retrieving liblz4-1 0.0~r131-2+b1
>      I: Validating liblz4-1 0.0~r131-2+b1
>      I: Retrieving mawk 1.3.3-17+b3
>      I: Validating mawk 1.3.3-17+b3
>      I: Retrieving libncursesw5 6.0+20161126-1+deb9u2
>      I: Validating libncursesw5 6.0+20161126-1+deb9u2
>      I: Retrieving libtinfo5 6.0+20161126-1+deb9u2
>      I: Validating libtinfo5 6.0+20161126-1+deb9u2
>      I: Retrieving ncurses-base 6.0+20161126-1+deb9u2
>      I: Validating ncurses-base 6.0+20161126-1+deb9u2
>      I: Retrieving ncurses-bin 6.0+20161126-1+deb9u2
>      I: Validating ncurses-bin 6.0+20161126-1+deb9u2
>      I: Retrieving libpam-modules 1.1.8-3.6
>      I: Validating libpam-modules 1.1.8-3.6
>      I: Retrieving libpam-modules-bin 1.1.8-3.6
>      I: Validating libpam-modules-bin 1.1.8-3.6
>      I: Retrieving libpam-runtime 1.1.8-3.6
>      I: Validating libpam-runtime 1.1.8-3.6
>      I: Retrieving libpam0g 1.1.8-3.6
>      I: Validating libpam0g 1.1.8-3.6
>      I: Retrieving libpcre3 2:8.39-3
>      I: Validating libpcre3 2:8.39-3
>      I: Retrieving perl-base 5.24.1-3+deb9u5
>      I: Validating perl-base 5.24.1-3+deb9u5
>      I: Retrieving sed 4.4-1
>      I: Validating sed 4.4-1
>      I: Retrieving sensible-utils 0.0.9+deb9u1
>      I: Validating sensible-utils 0.0.9+deb9u1
>      I: Retrieving login 1:4.4-4.1
>      I: Validating login 1:4.4-4.1
>      I: Retrieving passwd 1:4.4-4.1
>      I: Validating passwd 1:4.4-4.1
>      I: Retrieving libsystemd0 232-25+deb9u8
>      I: Validating libsystemd0 232-25+deb9u8
>      I: Retrieving libudev1 232-25+deb9u8
>      I: Validating libudev1 232-25+deb9u8
>      I: Retrieving sysvinit-utils 2.88dsf-59.9
>      I: Validating sysvinit-utils 2.88dsf-59.9
>      I: Retrieving tar 1.29b-1.1
>      I: Validating tar 1.29b-1.1
>      I: Retrieving tzdata 2018i-0+deb9u1
>      I: Validating tzdata 2018i-0+deb9u1
>      I: Retrieving libustr-1.0-1 1.0.4-6
>      I: Validating libustr-1.0-1 1.0.4-6
>      I: Retrieving bsdutils 1:2.29.2-1+deb9u1
>      I: Validating bsdutils 1:2.29.2-1+deb9u1
>      I: Retrieving libblkid1 2.29.2-1+deb9u1
>      I: Validating libblkid1 2.29.2-1+deb9u1
>      I: Retrieving libfdisk1 2.29.2-1+deb9u1
>      I: Validating libfdisk1 2.29.2-1+deb9u1
>      I: Retrieving libmount1 2.29.2-1+deb9u1
>      I: Validating libmount1 2.29.2-1+deb9u1
>      I: Retrieving libsmartcols1 2.29.2-1+deb9u1
>      I: Validating libsmartcols1 2.29.2-1+deb9u1
>      I: Retrieving libuuid1 2.29.2-1+deb9u1
>      I: Validating libuuid1 2.29.2-1+deb9u1
>      I: Retrieving mount 2.29.2-1+deb9u1
>      I: Validating mount 2.29.2-1+deb9u1
>      I: Retrieving util-linux 2.29.2-1+deb9u1
>      I: Validating util-linux 2.29.2-1+deb9u1
>      I: Retrieving liblzma5 5.2.2-1.2+b1
>      I: Validating liblzma5 5.2.2-1.2+b1
>      I: Retrieving zlib1g 1:1.2.8.dfsg-5
>      I: Validating zlib1g 1:1.2.8.dfsg-5
>      I: Chosen extractor for .deb packages: dpkg-deb
>      I: Extracting libacl1...
>      I: Extracting libattr1...
>      I: Extracting libaudit-common...
>      I: Extracting libaudit1...
>      I: Extracting base-files...
>      I: Extracting base-passwd...
>      I: Extracting bash...
>      I: Extracting libbz2-1.0...
>      I: Extracting libdebconfclient0...
>      I: Extracting coreutils...
>      I: Extracting dash...
>      I: Extracting libdb5.3...
>      I: Extracting debconf...
>      I: Extracting debianutils...
>      I: Extracting diffutils...
>      I: Extracting dpkg...
>      I: Extracting e2fslibs...
>      I: Extracting e2fsprogs...
>      I: Extracting libcomerr2...
>      I: Extracting libss2...
>      I: Extracting findutils...
>      I: Extracting gcc-6-base...
>      I: Extracting libgcc1...
>      I: Extracting libc-bin...
>      I: Extracting libc6...
>      I: Extracting multiarch-support...
>      I: Extracting grep...
>      I: Extracting gzip...
>      I: Extracting hostname...
>      I: Extracting init-system-helpers...
>      I: Extracting libcap-ng0...
>      I: Extracting libgcrypt20...
>      I: Extracting libgpg-error0...
>      I: Extracting libselinux1...
>      I: Extracting libsemanage-common...
>      I: Extracting libsemanage1...
>      I: Extracting libsepol1...
>      I: Extracting lsb-base...
>      I: Extracting liblz4-1...
>      I: Extracting mawk...
>      I: Extracting libncursesw5...
>      I: Extracting libtinfo5...
>      I: Extracting ncurses-base...
>      I: Extracting ncurses-bin...
>      I: Extracting libpam-modules...
>      I: Extracting libpam-modules-bin...
>      I: Extracting libpam-runtime...
>      I: Extracting libpam0g...
>      I: Extracting libpcre3...
>      I: Extracting perl-base...
>      I: Extracting sed...
>      I: Extracting sensible-utils...
>      I: Extracting login...
>      I: Extracting passwd...
>      I: Extracting libsystemd0...
>      I: Extracting libudev1...
>      I: Extracting sysvinit-utils...
>      I: Extracting tar...
>      I: Extracting tzdata...
>      I: Extracting libustr-1.0-1...
>      I: Extracting bsdutils...
>      I: Extracting libblkid1...
>      I: Extracting libfdisk1...
>      I: Extracting libmount1...
>      I: Extracting libsmartcols1...
>      I: Extracting libuuid1...
>      I: Extracting mount...
>      I: Extracting util-linux...
>      I: Extracting liblzma5...
>      I: Extracting zlib1g...
>      I: Running command: chroot /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/rootfs /debootstrap/debootstrap --second-stage
>      chroot: failed to run command ?/debootstrap/debootstrap?: No such file or directory
>      WARNING: exit code 127 from a shell command.
>      ERROR: Function failed: do_bootstrap (log file is located at /work/build/tmp/work/cip-core-armhf/isar-bootstrap-target/temp/log.do_bootstrap.316)
> 

Looping in isar-users and Claudius. I've no idea why debootstrap should stumble here, apparently over its own feet.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error (was: Re: CIP IRC weekly meeting today)
  2019-03-18  9:05           ` [cip-dev] debootrap error (was: Re: CIP IRC weekly meeting today) Jan Kiszka
@ 2019-03-18  9:11             ` Claudius Heine
  2019-03-18  9:39               ` [cip-dev] debootrap error Jan Kiszka
  0 siblings, 1 reply; 40+ messages in thread
From: Claudius Heine @ 2019-03-18  9:11 UTC (permalink / raw)
  To: cip-dev

Hi,

On Mon, 2019-03-18 at 10:05 +0100, [ext] Jan Kiszka wrote:
> On 18.03.19 02:42, akihiro27.suzuki at toshiba.co.jp wrote:
> > Hi Jan,
> > 
> > > Were you building natively on Debian or inside the kas container?
> > I was executing following commands according to the README.md at
> > isar-cip-core,
> > so I think I was building inside the kas container.
> > 
> >      $ wget 
> > https://raw.githubusercontent.com/siemens/kas/master/kas-docker
> >      $ chmod a+x kas-docker
> >      $ sudo ./kas-docker --isar build kas.yml:board-bbb.yml
> > 
> > The error is as follows (from log.do_bootstrap of isar-bootstrap-
> > target):
> > 
> >      DEBUG: Executing shell function do_bootstrap
> >      I: Running command: debootstrap --arch armhf --foreign --
> > verbose --variant=minbase --include=locales --
> > components=main,contrib,non-free stretch /work/build/tmp/work/cip-
> > core-armhf/isar-bootstrap-target/rootfs 
> > http://ftp.de.debian.org/debian
> >      I: Retrieving InRelease
> >      I: Retrieving Release
> >      I: Retrieving Release.gpg
> >      I: Checking Release signature
> >      I: Valid Release signature (key id
> > 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500)
> >      I: Retrieving Packages
> >      I: Validating Packages
> >      I: Retrieving Packages
> >      I: Validating Packages
> >      I: Retrieving Packages
> >      I: Validating Packages
> >      I: Resolving dependencies of required packages...
> >      I: Resolving dependencies of base packages...
> >      I: Found additional required dependencies: libaudit1 libaudit-
> > common libbz2-1.0 libcap-ng0 libdb5.3 libdebconfclient0 libgcrypt20
> > libgpg-error0 liblz4-1 libncursesw5 libsemanage1 libsemanage-common 
> > libsystemd0 libudev1 libustr-1.0-1
> >      I: Found additional base dependencies: adduser debian-archive-
> > keyring gpgv libapt-pkg5.0 libc-l10n libstdc++6
> >      I: Checking component main on http://ftp.de.debian.org/debian.
> > ..
> >      I: Retrieving libacl1 2.2.52-3+b1
> >      I: Validating libacl1 2.2.52-3+b1
> >      I: Retrieving adduser 3.115
> >      I: Validating adduser 3.115
> >      I: Retrieving apt 1.4.9
> >      I: Validating apt 1.4.9
> >      I: Retrieving libapt-pkg5.0 1.4.9
> >      I: Validating libapt-pkg5.0 1.4.9
> >      I: Retrieving libattr1 1:2.4.47-2+b2
> >      I: Validating libattr1 1:2.4.47-2+b2
> >      I: Retrieving libaudit-common 1:2.6.7-2
> >      I: Validating libaudit-common 1:2.6.7-2
> >      I: Retrieving libaudit1 1:2.6.7-2
> >      I: Validating libaudit1 1:2.6.7-2
> >      I: Retrieving base-files 9.9+deb9u8
> >      I: Validating base-files 9.9+deb9u8
> >      I: Retrieving base-passwd 3.5.43
> >      I: Validating base-passwd 3.5.43
> >      I: Retrieving bash 4.4-5
> >      I: Validating bash 4.4-5
> >      I: Retrieving libbz2-1.0 1.0.6-8.1
> >      I: Validating libbz2-1.0 1.0.6-8.1
> >      I: Retrieving libdebconfclient0 0.227
> >      I: Validating libdebconfclient0 0.227
> >      I: Retrieving coreutils 8.26-3
> >      I: Validating coreutils 8.26-3
> >      I: Retrieving dash 0.5.8-2.4
> >      I: Validating dash 0.5.8-2.4
> >      I: Retrieving libdb5.3 5.3.28-12+deb9u1
> >      I: Validating libdb5.3 5.3.28-12+deb9u1
> >      I: Retrieving debconf 1.5.61
> >      I: Validating debconf 1.5.61
> >      I: Retrieving debian-archive-keyring 2017.5
> >      I: Validating debian-archive-keyring 2017.5
> >      I: Retrieving debianutils 4.8.1.1
> >      I: Validating debianutils 4.8.1.1
> >      I: Retrieving diffutils 1:3.5-3
> >      I: Validating diffutils 1:3.5-3
> >      I: Retrieving dpkg 1.18.25
> >      I: Validating dpkg 1.18.25
> >      I: Retrieving e2fslibs 1.43.4-2
> >      I: Validating e2fslibs 1.43.4-2
> >      I: Retrieving e2fsprogs 1.43.4-2
> >      I: Validating e2fsprogs 1.43.4-2
> >      I: Retrieving libcomerr2 1.43.4-2
> >      I: Validating libcomerr2 1.43.4-2
> >      I: Retrieving libss2 1.43.4-2
> >      I: Validating libss2 1.43.4-2
> >      I: Retrieving findutils 4.6.0+git+20161106-2
> >      I: Validating findutils 4.6.0+git+20161106-2
> >      I: Retrieving gcc-6-base 6.3.0-18+deb9u1
> >      I: Validating gcc-6-base 6.3.0-18+deb9u1
> >      I: Retrieving libgcc1 1:6.3.0-18+deb9u1
> >      I: Validating libgcc1 1:6.3.0-18+deb9u1
> >      I: Retrieving libstdc++6 6.3.0-18+deb9u1
> >      I: Validating libstdc++6 6.3.0-18+deb9u1
> >      I: Retrieving libc-bin 2.24-11+deb9u4
> >      I: Validating libc-bin 2.24-11+deb9u4
> >      I: Retrieving libc-l10n 2.24-11+deb9u4
> >      I: Validating libc-l10n 2.24-11+deb9u4
> >      I: Retrieving libc6 2.24-11+deb9u4
> >      I: Validating libc6 2.24-11+deb9u4
> >      I: Retrieving locales 2.24-11+deb9u4
> >      I: Validating locales 2.24-11+deb9u4
> >      I: Retrieving multiarch-support 2.24-11+deb9u4
> >      I: Validating multiarch-support 2.24-11+deb9u4
> >      I: Retrieving gpgv 2.1.18-8~deb9u4
> >      I: Validating gpgv 2.1.18-8~deb9u4
> >      I: Retrieving grep 2.27-2
> >      I: Validating grep 2.27-2
> >      I: Retrieving gzip 1.6-5+b1
> >      I: Validating gzip 1.6-5+b1
> >      I: Retrieving hostname 3.18+b1
> >      I: Validating hostname 3.18+b1
> >      I: Retrieving init-system-helpers 1.48
> >      I: Validating init-system-helpers 1.48
> >      I: Retrieving libcap-ng0 0.7.7-3+b1
> >      I: Validating libcap-ng0 0.7.7-3+b1
> >      I: Retrieving libgcrypt20 1.7.6-2+deb9u3
> >      I: Validating libgcrypt20 1.7.6-2+deb9u3
> >      I: Retrieving libgpg-error0 1.26-2
> >      I: Validating libgpg-error0 1.26-2
> >      I: Retrieving libselinux1 2.6-3+b3
> >      I: Validating libselinux1 2.6-3+b3
> >      I: Retrieving libsemanage-common 2.6-2
> >      I: Validating libsemanage-common 2.6-2
> >      I: Retrieving libsemanage1 2.6-2
> >      I: Validating libsemanage1 2.6-2
> >      I: Retrieving libsepol1 2.6-2
> >      I: Validating libsepol1 2.6-2
> >      I: Retrieving lsb-base 9.20161125
> >      I: Validating lsb-base 9.20161125
> >      I: Retrieving liblz4-1 0.0~r131-2+b1
> >      I: Validating liblz4-1 0.0~r131-2+b1
> >      I: Retrieving mawk 1.3.3-17+b3
> >      I: Validating mawk 1.3.3-17+b3
> >      I: Retrieving libncursesw5 6.0+20161126-1+deb9u2
> >      I: Validating libncursesw5 6.0+20161126-1+deb9u2
> >      I: Retrieving libtinfo5 6.0+20161126-1+deb9u2
> >      I: Validating libtinfo5 6.0+20161126-1+deb9u2
> >      I: Retrieving ncurses-base 6.0+20161126-1+deb9u2
> >      I: Validating ncurses-base 6.0+20161126-1+deb9u2
> >      I: Retrieving ncurses-bin 6.0+20161126-1+deb9u2
> >      I: Validating ncurses-bin 6.0+20161126-1+deb9u2
> >      I: Retrieving libpam-modules 1.1.8-3.6
> >      I: Validating libpam-modules 1.1.8-3.6
> >      I: Retrieving libpam-modules-bin 1.1.8-3.6
> >      I: Validating libpam-modules-bin 1.1.8-3.6
> >      I: Retrieving libpam-runtime 1.1.8-3.6
> >      I: Validating libpam-runtime 1.1.8-3.6
> >      I: Retrieving libpam0g 1.1.8-3.6
> >      I: Validating libpam0g 1.1.8-3.6
> >      I: Retrieving libpcre3 2:8.39-3
> >      I: Validating libpcre3 2:8.39-3
> >      I: Retrieving perl-base 5.24.1-3+deb9u5
> >      I: Validating perl-base 5.24.1-3+deb9u5
> >      I: Retrieving sed 4.4-1
> >      I: Validating sed 4.4-1
> >      I: Retrieving sensible-utils 0.0.9+deb9u1
> >      I: Validating sensible-utils 0.0.9+deb9u1
> >      I: Retrieving login 1:4.4-4.1
> >      I: Validating login 1:4.4-4.1
> >      I: Retrieving passwd 1:4.4-4.1
> >      I: Validating passwd 1:4.4-4.1
> >      I: Retrieving libsystemd0 232-25+deb9u8
> >      I: Validating libsystemd0 232-25+deb9u8
> >      I: Retrieving libudev1 232-25+deb9u8
> >      I: Validating libudev1 232-25+deb9u8
> >      I: Retrieving sysvinit-utils 2.88dsf-59.9
> >      I: Validating sysvinit-utils 2.88dsf-59.9
> >      I: Retrieving tar 1.29b-1.1
> >      I: Validating tar 1.29b-1.1
> >      I: Retrieving tzdata 2018i-0+deb9u1
> >      I: Validating tzdata 2018i-0+deb9u1
> >      I: Retrieving libustr-1.0-1 1.0.4-6
> >      I: Validating libustr-1.0-1 1.0.4-6
> >      I: Retrieving bsdutils 1:2.29.2-1+deb9u1
> >      I: Validating bsdutils 1:2.29.2-1+deb9u1
> >      I: Retrieving libblkid1 2.29.2-1+deb9u1
> >      I: Validating libblkid1 2.29.2-1+deb9u1
> >      I: Retrieving libfdisk1 2.29.2-1+deb9u1
> >      I: Validating libfdisk1 2.29.2-1+deb9u1
> >      I: Retrieving libmount1 2.29.2-1+deb9u1
> >      I: Validating libmount1 2.29.2-1+deb9u1
> >      I: Retrieving libsmartcols1 2.29.2-1+deb9u1
> >      I: Validating libsmartcols1 2.29.2-1+deb9u1
> >      I: Retrieving libuuid1 2.29.2-1+deb9u1
> >      I: Validating libuuid1 2.29.2-1+deb9u1
> >      I: Retrieving mount 2.29.2-1+deb9u1
> >      I: Validating mount 2.29.2-1+deb9u1
> >      I: Retrieving util-linux 2.29.2-1+deb9u1
> >      I: Validating util-linux 2.29.2-1+deb9u1
> >      I: Retrieving liblzma5 5.2.2-1.2+b1
> >      I: Validating liblzma5 5.2.2-1.2+b1
> >      I: Retrieving zlib1g 1:1.2.8.dfsg-5
> >      I: Validating zlib1g 1:1.2.8.dfsg-5
> >      I: Chosen extractor for .deb packages: dpkg-deb
> >      I: Extracting libacl1...
> >      I: Extracting libattr1...
> >      I: Extracting libaudit-common...
> >      I: Extracting libaudit1...
> >      I: Extracting base-files...
> >      I: Extracting base-passwd...
> >      I: Extracting bash...
> >      I: Extracting libbz2-1.0...
> >      I: Extracting libdebconfclient0...
> >      I: Extracting coreutils...
> >      I: Extracting dash...
> >      I: Extracting libdb5.3...
> >      I: Extracting debconf...
> >      I: Extracting debianutils...
> >      I: Extracting diffutils...
> >      I: Extracting dpkg...
> >      I: Extracting e2fslibs...
> >      I: Extracting e2fsprogs...
> >      I: Extracting libcomerr2...
> >      I: Extracting libss2...
> >      I: Extracting findutils...
> >      I: Extracting gcc-6-base...
> >      I: Extracting libgcc1...
> >      I: Extracting libc-bin...
> >      I: Extracting libc6...
> >      I: Extracting multiarch-support...
> >      I: Extracting grep...
> >      I: Extracting gzip...
> >      I: Extracting hostname...
> >      I: Extracting init-system-helpers...
> >      I: Extracting libcap-ng0...
> >      I: Extracting libgcrypt20...
> >      I: Extracting libgpg-error0...
> >      I: Extracting libselinux1...
> >      I: Extracting libsemanage-common...
> >      I: Extracting libsemanage1...
> >      I: Extracting libsepol1...
> >      I: Extracting lsb-base...
> >      I: Extracting liblz4-1...
> >      I: Extracting mawk...
> >      I: Extracting libncursesw5...
> >      I: Extracting libtinfo5...
> >      I: Extracting ncurses-base...
> >      I: Extracting ncurses-bin...
> >      I: Extracting libpam-modules...
> >      I: Extracting libpam-modules-bin...
> >      I: Extracting libpam-runtime...
> >      I: Extracting libpam0g...
> >      I: Extracting libpcre3...
> >      I: Extracting perl-base...
> >      I: Extracting sed...
> >      I: Extracting sensible-utils...
> >      I: Extracting login...
> >      I: Extracting passwd...
> >      I: Extracting libsystemd0...
> >      I: Extracting libudev1...
> >      I: Extracting sysvinit-utils...
> >      I: Extracting tar...
> >      I: Extracting tzdata...
> >      I: Extracting libustr-1.0-1...
> >      I: Extracting bsdutils...
> >      I: Extracting libblkid1...
> >      I: Extracting libfdisk1...
> >      I: Extracting libmount1...
> >      I: Extracting libsmartcols1...
> >      I: Extracting libuuid1...
> >      I: Extracting mount...
> >      I: Extracting util-linux...
> >      I: Extracting liblzma5...
> >      I: Extracting zlib1g...
> >      I: Running command: chroot /work/build/tmp/work/cip-core-
> > armhf/isar-bootstrap-target/rootfs /debootstrap/debootstrap --
> > second-stage
> >      chroot: failed to run command ?/debootstrap/debootstrap?: No
> > such file or directory
> >      WARNING: exit code 127 from a shell command.
> >      ERROR: Function failed: do_bootstrap (log file is located at
> > /work/build/tmp/work/cip-core-armhf/isar-bootstrap-
> > target/temp/log.do_bootstrap.316)
> > 
> 
> Looping in isar-users and Claudius. I've no idea why debootstrap
> should stumble here, apparently over its own feet.

Well I would assume that it is an issue with your binfmt configuration
if '/work/build/tmp/work/cip-core-armhf/isar-bootstrap-
target/rootfs/debootstrap/deboostrap' exists.

regards,
Claudius

> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
> 

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-18  8:42     ` [cip-dev] CIP IRC weekly meeting today Christian Storm
@ 2019-03-18  9:14       ` akihiro27.suzuki at toshiba.co.jp
  2019-03-18 10:27         ` Christian Storm
  0 siblings, 1 reply; 40+ messages in thread
From: akihiro27.suzuki at toshiba.co.jp @ 2019-03-18  9:14 UTC (permalink / raw)
  To: cip-dev

Hi Christian,

> > > [Note] we are planning to develop the SWUpdate demo using ISAR, any
> > > advice or news about how to build SWUpdate on ISAR with the right
> > > U-Boot environment?
> > >
> > > - Regarding SWUpdate we hit an issue that we had not expected
> > > before. Suzuki-san was trying to update the standard BBB debian
> > > image (or a yocto-made one), but there were many warnings about
> > > orphan nodes etc. After some investigation the reason seems to be
> > > that the rootfs is modified during the first boot (or something like
> > > that). This is probably one of the biggest problems with updating
> > > images instead of files.
> >
> > Christian, any remarks?
> 
> Hm, did you check that you didn't flash the filesystem you have
> currently booted, i.e., are you overwriting the currently running
> root filesystem? I have seen such errors when I did this by accident.
I mounted rootfs with read-only.
I checked the difference of the rootfs image between before boot and after boot,
and at least the number of mounts had changed.

I attached following log files. I think that 0x434 is a mount count.

    mmcblk1p2-1-2.diff: The difference of rootfs image between 1st boot and 2nd boot
    mmcblk1p2-2-3.diff: The difference of rootfs image between 2nd boot and 3rd boot

Do you have some example of A/B update with binary delta update?

BTW, the warning message after binary delta update was as follows:

    EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm init: deleted inode referenced: 5040
    EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm init: deleted inode referenced: 5040
    EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
    EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
    EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
    EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
    EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
    EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
    EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
    EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833

Best regards,
Suzuki


> -----Original Message-----
> From: cip-dev-bounces at lists.cip-project.org
> [mailto:cip-dev-bounces at lists.cip-project.org] On Behalf Of Christian
> Storm
> Sent: Monday, March 18, 2019 5:42 PM
> To: Jan Kiszka <jan.kiszka@siemens.com>
> Cc: SZ.Lin at moxa.com; cip-dev at lists.cip-project.org
> Subject: Re: [cip-dev] CIP IRC weekly meeting today
> 
> Hi,
> 
> > > [Note] we are planning to develop the SWUpdate demo using ISAR, any
> > > advice or news about how to build SWUpdate on ISAR with the right
> > > U-Boot environment?
> > >
> > > - Regarding SWUpdate we hit an issue that we had not expected
> > > before. Suzuki-san was trying to update the standard BBB debian
> > > image (or a yocto-made one), but there were many warnings about
> > > orphan nodes etc. After some investigation the reason seems to be
> > > that the rootfs is modified during the first boot (or something like
> > > that). This is probably one of the biggest problems with updating
> > > images instead of files.
> >
> > Christian, any remarks?
> 
> Hm, did you check that you didn't flash the filesystem you have
> currently booted, i.e., are you overwriting the currently running
> root filesystem? I have seen such errors when I did this by accident.
> 
> Kind regards,
>    Christian
> 
> --
> Dr. Christian Storm
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Otto-Hahn-Ring 6, 81739 M?nchen, Germany
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mmcblk1p2-1-2.diff
Type: application/octet-stream
Size: 20959 bytes
Desc: mmcblk1p2-1-2.diff
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20190318/96c49ba5/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mmcblk1p2-2-3.diff
Type: application/octet-stream
Size: 7953 bytes
Desc: mmcblk1p2-2-3.diff
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20190318/96c49ba5/attachment-0003.obj>

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error
  2019-03-18  9:11             ` Claudius Heine
@ 2019-03-18  9:39               ` Jan Kiszka
  2019-03-18 10:14                 ` akihiro27.suzuki at toshiba.co.jp
  0 siblings, 1 reply; 40+ messages in thread
From: Jan Kiszka @ 2019-03-18  9:39 UTC (permalink / raw)
  To: cip-dev

On 18.03.19 10:11, Claudius Heine wrote:
> Hi,
> 
> On Mon, 2019-03-18 at 10:05 +0100, [ext] Jan Kiszka wrote:
>> On 18.03.19 02:42, akihiro27.suzuki at toshiba.co.jp wrote:
>>> Hi Jan,
>>>
>>>> Were you building natively on Debian or inside the kas container?
>>> I was executing following commands according to the README.md at
>>> isar-cip-core,
>>> so I think I was building inside the kas container.
>>>
>>>       $ wget
>>> https://raw.githubusercontent.com/siemens/kas/master/kas-docker
>>>       $ chmod a+x kas-docker
>>>       $ sudo ./kas-docker --isar build kas.yml:board-bbb.yml
>>>
>>> The error is as follows (from log.do_bootstrap of isar-bootstrap-
>>> target):
>>>
>>>       DEBUG: Executing shell function do_bootstrap
>>>       I: Running command: debootstrap --arch armhf --foreign --
>>> verbose --variant=minbase --include=locales --
>>> components=main,contrib,non-free stretch /work/build/tmp/work/cip-
>>> core-armhf/isar-bootstrap-target/rootfs
>>> http://ftp.de.debian.org/debian
>>>       I: Retrieving InRelease
>>>       I: Retrieving Release
>>>       I: Retrieving Release.gpg
>>>       I: Checking Release signature
>>>       I: Valid Release signature (key id
>>> 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500)
>>>       I: Retrieving Packages
>>>       I: Validating Packages
>>>       I: Retrieving Packages
>>>       I: Validating Packages
>>>       I: Retrieving Packages
>>>       I: Validating Packages
>>>       I: Resolving dependencies of required packages...
>>>       I: Resolving dependencies of base packages...
>>>       I: Found additional required dependencies: libaudit1 libaudit-
>>> common libbz2-1.0 libcap-ng0 libdb5.3 libdebconfclient0 libgcrypt20
>>> libgpg-error0 liblz4-1 libncursesw5 libsemanage1 libsemanage-common
>>> libsystemd0 libudev1 libustr-1.0-1
>>>       I: Found additional base dependencies: adduser debian-archive-
>>> keyring gpgv libapt-pkg5.0 libc-l10n libstdc++6
>>>       I: Checking component main on http://ftp.de.debian.org/debian.
>>> ..
>>>       I: Retrieving libacl1 2.2.52-3+b1
>>>       I: Validating libacl1 2.2.52-3+b1
>>>       I: Retrieving adduser 3.115
>>>       I: Validating adduser 3.115
>>>       I: Retrieving apt 1.4.9
>>>       I: Validating apt 1.4.9
>>>       I: Retrieving libapt-pkg5.0 1.4.9
>>>       I: Validating libapt-pkg5.0 1.4.9
>>>       I: Retrieving libattr1 1:2.4.47-2+b2
>>>       I: Validating libattr1 1:2.4.47-2+b2
>>>       I: Retrieving libaudit-common 1:2.6.7-2
>>>       I: Validating libaudit-common 1:2.6.7-2
>>>       I: Retrieving libaudit1 1:2.6.7-2
>>>       I: Validating libaudit1 1:2.6.7-2
>>>       I: Retrieving base-files 9.9+deb9u8
>>>       I: Validating base-files 9.9+deb9u8
>>>       I: Retrieving base-passwd 3.5.43
>>>       I: Validating base-passwd 3.5.43
>>>       I: Retrieving bash 4.4-5
>>>       I: Validating bash 4.4-5
>>>       I: Retrieving libbz2-1.0 1.0.6-8.1
>>>       I: Validating libbz2-1.0 1.0.6-8.1
>>>       I: Retrieving libdebconfclient0 0.227
>>>       I: Validating libdebconfclient0 0.227
>>>       I: Retrieving coreutils 8.26-3
>>>       I: Validating coreutils 8.26-3
>>>       I: Retrieving dash 0.5.8-2.4
>>>       I: Validating dash 0.5.8-2.4
>>>       I: Retrieving libdb5.3 5.3.28-12+deb9u1
>>>       I: Validating libdb5.3 5.3.28-12+deb9u1
>>>       I: Retrieving debconf 1.5.61
>>>       I: Validating debconf 1.5.61
>>>       I: Retrieving debian-archive-keyring 2017.5
>>>       I: Validating debian-archive-keyring 2017.5
>>>       I: Retrieving debianutils 4.8.1.1
>>>       I: Validating debianutils 4.8.1.1
>>>       I: Retrieving diffutils 1:3.5-3
>>>       I: Validating diffutils 1:3.5-3
>>>       I: Retrieving dpkg 1.18.25
>>>       I: Validating dpkg 1.18.25
>>>       I: Retrieving e2fslibs 1.43.4-2
>>>       I: Validating e2fslibs 1.43.4-2
>>>       I: Retrieving e2fsprogs 1.43.4-2
>>>       I: Validating e2fsprogs 1.43.4-2
>>>       I: Retrieving libcomerr2 1.43.4-2
>>>       I: Validating libcomerr2 1.43.4-2
>>>       I: Retrieving libss2 1.43.4-2
>>>       I: Validating libss2 1.43.4-2
>>>       I: Retrieving findutils 4.6.0+git+20161106-2
>>>       I: Validating findutils 4.6.0+git+20161106-2
>>>       I: Retrieving gcc-6-base 6.3.0-18+deb9u1
>>>       I: Validating gcc-6-base 6.3.0-18+deb9u1
>>>       I: Retrieving libgcc1 1:6.3.0-18+deb9u1
>>>       I: Validating libgcc1 1:6.3.0-18+deb9u1
>>>       I: Retrieving libstdc++6 6.3.0-18+deb9u1
>>>       I: Validating libstdc++6 6.3.0-18+deb9u1
>>>       I: Retrieving libc-bin 2.24-11+deb9u4
>>>       I: Validating libc-bin 2.24-11+deb9u4
>>>       I: Retrieving libc-l10n 2.24-11+deb9u4
>>>       I: Validating libc-l10n 2.24-11+deb9u4
>>>       I: Retrieving libc6 2.24-11+deb9u4
>>>       I: Validating libc6 2.24-11+deb9u4
>>>       I: Retrieving locales 2.24-11+deb9u4
>>>       I: Validating locales 2.24-11+deb9u4
>>>       I: Retrieving multiarch-support 2.24-11+deb9u4
>>>       I: Validating multiarch-support 2.24-11+deb9u4
>>>       I: Retrieving gpgv 2.1.18-8~deb9u4
>>>       I: Validating gpgv 2.1.18-8~deb9u4
>>>       I: Retrieving grep 2.27-2
>>>       I: Validating grep 2.27-2
>>>       I: Retrieving gzip 1.6-5+b1
>>>       I: Validating gzip 1.6-5+b1
>>>       I: Retrieving hostname 3.18+b1
>>>       I: Validating hostname 3.18+b1
>>>       I: Retrieving init-system-helpers 1.48
>>>       I: Validating init-system-helpers 1.48
>>>       I: Retrieving libcap-ng0 0.7.7-3+b1
>>>       I: Validating libcap-ng0 0.7.7-3+b1
>>>       I: Retrieving libgcrypt20 1.7.6-2+deb9u3
>>>       I: Validating libgcrypt20 1.7.6-2+deb9u3
>>>       I: Retrieving libgpg-error0 1.26-2
>>>       I: Validating libgpg-error0 1.26-2
>>>       I: Retrieving libselinux1 2.6-3+b3
>>>       I: Validating libselinux1 2.6-3+b3
>>>       I: Retrieving libsemanage-common 2.6-2
>>>       I: Validating libsemanage-common 2.6-2
>>>       I: Retrieving libsemanage1 2.6-2
>>>       I: Validating libsemanage1 2.6-2
>>>       I: Retrieving libsepol1 2.6-2
>>>       I: Validating libsepol1 2.6-2
>>>       I: Retrieving lsb-base 9.20161125
>>>       I: Validating lsb-base 9.20161125
>>>       I: Retrieving liblz4-1 0.0~r131-2+b1
>>>       I: Validating liblz4-1 0.0~r131-2+b1
>>>       I: Retrieving mawk 1.3.3-17+b3
>>>       I: Validating mawk 1.3.3-17+b3
>>>       I: Retrieving libncursesw5 6.0+20161126-1+deb9u2
>>>       I: Validating libncursesw5 6.0+20161126-1+deb9u2
>>>       I: Retrieving libtinfo5 6.0+20161126-1+deb9u2
>>>       I: Validating libtinfo5 6.0+20161126-1+deb9u2
>>>       I: Retrieving ncurses-base 6.0+20161126-1+deb9u2
>>>       I: Validating ncurses-base 6.0+20161126-1+deb9u2
>>>       I: Retrieving ncurses-bin 6.0+20161126-1+deb9u2
>>>       I: Validating ncurses-bin 6.0+20161126-1+deb9u2
>>>       I: Retrieving libpam-modules 1.1.8-3.6
>>>       I: Validating libpam-modules 1.1.8-3.6
>>>       I: Retrieving libpam-modules-bin 1.1.8-3.6
>>>       I: Validating libpam-modules-bin 1.1.8-3.6
>>>       I: Retrieving libpam-runtime 1.1.8-3.6
>>>       I: Validating libpam-runtime 1.1.8-3.6
>>>       I: Retrieving libpam0g 1.1.8-3.6
>>>       I: Validating libpam0g 1.1.8-3.6
>>>       I: Retrieving libpcre3 2:8.39-3
>>>       I: Validating libpcre3 2:8.39-3
>>>       I: Retrieving perl-base 5.24.1-3+deb9u5
>>>       I: Validating perl-base 5.24.1-3+deb9u5
>>>       I: Retrieving sed 4.4-1
>>>       I: Validating sed 4.4-1
>>>       I: Retrieving sensible-utils 0.0.9+deb9u1
>>>       I: Validating sensible-utils 0.0.9+deb9u1
>>>       I: Retrieving login 1:4.4-4.1
>>>       I: Validating login 1:4.4-4.1
>>>       I: Retrieving passwd 1:4.4-4.1
>>>       I: Validating passwd 1:4.4-4.1
>>>       I: Retrieving libsystemd0 232-25+deb9u8
>>>       I: Validating libsystemd0 232-25+deb9u8
>>>       I: Retrieving libudev1 232-25+deb9u8
>>>       I: Validating libudev1 232-25+deb9u8
>>>       I: Retrieving sysvinit-utils 2.88dsf-59.9
>>>       I: Validating sysvinit-utils 2.88dsf-59.9
>>>       I: Retrieving tar 1.29b-1.1
>>>       I: Validating tar 1.29b-1.1
>>>       I: Retrieving tzdata 2018i-0+deb9u1
>>>       I: Validating tzdata 2018i-0+deb9u1
>>>       I: Retrieving libustr-1.0-1 1.0.4-6
>>>       I: Validating libustr-1.0-1 1.0.4-6
>>>       I: Retrieving bsdutils 1:2.29.2-1+deb9u1
>>>       I: Validating bsdutils 1:2.29.2-1+deb9u1
>>>       I: Retrieving libblkid1 2.29.2-1+deb9u1
>>>       I: Validating libblkid1 2.29.2-1+deb9u1
>>>       I: Retrieving libfdisk1 2.29.2-1+deb9u1
>>>       I: Validating libfdisk1 2.29.2-1+deb9u1
>>>       I: Retrieving libmount1 2.29.2-1+deb9u1
>>>       I: Validating libmount1 2.29.2-1+deb9u1
>>>       I: Retrieving libsmartcols1 2.29.2-1+deb9u1
>>>       I: Validating libsmartcols1 2.29.2-1+deb9u1
>>>       I: Retrieving libuuid1 2.29.2-1+deb9u1
>>>       I: Validating libuuid1 2.29.2-1+deb9u1
>>>       I: Retrieving mount 2.29.2-1+deb9u1
>>>       I: Validating mount 2.29.2-1+deb9u1
>>>       I: Retrieving util-linux 2.29.2-1+deb9u1
>>>       I: Validating util-linux 2.29.2-1+deb9u1
>>>       I: Retrieving liblzma5 5.2.2-1.2+b1
>>>       I: Validating liblzma5 5.2.2-1.2+b1
>>>       I: Retrieving zlib1g 1:1.2.8.dfsg-5
>>>       I: Validating zlib1g 1:1.2.8.dfsg-5
>>>       I: Chosen extractor for .deb packages: dpkg-deb
>>>       I: Extracting libacl1...
>>>       I: Extracting libattr1...
>>>       I: Extracting libaudit-common...
>>>       I: Extracting libaudit1...
>>>       I: Extracting base-files...
>>>       I: Extracting base-passwd...
>>>       I: Extracting bash...
>>>       I: Extracting libbz2-1.0...
>>>       I: Extracting libdebconfclient0...
>>>       I: Extracting coreutils...
>>>       I: Extracting dash...
>>>       I: Extracting libdb5.3...
>>>       I: Extracting debconf...
>>>       I: Extracting debianutils...
>>>       I: Extracting diffutils...
>>>       I: Extracting dpkg...
>>>       I: Extracting e2fslibs...
>>>       I: Extracting e2fsprogs...
>>>       I: Extracting libcomerr2...
>>>       I: Extracting libss2...
>>>       I: Extracting findutils...
>>>       I: Extracting gcc-6-base...
>>>       I: Extracting libgcc1...
>>>       I: Extracting libc-bin...
>>>       I: Extracting libc6...
>>>       I: Extracting multiarch-support...
>>>       I: Extracting grep...
>>>       I: Extracting gzip...
>>>       I: Extracting hostname...
>>>       I: Extracting init-system-helpers...
>>>       I: Extracting libcap-ng0...
>>>       I: Extracting libgcrypt20...
>>>       I: Extracting libgpg-error0...
>>>       I: Extracting libselinux1...
>>>       I: Extracting libsemanage-common...
>>>       I: Extracting libsemanage1...
>>>       I: Extracting libsepol1...
>>>       I: Extracting lsb-base...
>>>       I: Extracting liblz4-1...
>>>       I: Extracting mawk...
>>>       I: Extracting libncursesw5...
>>>       I: Extracting libtinfo5...
>>>       I: Extracting ncurses-base...
>>>       I: Extracting ncurses-bin...
>>>       I: Extracting libpam-modules...
>>>       I: Extracting libpam-modules-bin...
>>>       I: Extracting libpam-runtime...
>>>       I: Extracting libpam0g...
>>>       I: Extracting libpcre3...
>>>       I: Extracting perl-base...
>>>       I: Extracting sed...
>>>       I: Extracting sensible-utils...
>>>       I: Extracting login...
>>>       I: Extracting passwd...
>>>       I: Extracting libsystemd0...
>>>       I: Extracting libudev1...
>>>       I: Extracting sysvinit-utils...
>>>       I: Extracting tar...
>>>       I: Extracting tzdata...
>>>       I: Extracting libustr-1.0-1...
>>>       I: Extracting bsdutils...
>>>       I: Extracting libblkid1...
>>>       I: Extracting libfdisk1...
>>>       I: Extracting libmount1...
>>>       I: Extracting libsmartcols1...
>>>       I: Extracting libuuid1...
>>>       I: Extracting mount...
>>>       I: Extracting util-linux...
>>>       I: Extracting liblzma5...
>>>       I: Extracting zlib1g...
>>>       I: Running command: chroot /work/build/tmp/work/cip-core-
>>> armhf/isar-bootstrap-target/rootfs /debootstrap/debootstrap --
>>> second-stage
>>>       chroot: failed to run command ?/debootstrap/debootstrap?: No
>>> such file or directory
>>>       WARNING: exit code 127 from a shell command.
>>>       ERROR: Function failed: do_bootstrap (log file is located at
>>> /work/build/tmp/work/cip-core-armhf/isar-bootstrap-
>>> target/temp/log.do_bootstrap.316)
>>>
>>
>> Looping in isar-users and Claudius. I've no idea why debootstrap
>> should stumble here, apparently over its own feet.
> 
> Well I would assume that it is an issue with your binfmt configuration
> if '/work/build/tmp/work/cip-core-armhf/isar-bootstrap-
> target/rootfs/debootstrap/deboostrap' exists.
> 

That's a good hint: Suzuki-san, could you check if binfmt_misc is available as 
kernel feature/module on that machine? There may also be some warning during the 
container startup.

If that should have been the reason, we likely need a better detection in Isar, 
before the user runs into this non-obvious error message.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error
  2019-03-18  9:39               ` [cip-dev] debootrap error Jan Kiszka
@ 2019-03-18 10:14                 ` akihiro27.suzuki at toshiba.co.jp
  2019-03-18 10:17                   ` Claudius Heine
  0 siblings, 1 reply; 40+ messages in thread
From: akihiro27.suzuki at toshiba.co.jp @ 2019-03-18 10:14 UTC (permalink / raw)
  To: cip-dev

Hi,

> That's a good hint: Suzuki-san, could you check if binfmt_misc is
> available as
> kernel feature/module on that machine? There may also be some warning
> during the
> container startup.
I checked it and maybe it is available.

    $ mount | grep binfmt
    systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=18804)
    binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
    $ lsmod | grep binfmt
    binfmt_misc            20480  1
    $ cat /boot/config-4.15.0-46-generic  | grep BINFMT
    CONFIG_BINFMT_ELF=y
    CONFIG_COMPAT_BINFMT_ELF=y
    CONFIG_BINFMT_SCRIPT=y
    CONFIG_BINFMT_MISC=m
    $ ls /proc/sys/fs/binfmt_misc/
    python2.7     qemu-armeb       qemu-mips64      qemu-ppc64le  qemu-sparc        status
    python3.5     qemu-cris        qemu-mips64el    qemu-riscv32  qemu-sparc32plus
    python3.6     qemu-hppa        qemu-mipsel      qemu-riscv64  qemu-sparc64
    qemu-aarch64  qemu-m68k        qemu-ppc         qemu-s390x    qemu-xtensa
    qemu-alpha    qemu-microblaze  qemu-ppc64       qemu-sh4      qemu-xtensaeb
    qemu-arm      qemu-mips        qemu-ppc64abi32  qemu-sh4eb    register
    $ cat /proc/sys/fs/binfmt_misc/status
    enabled

The startup message is as follows:

    $ ./kas-docker --isar build kas.yml:board-bbb.yml
    2019-03-18 10:08:58 - INFO     - kas 0.20.1 started
    2019-03-18 10:08:58 - INFO     - /repo$ git rev-parse --show-toplevel
    2019-03-18 10:08:58 - INFO     - /repo$ git rev-parse --show-toplevel
    2019-03-18 10:08:58 - INFO     - /repo$ git rev-parse --show-toplevel
    2019-03-18 10:08:58 - INFO     - Using /repo as root for repository cip-core
    2019-03-18 10:08:58 - INFO     - /work$ git clone -q https://github.com/ilbers/isar /work/isar
    2019-03-18 10:09:02 - INFO     - Repository isar cloned
    2019-03-18 10:09:02 - INFO     - /repo$ git rev-parse --show-toplevel
    2019-03-18 10:09:02 - INFO     - Using /repo as root for repository cip-core
    2019-03-18 10:09:02 - INFO     - /work/isar$ git status -s
    2019-03-18 10:09:02 - INFO     - /work/isar$ git rev-parse --verify HEAD
    2019-03-18 10:09:02 - INFO     - 6c5db020b9b837d7b0ce63bfc719f9192e725f26
    2019-03-18 10:09:02 - INFO     - /work/isar$ git checkout -q d226c29d24f791a15fbdce9c354eb189a1003dcc
    2019-03-18 10:09:02 - INFO     - /repo$ git rev-parse --show-toplevel
    2019-03-18 10:09:02 - INFO     - Using /repo as root for repository cip-core
    2019-03-18 10:09:02 - INFO     - /work/isar$ /tmp/tmpyscgo7lw /work/build
    2019-03-18 10:09:02 - INFO     - /repo$ git rev-parse --show-toplevel
    2019-03-18 10:09:02 - INFO     - Using /repo as root for repository cip-core
    2019-03-18 10:09:02 - INFO     - /repo$ git rev-parse --show-toplevel
    2019-03-18 10:09:02 - INFO     - Using /repo as root for repository cip-core
    2019-03-18 10:09:02 - INFO     - /work/build$ /work/isar/bitbake/bin/bitbake -k -c build cip-core-image
    Parsing recipes: 100% |################################################################################
    ...(snip)...

Best regards,
Suzuki


> -----Original Message-----
> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
> Sent: Monday, March 18, 2019 6:39 PM
> To: Claudius Heine <claudius.heine.ext@siemens.com>; suzuki akihiro(?
> ? ?? ????????) <akihiro27.suzuki@toshiba.co.jp>;
> isar-users <isar-users@googlegroups.com>; Claudius Heine <ch@denx.de>
> Cc: sangorrin daniel(????? ???? ????????)
> <daniel.sangorrin@toshiba.co.jp>; cip-dev at lists.cip-project.org
> Subject: Re: debootrap error
> 
> On 18.03.19 10:11, Claudius Heine wrote:
> > Hi,
> >
> > On Mon, 2019-03-18 at 10:05 +0100, [ext] Jan Kiszka wrote:
> >> On 18.03.19 02:42, akihiro27.suzuki at toshiba.co.jp wrote:
> >>> Hi Jan,
> >>>
> >>>> Were you building natively on Debian or inside the kas container?
> >>> I was executing following commands according to the README.md at
> >>> isar-cip-core,
> >>> so I think I was building inside the kas container.
> >>>
> >>>       $ wget
> >>> https://raw.githubusercontent.com/siemens/kas/master/kas-docker
> >>>       $ chmod a+x kas-docker
> >>>       $ sudo ./kas-docker --isar build kas.yml:board-bbb.yml
> >>>
> >>> The error is as follows (from log.do_bootstrap of isar-bootstrap-
> >>> target):
> >>>
> >>>       DEBUG: Executing shell function do_bootstrap
> >>>       I: Running command: debootstrap --arch armhf --foreign --
> >>> verbose --variant=minbase --include=locales --
> >>> components=main,contrib,non-free stretch /work/build/tmp/work/cip-
> >>> core-armhf/isar-bootstrap-target/rootfs
> >>> http://ftp.de.debian.org/debian
> >>>       I: Retrieving InRelease
> >>>       I: Retrieving Release
> >>>       I: Retrieving Release.gpg
> >>>       I: Checking Release signature
> >>>       I: Valid Release signature (key id
> >>> 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500)
> >>>       I: Retrieving Packages
> >>>       I: Validating Packages
> >>>       I: Retrieving Packages
> >>>       I: Validating Packages
> >>>       I: Retrieving Packages
> >>>       I: Validating Packages
> >>>       I: Resolving dependencies of required packages...
> >>>       I: Resolving dependencies of base packages...
> >>>       I: Found additional required dependencies: libaudit1
> libaudit-
> >>> common libbz2-1.0 libcap-ng0 libdb5.3 libdebconfclient0 libgcrypt20
> >>> libgpg-error0 liblz4-1 libncursesw5 libsemanage1 libsemanage-common
> >>> libsystemd0 libudev1 libustr-1.0-1
> >>>       I: Found additional base dependencies: adduser
> debian-archive-
> >>> keyring gpgv libapt-pkg5.0 libc-l10n libstdc++6
> >>>       I: Checking component main on
> http://ftp.de.debian.org/debian.
> >>> ..
> >>>       I: Retrieving libacl1 2.2.52-3+b1
> >>>       I: Validating libacl1 2.2.52-3+b1
> >>>       I: Retrieving adduser 3.115
> >>>       I: Validating adduser 3.115
> >>>       I: Retrieving apt 1.4.9
> >>>       I: Validating apt 1.4.9
> >>>       I: Retrieving libapt-pkg5.0 1.4.9
> >>>       I: Validating libapt-pkg5.0 1.4.9
> >>>       I: Retrieving libattr1 1:2.4.47-2+b2
> >>>       I: Validating libattr1 1:2.4.47-2+b2
> >>>       I: Retrieving libaudit-common 1:2.6.7-2
> >>>       I: Validating libaudit-common 1:2.6.7-2
> >>>       I: Retrieving libaudit1 1:2.6.7-2
> >>>       I: Validating libaudit1 1:2.6.7-2
> >>>       I: Retrieving base-files 9.9+deb9u8
> >>>       I: Validating base-files 9.9+deb9u8
> >>>       I: Retrieving base-passwd 3.5.43
> >>>       I: Validating base-passwd 3.5.43
> >>>       I: Retrieving bash 4.4-5
> >>>       I: Validating bash 4.4-5
> >>>       I: Retrieving libbz2-1.0 1.0.6-8.1
> >>>       I: Validating libbz2-1.0 1.0.6-8.1
> >>>       I: Retrieving libdebconfclient0 0.227
> >>>       I: Validating libdebconfclient0 0.227
> >>>       I: Retrieving coreutils 8.26-3
> >>>       I: Validating coreutils 8.26-3
> >>>       I: Retrieving dash 0.5.8-2.4
> >>>       I: Validating dash 0.5.8-2.4
> >>>       I: Retrieving libdb5.3 5.3.28-12+deb9u1
> >>>       I: Validating libdb5.3 5.3.28-12+deb9u1
> >>>       I: Retrieving debconf 1.5.61
> >>>       I: Validating debconf 1.5.61
> >>>       I: Retrieving debian-archive-keyring 2017.5
> >>>       I: Validating debian-archive-keyring 2017.5
> >>>       I: Retrieving debianutils 4.8.1.1
> >>>       I: Validating debianutils 4.8.1.1
> >>>       I: Retrieving diffutils 1:3.5-3
> >>>       I: Validating diffutils 1:3.5-3
> >>>       I: Retrieving dpkg 1.18.25
> >>>       I: Validating dpkg 1.18.25
> >>>       I: Retrieving e2fslibs 1.43.4-2
> >>>       I: Validating e2fslibs 1.43.4-2
> >>>       I: Retrieving e2fsprogs 1.43.4-2
> >>>       I: Validating e2fsprogs 1.43.4-2
> >>>       I: Retrieving libcomerr2 1.43.4-2
> >>>       I: Validating libcomerr2 1.43.4-2
> >>>       I: Retrieving libss2 1.43.4-2
> >>>       I: Validating libss2 1.43.4-2
> >>>       I: Retrieving findutils 4.6.0+git+20161106-2
> >>>       I: Validating findutils 4.6.0+git+20161106-2
> >>>       I: Retrieving gcc-6-base 6.3.0-18+deb9u1
> >>>       I: Validating gcc-6-base 6.3.0-18+deb9u1
> >>>       I: Retrieving libgcc1 1:6.3.0-18+deb9u1
> >>>       I: Validating libgcc1 1:6.3.0-18+deb9u1
> >>>       I: Retrieving libstdc++6 6.3.0-18+deb9u1
> >>>       I: Validating libstdc++6 6.3.0-18+deb9u1
> >>>       I: Retrieving libc-bin 2.24-11+deb9u4
> >>>       I: Validating libc-bin 2.24-11+deb9u4
> >>>       I: Retrieving libc-l10n 2.24-11+deb9u4
> >>>       I: Validating libc-l10n 2.24-11+deb9u4
> >>>       I: Retrieving libc6 2.24-11+deb9u4
> >>>       I: Validating libc6 2.24-11+deb9u4
> >>>       I: Retrieving locales 2.24-11+deb9u4
> >>>       I: Validating locales 2.24-11+deb9u4
> >>>       I: Retrieving multiarch-support 2.24-11+deb9u4
> >>>       I: Validating multiarch-support 2.24-11+deb9u4
> >>>       I: Retrieving gpgv 2.1.18-8~deb9u4
> >>>       I: Validating gpgv 2.1.18-8~deb9u4
> >>>       I: Retrieving grep 2.27-2
> >>>       I: Validating grep 2.27-2
> >>>       I: Retrieving gzip 1.6-5+b1
> >>>       I: Validating gzip 1.6-5+b1
> >>>       I: Retrieving hostname 3.18+b1
> >>>       I: Validating hostname 3.18+b1
> >>>       I: Retrieving init-system-helpers 1.48
> >>>       I: Validating init-system-helpers 1.48
> >>>       I: Retrieving libcap-ng0 0.7.7-3+b1
> >>>       I: Validating libcap-ng0 0.7.7-3+b1
> >>>       I: Retrieving libgcrypt20 1.7.6-2+deb9u3
> >>>       I: Validating libgcrypt20 1.7.6-2+deb9u3
> >>>       I: Retrieving libgpg-error0 1.26-2
> >>>       I: Validating libgpg-error0 1.26-2
> >>>       I: Retrieving libselinux1 2.6-3+b3
> >>>       I: Validating libselinux1 2.6-3+b3
> >>>       I: Retrieving libsemanage-common 2.6-2
> >>>       I: Validating libsemanage-common 2.6-2
> >>>       I: Retrieving libsemanage1 2.6-2
> >>>       I: Validating libsemanage1 2.6-2
> >>>       I: Retrieving libsepol1 2.6-2
> >>>       I: Validating libsepol1 2.6-2
> >>>       I: Retrieving lsb-base 9.20161125
> >>>       I: Validating lsb-base 9.20161125
> >>>       I: Retrieving liblz4-1 0.0~r131-2+b1
> >>>       I: Validating liblz4-1 0.0~r131-2+b1
> >>>       I: Retrieving mawk 1.3.3-17+b3
> >>>       I: Validating mawk 1.3.3-17+b3
> >>>       I: Retrieving libncursesw5 6.0+20161126-1+deb9u2
> >>>       I: Validating libncursesw5 6.0+20161126-1+deb9u2
> >>>       I: Retrieving libtinfo5 6.0+20161126-1+deb9u2
> >>>       I: Validating libtinfo5 6.0+20161126-1+deb9u2
> >>>       I: Retrieving ncurses-base 6.0+20161126-1+deb9u2
> >>>       I: Validating ncurses-base 6.0+20161126-1+deb9u2
> >>>       I: Retrieving ncurses-bin 6.0+20161126-1+deb9u2
> >>>       I: Validating ncurses-bin 6.0+20161126-1+deb9u2
> >>>       I: Retrieving libpam-modules 1.1.8-3.6
> >>>       I: Validating libpam-modules 1.1.8-3.6
> >>>       I: Retrieving libpam-modules-bin 1.1.8-3.6
> >>>       I: Validating libpam-modules-bin 1.1.8-3.6
> >>>       I: Retrieving libpam-runtime 1.1.8-3.6
> >>>       I: Validating libpam-runtime 1.1.8-3.6
> >>>       I: Retrieving libpam0g 1.1.8-3.6
> >>>       I: Validating libpam0g 1.1.8-3.6
> >>>       I: Retrieving libpcre3 2:8.39-3
> >>>       I: Validating libpcre3 2:8.39-3
> >>>       I: Retrieving perl-base 5.24.1-3+deb9u5
> >>>       I: Validating perl-base 5.24.1-3+deb9u5
> >>>       I: Retrieving sed 4.4-1
> >>>       I: Validating sed 4.4-1
> >>>       I: Retrieving sensible-utils 0.0.9+deb9u1
> >>>       I: Validating sensible-utils 0.0.9+deb9u1
> >>>       I: Retrieving login 1:4.4-4.1
> >>>       I: Validating login 1:4.4-4.1
> >>>       I: Retrieving passwd 1:4.4-4.1
> >>>       I: Validating passwd 1:4.4-4.1
> >>>       I: Retrieving libsystemd0 232-25+deb9u8
> >>>       I: Validating libsystemd0 232-25+deb9u8
> >>>       I: Retrieving libudev1 232-25+deb9u8
> >>>       I: Validating libudev1 232-25+deb9u8
> >>>       I: Retrieving sysvinit-utils 2.88dsf-59.9
> >>>       I: Validating sysvinit-utils 2.88dsf-59.9
> >>>       I: Retrieving tar 1.29b-1.1
> >>>       I: Validating tar 1.29b-1.1
> >>>       I: Retrieving tzdata 2018i-0+deb9u1
> >>>       I: Validating tzdata 2018i-0+deb9u1
> >>>       I: Retrieving libustr-1.0-1 1.0.4-6
> >>>       I: Validating libustr-1.0-1 1.0.4-6
> >>>       I: Retrieving bsdutils 1:2.29.2-1+deb9u1
> >>>       I: Validating bsdutils 1:2.29.2-1+deb9u1
> >>>       I: Retrieving libblkid1 2.29.2-1+deb9u1
> >>>       I: Validating libblkid1 2.29.2-1+deb9u1
> >>>       I: Retrieving libfdisk1 2.29.2-1+deb9u1
> >>>       I: Validating libfdisk1 2.29.2-1+deb9u1
> >>>       I: Retrieving libmount1 2.29.2-1+deb9u1
> >>>       I: Validating libmount1 2.29.2-1+deb9u1
> >>>       I: Retrieving libsmartcols1 2.29.2-1+deb9u1
> >>>       I: Validating libsmartcols1 2.29.2-1+deb9u1
> >>>       I: Retrieving libuuid1 2.29.2-1+deb9u1
> >>>       I: Validating libuuid1 2.29.2-1+deb9u1
> >>>       I: Retrieving mount 2.29.2-1+deb9u1
> >>>       I: Validating mount 2.29.2-1+deb9u1
> >>>       I: Retrieving util-linux 2.29.2-1+deb9u1
> >>>       I: Validating util-linux 2.29.2-1+deb9u1
> >>>       I: Retrieving liblzma5 5.2.2-1.2+b1
> >>>       I: Validating liblzma5 5.2.2-1.2+b1
> >>>       I: Retrieving zlib1g 1:1.2.8.dfsg-5
> >>>       I: Validating zlib1g 1:1.2.8.dfsg-5
> >>>       I: Chosen extractor for .deb packages: dpkg-deb
> >>>       I: Extracting libacl1...
> >>>       I: Extracting libattr1...
> >>>       I: Extracting libaudit-common...
> >>>       I: Extracting libaudit1...
> >>>       I: Extracting base-files...
> >>>       I: Extracting base-passwd...
> >>>       I: Extracting bash...
> >>>       I: Extracting libbz2-1.0...
> >>>       I: Extracting libdebconfclient0...
> >>>       I: Extracting coreutils...
> >>>       I: Extracting dash...
> >>>       I: Extracting libdb5.3...
> >>>       I: Extracting debconf...
> >>>       I: Extracting debianutils...
> >>>       I: Extracting diffutils...
> >>>       I: Extracting dpkg...
> >>>       I: Extracting e2fslibs...
> >>>       I: Extracting e2fsprogs...
> >>>       I: Extracting libcomerr2...
> >>>       I: Extracting libss2...
> >>>       I: Extracting findutils...
> >>>       I: Extracting gcc-6-base...
> >>>       I: Extracting libgcc1...
> >>>       I: Extracting libc-bin...
> >>>       I: Extracting libc6...
> >>>       I: Extracting multiarch-support...
> >>>       I: Extracting grep...
> >>>       I: Extracting gzip...
> >>>       I: Extracting hostname...
> >>>       I: Extracting init-system-helpers...
> >>>       I: Extracting libcap-ng0...
> >>>       I: Extracting libgcrypt20...
> >>>       I: Extracting libgpg-error0...
> >>>       I: Extracting libselinux1...
> >>>       I: Extracting libsemanage-common...
> >>>       I: Extracting libsemanage1...
> >>>       I: Extracting libsepol1...
> >>>       I: Extracting lsb-base...
> >>>       I: Extracting liblz4-1...
> >>>       I: Extracting mawk...
> >>>       I: Extracting libncursesw5...
> >>>       I: Extracting libtinfo5...
> >>>       I: Extracting ncurses-base...
> >>>       I: Extracting ncurses-bin...
> >>>       I: Extracting libpam-modules...
> >>>       I: Extracting libpam-modules-bin...
> >>>       I: Extracting libpam-runtime...
> >>>       I: Extracting libpam0g...
> >>>       I: Extracting libpcre3...
> >>>       I: Extracting perl-base...
> >>>       I: Extracting sed...
> >>>       I: Extracting sensible-utils...
> >>>       I: Extracting login...
> >>>       I: Extracting passwd...
> >>>       I: Extracting libsystemd0...
> >>>       I: Extracting libudev1...
> >>>       I: Extracting sysvinit-utils...
> >>>       I: Extracting tar...
> >>>       I: Extracting tzdata...
> >>>       I: Extracting libustr-1.0-1...
> >>>       I: Extracting bsdutils...
> >>>       I: Extracting libblkid1...
> >>>       I: Extracting libfdisk1...
> >>>       I: Extracting libmount1...
> >>>       I: Extracting libsmartcols1...
> >>>       I: Extracting libuuid1...
> >>>       I: Extracting mount...
> >>>       I: Extracting util-linux...
> >>>       I: Extracting liblzma5...
> >>>       I: Extracting zlib1g...
> >>>       I: Running command: chroot /work/build/tmp/work/cip-core-
> >>> armhf/isar-bootstrap-target/rootfs /debootstrap/debootstrap --
> >>> second-stage
> >>>       chroot: failed to run command ?/debootstrap/debootstrap?: No
> >>> such file or directory
> >>>       WARNING: exit code 127 from a shell command.
> >>>       ERROR: Function failed: do_bootstrap (log file is located at
> >>> /work/build/tmp/work/cip-core-armhf/isar-bootstrap-
> >>> target/temp/log.do_bootstrap.316)
> >>>
> >>
> >> Looping in isar-users and Claudius. I've no idea why debootstrap
> >> should stumble here, apparently over its own feet.
> >
> > Well I would assume that it is an issue with your binfmt configuration
> > if '/work/build/tmp/work/cip-core-armhf/isar-bootstrap-
> > target/rootfs/debootstrap/deboostrap' exists.
> >
> 
> That's a good hint: Suzuki-san, could you check if binfmt_misc is
> available as
> kernel feature/module on that machine? There may also be some warning
> during the
> container startup.
> 
> If that should have been the reason, we likely need a better detection
> in Isar,
> before the user runs into this non-obvious error message.
> 
> Jan
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error
  2019-03-18 10:14                 ` akihiro27.suzuki at toshiba.co.jp
@ 2019-03-18 10:17                   ` Claudius Heine
  2019-03-18 10:18                     ` Jan Kiszka
  0 siblings, 1 reply; 40+ messages in thread
From: Claudius Heine @ 2019-03-18 10:17 UTC (permalink / raw)
  To: cip-dev

Hi,,

On 18/03/2019 11.14, akihiro27.suzuki at toshiba.co.jp wrote:
> Hi,
> 
>> That's a good hint: Suzuki-san, could you check if binfmt_misc is
>> available as
>> kernel feature/module on that machine? There may also be some warning
>> during the
>> container startup.
> I checked it and maybe it is available.
> 
>      $ mount | grep binfmt
>      systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=18804)
>      binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
>      $ lsmod | grep binfmt
>      binfmt_misc            20480  1
>      $ cat /boot/config-4.15.0-46-generic  | grep BINFMT
>      CONFIG_BINFMT_ELF=y
>      CONFIG_COMPAT_BINFMT_ELF=y
>      CONFIG_BINFMT_SCRIPT=y
>      CONFIG_BINFMT_MISC=m
>      $ ls /proc/sys/fs/binfmt_misc/
>      python2.7     qemu-armeb       qemu-mips64      qemu-ppc64le  qemu-sparc        status
>      python3.5     qemu-cris        qemu-mips64el    qemu-riscv32  qemu-sparc32plus
>      python3.6     qemu-hppa        qemu-mipsel      qemu-riscv64  qemu-sparc64
>      qemu-aarch64  qemu-m68k        qemu-ppc         qemu-s390x    qemu-xtensa
>      qemu-alpha    qemu-microblaze  qemu-ppc64       qemu-sh4      qemu-xtensaeb
>      qemu-arm      qemu-mips        qemu-ppc64abi32  qemu-sh4eb    register
>      $ cat /proc/sys/fs/binfmt_misc/status
>      enabled

That is how my qemu-arm setting looks like. Do you have a different qemu 
path?

$ cat /proc/sys/fs/binfmt_misc/qemu-arm
enabled
interpreter /usr/bin/qemu-arm-static
flags: OCF
offset 0
magic 7f454c4601010100000000000000000002002800
mask ffffffffffffff00fffffffffffffffffeffffff

regards,
Claudius


> 
> The startup message is as follows:
> 
>      $ ./kas-docker --isar build kas.yml:board-bbb.yml
>      2019-03-18 10:08:58 - INFO     - kas 0.20.1 started
>      2019-03-18 10:08:58 - INFO     - /repo$ git rev-parse --show-toplevel
>      2019-03-18 10:08:58 - INFO     - /repo$ git rev-parse --show-toplevel
>      2019-03-18 10:08:58 - INFO     - /repo$ git rev-parse --show-toplevel
>      2019-03-18 10:08:58 - INFO     - Using /repo as root for repository cip-core
>      2019-03-18 10:08:58 - INFO     - /work$ git clone -q https://github.com/ilbers/isar /work/isar
>      2019-03-18 10:09:02 - INFO     - Repository isar cloned
>      2019-03-18 10:09:02 - INFO     - /repo$ git rev-parse --show-toplevel
>      2019-03-18 10:09:02 - INFO     - Using /repo as root for repository cip-core
>      2019-03-18 10:09:02 - INFO     - /work/isar$ git status -s
>      2019-03-18 10:09:02 - INFO     - /work/isar$ git rev-parse --verify HEAD
>      2019-03-18 10:09:02 - INFO     - 6c5db020b9b837d7b0ce63bfc719f9192e725f26
>      2019-03-18 10:09:02 - INFO     - /work/isar$ git checkout -q d226c29d24f791a15fbdce9c354eb189a1003dcc
>      2019-03-18 10:09:02 - INFO     - /repo$ git rev-parse --show-toplevel
>      2019-03-18 10:09:02 - INFO     - Using /repo as root for repository cip-core
>      2019-03-18 10:09:02 - INFO     - /work/isar$ /tmp/tmpyscgo7lw /work/build
>      2019-03-18 10:09:02 - INFO     - /repo$ git rev-parse --show-toplevel
>      2019-03-18 10:09:02 - INFO     - Using /repo as root for repository cip-core
>      2019-03-18 10:09:02 - INFO     - /repo$ git rev-parse --show-toplevel
>      2019-03-18 10:09:02 - INFO     - Using /repo as root for repository cip-core
>      2019-03-18 10:09:02 - INFO     - /work/build$ /work/isar/bitbake/bin/bitbake -k -c build cip-core-image
>      Parsing recipes: 100% |################################################################################
>      ...(snip)...
> 
> Best regards,
> Suzuki
> 
> 
>> -----Original Message-----
>> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
>> Sent: Monday, March 18, 2019 6:39 PM
>> To: Claudius Heine <claudius.heine.ext@siemens.com>; suzuki akihiro(?
>> ? ?? ????????) <akihiro27.suzuki@toshiba.co.jp>;
>> isar-users <isar-users@googlegroups.com>; Claudius Heine <ch@denx.de>
>> Cc: sangorrin daniel(????? ???? ????????)
>> <daniel.sangorrin@toshiba.co.jp>; cip-dev at lists.cip-project.org
>> Subject: Re: debootrap error
>>
>> On 18.03.19 10:11, Claudius Heine wrote:
>>> Hi,
>>>
>>> On Mon, 2019-03-18 at 10:05 +0100, [ext] Jan Kiszka wrote:
>>>> On 18.03.19 02:42, akihiro27.suzuki at toshiba.co.jp wrote:
>>>>> Hi Jan,
>>>>>
>>>>>> Were you building natively on Debian or inside the kas container?
>>>>> I was executing following commands according to the README.md at
>>>>> isar-cip-core,
>>>>> so I think I was building inside the kas container.
>>>>>
>>>>>        $ wget
>>>>> https://raw.githubusercontent.com/siemens/kas/master/kas-docker
>>>>>        $ chmod a+x kas-docker
>>>>>        $ sudo ./kas-docker --isar build kas.yml:board-bbb.yml
>>>>>
>>>>> The error is as follows (from log.do_bootstrap of isar-bootstrap-
>>>>> target):
>>>>>
>>>>>        DEBUG: Executing shell function do_bootstrap
>>>>>        I: Running command: debootstrap --arch armhf --foreign --
>>>>> verbose --variant=minbase --include=locales --
>>>>> components=main,contrib,non-free stretch /work/build/tmp/work/cip-
>>>>> core-armhf/isar-bootstrap-target/rootfs
>>>>> http://ftp.de.debian.org/debian
>>>>>        I: Retrieving InRelease
>>>>>        I: Retrieving Release
>>>>>        I: Retrieving Release.gpg
>>>>>        I: Checking Release signature
>>>>>        I: Valid Release signature (key id
>>>>> 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500)
>>>>>        I: Retrieving Packages
>>>>>        I: Validating Packages
>>>>>        I: Retrieving Packages
>>>>>        I: Validating Packages
>>>>>        I: Retrieving Packages
>>>>>        I: Validating Packages
>>>>>        I: Resolving dependencies of required packages...
>>>>>        I: Resolving dependencies of base packages...
>>>>>        I: Found additional required dependencies: libaudit1
>> libaudit-
>>>>> common libbz2-1.0 libcap-ng0 libdb5.3 libdebconfclient0 libgcrypt20
>>>>> libgpg-error0 liblz4-1 libncursesw5 libsemanage1 libsemanage-common
>>>>> libsystemd0 libudev1 libustr-1.0-1
>>>>>        I: Found additional base dependencies: adduser
>> debian-archive-
>>>>> keyring gpgv libapt-pkg5.0 libc-l10n libstdc++6
>>>>>        I: Checking component main on
>> http://ftp.de.debian.org/debian.
>>>>> ..
>>>>>        I: Retrieving libacl1 2.2.52-3+b1
>>>>>        I: Validating libacl1 2.2.52-3+b1
>>>>>        I: Retrieving adduser 3.115
>>>>>        I: Validating adduser 3.115
>>>>>        I: Retrieving apt 1.4.9
>>>>>        I: Validating apt 1.4.9
>>>>>        I: Retrieving libapt-pkg5.0 1.4.9
>>>>>        I: Validating libapt-pkg5.0 1.4.9
>>>>>        I: Retrieving libattr1 1:2.4.47-2+b2
>>>>>        I: Validating libattr1 1:2.4.47-2+b2
>>>>>        I: Retrieving libaudit-common 1:2.6.7-2
>>>>>        I: Validating libaudit-common 1:2.6.7-2
>>>>>        I: Retrieving libaudit1 1:2.6.7-2
>>>>>        I: Validating libaudit1 1:2.6.7-2
>>>>>        I: Retrieving base-files 9.9+deb9u8
>>>>>        I: Validating base-files 9.9+deb9u8
>>>>>        I: Retrieving base-passwd 3.5.43
>>>>>        I: Validating base-passwd 3.5.43
>>>>>        I: Retrieving bash 4.4-5
>>>>>        I: Validating bash 4.4-5
>>>>>        I: Retrieving libbz2-1.0 1.0.6-8.1
>>>>>        I: Validating libbz2-1.0 1.0.6-8.1
>>>>>        I: Retrieving libdebconfclient0 0.227
>>>>>        I: Validating libdebconfclient0 0.227
>>>>>        I: Retrieving coreutils 8.26-3
>>>>>        I: Validating coreutils 8.26-3
>>>>>        I: Retrieving dash 0.5.8-2.4
>>>>>        I: Validating dash 0.5.8-2.4
>>>>>        I: Retrieving libdb5.3 5.3.28-12+deb9u1
>>>>>        I: Validating libdb5.3 5.3.28-12+deb9u1
>>>>>        I: Retrieving debconf 1.5.61
>>>>>        I: Validating debconf 1.5.61
>>>>>        I: Retrieving debian-archive-keyring 2017.5
>>>>>        I: Validating debian-archive-keyring 2017.5
>>>>>        I: Retrieving debianutils 4.8.1.1
>>>>>        I: Validating debianutils 4.8.1.1
>>>>>        I: Retrieving diffutils 1:3.5-3
>>>>>        I: Validating diffutils 1:3.5-3
>>>>>        I: Retrieving dpkg 1.18.25
>>>>>        I: Validating dpkg 1.18.25
>>>>>        I: Retrieving e2fslibs 1.43.4-2
>>>>>        I: Validating e2fslibs 1.43.4-2
>>>>>        I: Retrieving e2fsprogs 1.43.4-2
>>>>>        I: Validating e2fsprogs 1.43.4-2
>>>>>        I: Retrieving libcomerr2 1.43.4-2
>>>>>        I: Validating libcomerr2 1.43.4-2
>>>>>        I: Retrieving libss2 1.43.4-2
>>>>>        I: Validating libss2 1.43.4-2
>>>>>        I: Retrieving findutils 4.6.0+git+20161106-2
>>>>>        I: Validating findutils 4.6.0+git+20161106-2
>>>>>        I: Retrieving gcc-6-base 6.3.0-18+deb9u1
>>>>>        I: Validating gcc-6-base 6.3.0-18+deb9u1
>>>>>        I: Retrieving libgcc1 1:6.3.0-18+deb9u1
>>>>>        I: Validating libgcc1 1:6.3.0-18+deb9u1
>>>>>        I: Retrieving libstdc++6 6.3.0-18+deb9u1
>>>>>        I: Validating libstdc++6 6.3.0-18+deb9u1
>>>>>        I: Retrieving libc-bin 2.24-11+deb9u4
>>>>>        I: Validating libc-bin 2.24-11+deb9u4
>>>>>        I: Retrieving libc-l10n 2.24-11+deb9u4
>>>>>        I: Validating libc-l10n 2.24-11+deb9u4
>>>>>        I: Retrieving libc6 2.24-11+deb9u4
>>>>>        I: Validating libc6 2.24-11+deb9u4
>>>>>        I: Retrieving locales 2.24-11+deb9u4
>>>>>        I: Validating locales 2.24-11+deb9u4
>>>>>        I: Retrieving multiarch-support 2.24-11+deb9u4
>>>>>        I: Validating multiarch-support 2.24-11+deb9u4
>>>>>        I: Retrieving gpgv 2.1.18-8~deb9u4
>>>>>        I: Validating gpgv 2.1.18-8~deb9u4
>>>>>        I: Retrieving grep 2.27-2
>>>>>        I: Validating grep 2.27-2
>>>>>        I: Retrieving gzip 1.6-5+b1
>>>>>        I: Validating gzip 1.6-5+b1
>>>>>        I: Retrieving hostname 3.18+b1
>>>>>        I: Validating hostname 3.18+b1
>>>>>        I: Retrieving init-system-helpers 1.48
>>>>>        I: Validating init-system-helpers 1.48
>>>>>        I: Retrieving libcap-ng0 0.7.7-3+b1
>>>>>        I: Validating libcap-ng0 0.7.7-3+b1
>>>>>        I: Retrieving libgcrypt20 1.7.6-2+deb9u3
>>>>>        I: Validating libgcrypt20 1.7.6-2+deb9u3
>>>>>        I: Retrieving libgpg-error0 1.26-2
>>>>>        I: Validating libgpg-error0 1.26-2
>>>>>        I: Retrieving libselinux1 2.6-3+b3
>>>>>        I: Validating libselinux1 2.6-3+b3
>>>>>        I: Retrieving libsemanage-common 2.6-2
>>>>>        I: Validating libsemanage-common 2.6-2
>>>>>        I: Retrieving libsemanage1 2.6-2
>>>>>        I: Validating libsemanage1 2.6-2
>>>>>        I: Retrieving libsepol1 2.6-2
>>>>>        I: Validating libsepol1 2.6-2
>>>>>        I: Retrieving lsb-base 9.20161125
>>>>>        I: Validating lsb-base 9.20161125
>>>>>        I: Retrieving liblz4-1 0.0~r131-2+b1
>>>>>        I: Validating liblz4-1 0.0~r131-2+b1
>>>>>        I: Retrieving mawk 1.3.3-17+b3
>>>>>        I: Validating mawk 1.3.3-17+b3
>>>>>        I: Retrieving libncursesw5 6.0+20161126-1+deb9u2
>>>>>        I: Validating libncursesw5 6.0+20161126-1+deb9u2
>>>>>        I: Retrieving libtinfo5 6.0+20161126-1+deb9u2
>>>>>        I: Validating libtinfo5 6.0+20161126-1+deb9u2
>>>>>        I: Retrieving ncurses-base 6.0+20161126-1+deb9u2
>>>>>        I: Validating ncurses-base 6.0+20161126-1+deb9u2
>>>>>        I: Retrieving ncurses-bin 6.0+20161126-1+deb9u2
>>>>>        I: Validating ncurses-bin 6.0+20161126-1+deb9u2
>>>>>        I: Retrieving libpam-modules 1.1.8-3.6
>>>>>        I: Validating libpam-modules 1.1.8-3.6
>>>>>        I: Retrieving libpam-modules-bin 1.1.8-3.6
>>>>>        I: Validating libpam-modules-bin 1.1.8-3.6
>>>>>        I: Retrieving libpam-runtime 1.1.8-3.6
>>>>>        I: Validating libpam-runtime 1.1.8-3.6
>>>>>        I: Retrieving libpam0g 1.1.8-3.6
>>>>>        I: Validating libpam0g 1.1.8-3.6
>>>>>        I: Retrieving libpcre3 2:8.39-3
>>>>>        I: Validating libpcre3 2:8.39-3
>>>>>        I: Retrieving perl-base 5.24.1-3+deb9u5
>>>>>        I: Validating perl-base 5.24.1-3+deb9u5
>>>>>        I: Retrieving sed 4.4-1
>>>>>        I: Validating sed 4.4-1
>>>>>        I: Retrieving sensible-utils 0.0.9+deb9u1
>>>>>        I: Validating sensible-utils 0.0.9+deb9u1
>>>>>        I: Retrieving login 1:4.4-4.1
>>>>>        I: Validating login 1:4.4-4.1
>>>>>        I: Retrieving passwd 1:4.4-4.1
>>>>>        I: Validating passwd 1:4.4-4.1
>>>>>        I: Retrieving libsystemd0 232-25+deb9u8
>>>>>        I: Validating libsystemd0 232-25+deb9u8
>>>>>        I: Retrieving libudev1 232-25+deb9u8
>>>>>        I: Validating libudev1 232-25+deb9u8
>>>>>        I: Retrieving sysvinit-utils 2.88dsf-59.9
>>>>>        I: Validating sysvinit-utils 2.88dsf-59.9
>>>>>        I: Retrieving tar 1.29b-1.1
>>>>>        I: Validating tar 1.29b-1.1
>>>>>        I: Retrieving tzdata 2018i-0+deb9u1
>>>>>        I: Validating tzdata 2018i-0+deb9u1
>>>>>        I: Retrieving libustr-1.0-1 1.0.4-6
>>>>>        I: Validating libustr-1.0-1 1.0.4-6
>>>>>        I: Retrieving bsdutils 1:2.29.2-1+deb9u1
>>>>>        I: Validating bsdutils 1:2.29.2-1+deb9u1
>>>>>        I: Retrieving libblkid1 2.29.2-1+deb9u1
>>>>>        I: Validating libblkid1 2.29.2-1+deb9u1
>>>>>        I: Retrieving libfdisk1 2.29.2-1+deb9u1
>>>>>        I: Validating libfdisk1 2.29.2-1+deb9u1
>>>>>        I: Retrieving libmount1 2.29.2-1+deb9u1
>>>>>        I: Validating libmount1 2.29.2-1+deb9u1
>>>>>        I: Retrieving libsmartcols1 2.29.2-1+deb9u1
>>>>>        I: Validating libsmartcols1 2.29.2-1+deb9u1
>>>>>        I: Retrieving libuuid1 2.29.2-1+deb9u1
>>>>>        I: Validating libuuid1 2.29.2-1+deb9u1
>>>>>        I: Retrieving mount 2.29.2-1+deb9u1
>>>>>        I: Validating mount 2.29.2-1+deb9u1
>>>>>        I: Retrieving util-linux 2.29.2-1+deb9u1
>>>>>        I: Validating util-linux 2.29.2-1+deb9u1
>>>>>        I: Retrieving liblzma5 5.2.2-1.2+b1
>>>>>        I: Validating liblzma5 5.2.2-1.2+b1
>>>>>        I: Retrieving zlib1g 1:1.2.8.dfsg-5
>>>>>        I: Validating zlib1g 1:1.2.8.dfsg-5
>>>>>        I: Chosen extractor for .deb packages: dpkg-deb
>>>>>        I: Extracting libacl1...
>>>>>        I: Extracting libattr1...
>>>>>        I: Extracting libaudit-common...
>>>>>        I: Extracting libaudit1...
>>>>>        I: Extracting base-files...
>>>>>        I: Extracting base-passwd...
>>>>>        I: Extracting bash...
>>>>>        I: Extracting libbz2-1.0...
>>>>>        I: Extracting libdebconfclient0...
>>>>>        I: Extracting coreutils...
>>>>>        I: Extracting dash...
>>>>>        I: Extracting libdb5.3...
>>>>>        I: Extracting debconf...
>>>>>        I: Extracting debianutils...
>>>>>        I: Extracting diffutils...
>>>>>        I: Extracting dpkg...
>>>>>        I: Extracting e2fslibs...
>>>>>        I: Extracting e2fsprogs...
>>>>>        I: Extracting libcomerr2...
>>>>>        I: Extracting libss2...
>>>>>        I: Extracting findutils...
>>>>>        I: Extracting gcc-6-base...
>>>>>        I: Extracting libgcc1...
>>>>>        I: Extracting libc-bin...
>>>>>        I: Extracting libc6...
>>>>>        I: Extracting multiarch-support...
>>>>>        I: Extracting grep...
>>>>>        I: Extracting gzip...
>>>>>        I: Extracting hostname...
>>>>>        I: Extracting init-system-helpers...
>>>>>        I: Extracting libcap-ng0...
>>>>>        I: Extracting libgcrypt20...
>>>>>        I: Extracting libgpg-error0...
>>>>>        I: Extracting libselinux1...
>>>>>        I: Extracting libsemanage-common...
>>>>>        I: Extracting libsemanage1...
>>>>>        I: Extracting libsepol1...
>>>>>        I: Extracting lsb-base...
>>>>>        I: Extracting liblz4-1...
>>>>>        I: Extracting mawk...
>>>>>        I: Extracting libncursesw5...
>>>>>        I: Extracting libtinfo5...
>>>>>        I: Extracting ncurses-base...
>>>>>        I: Extracting ncurses-bin...
>>>>>        I: Extracting libpam-modules...
>>>>>        I: Extracting libpam-modules-bin...
>>>>>        I: Extracting libpam-runtime...
>>>>>        I: Extracting libpam0g...
>>>>>        I: Extracting libpcre3...
>>>>>        I: Extracting perl-base...
>>>>>        I: Extracting sed...
>>>>>        I: Extracting sensible-utils...
>>>>>        I: Extracting login...
>>>>>        I: Extracting passwd...
>>>>>        I: Extracting libsystemd0...
>>>>>        I: Extracting libudev1...
>>>>>        I: Extracting sysvinit-utils...
>>>>>        I: Extracting tar...
>>>>>        I: Extracting tzdata...
>>>>>        I: Extracting libustr-1.0-1...
>>>>>        I: Extracting bsdutils...
>>>>>        I: Extracting libblkid1...
>>>>>        I: Extracting libfdisk1...
>>>>>        I: Extracting libmount1...
>>>>>        I: Extracting libsmartcols1...
>>>>>        I: Extracting libuuid1...
>>>>>        I: Extracting mount...
>>>>>        I: Extracting util-linux...
>>>>>        I: Extracting liblzma5...
>>>>>        I: Extracting zlib1g...
>>>>>        I: Running command: chroot /work/build/tmp/work/cip-core-
>>>>> armhf/isar-bootstrap-target/rootfs /debootstrap/debootstrap --
>>>>> second-stage
>>>>>        chroot: failed to run command ?/debootstrap/debootstrap?: No
>>>>> such file or directory
>>>>>        WARNING: exit code 127 from a shell command.
>>>>>        ERROR: Function failed: do_bootstrap (log file is located at
>>>>> /work/build/tmp/work/cip-core-armhf/isar-bootstrap-
>>>>> target/temp/log.do_bootstrap.316)
>>>>>
>>>>
>>>> Looping in isar-users and Claudius. I've no idea why debootstrap
>>>> should stumble here, apparently over its own feet.
>>>
>>> Well I would assume that it is an issue with your binfmt configuration
>>> if '/work/build/tmp/work/cip-core-armhf/isar-bootstrap-
>>> target/rootfs/debootstrap/deboostrap' exists.
>>>
>>
>> That's a good hint: Suzuki-san, could you check if binfmt_misc is
>> available as
>> kernel feature/module on that machine? There may also be some warning
>> during the
>> container startup.
>>
>> If that should have been the reason, we likely need a better detection
>> in Isar,
>> before the user runs into this non-obvious error message.
>>
>> Jan
>>
>> --
>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>> Corporate Competence Center Embedded Linux

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch at denx.de

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error
  2019-03-18 10:17                   ` Claudius Heine
@ 2019-03-18 10:18                     ` Jan Kiszka
  2019-03-19  5:18                       ` akihiro27.suzuki at toshiba.co.jp
  2019-03-19 10:14                       ` Henning Schild
  0 siblings, 2 replies; 40+ messages in thread
From: Jan Kiszka @ 2019-03-18 10:18 UTC (permalink / raw)
  To: cip-dev

On 18.03.19 11:17, Claudius Heine wrote:
> Hi,,
> 
> On 18/03/2019 11.14, akihiro27.suzuki at toshiba.co.jp wrote:
>> Hi,
>>
>>> That's a good hint: Suzuki-san, could you check if binfmt_misc is
>>> available as
>>> kernel feature/module on that machine? There may also be some warning
>>> during the
>>> container startup.
>> I checked it and maybe it is available.
>>
>> ???? $ mount | grep binfmt
>> ???? systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
>> (rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=18804)
>> ???? binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
>> ???? $ lsmod | grep binfmt
>> ???? binfmt_misc??????????? 20480? 1
>> ???? $ cat /boot/config-4.15.0-46-generic? | grep BINFMT
>> ???? CONFIG_BINFMT_ELF=y
>> ???? CONFIG_COMPAT_BINFMT_ELF=y
>> ???? CONFIG_BINFMT_SCRIPT=y
>> ???? CONFIG_BINFMT_MISC=m
>> ???? $ ls /proc/sys/fs/binfmt_misc/
>> ???? python2.7???? qemu-armeb?????? qemu-mips64????? qemu-ppc64le  
>> qemu-sparc??????? status
>> ???? python3.5???? qemu-cris??????? qemu-mips64el??? qemu-riscv32  
>> qemu-sparc32plus
>> ???? python3.6???? qemu-hppa??????? qemu-mipsel????? qemu-riscv64? qemu-sparc64
>> ???? qemu-aarch64? qemu-m68k??????? qemu-ppc???????? qemu-s390x??? qemu-xtensa
>> ???? qemu-alpha??? qemu-microblaze? qemu-ppc64?????? qemu-sh4????? qemu-xtensaeb
>> ???? qemu-arm????? qemu-mips??????? qemu-ppc64abi32? qemu-sh4eb??? register
>> ???? $ cat /proc/sys/fs/binfmt_misc/status
>> ???? enabled
> 
> That is how my qemu-arm setting looks like. Do you have a different qemu path?

Even if, it shouldn't be after starting the container: We allow it to adjust the 
system-wide binfmt configuration (one reason for --privileged).

Jan

> 
> $ cat /proc/sys/fs/binfmt_misc/qemu-arm
> enabled
> interpreter /usr/bin/qemu-arm-static
> flags: OCF
> offset 0
> magic 7f454c4601010100000000000000000002002800
> mask ffffffffffffff00fffffffffffffffffeffffff
> 
> regards,
> Claudius

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-18  9:14       ` akihiro27.suzuki at toshiba.co.jp
@ 2019-03-18 10:27         ` Christian Storm
  2019-03-22  5:01           ` akihiro27.suzuki at toshiba.co.jp
  0 siblings, 1 reply; 40+ messages in thread
From: Christian Storm @ 2019-03-18 10:27 UTC (permalink / raw)
  To: cip-dev

Hi Suzuki,

> > > > [Note] we are planning to develop the SWUpdate demo using ISAR, any
> > > > advice or news about how to build SWUpdate on ISAR with the right
> > > > U-Boot environment?
> > > >
> > > > - Regarding SWUpdate we hit an issue that we had not expected
> > > > before. Suzuki-san was trying to update the standard BBB debian
> > > > image (or a yocto-made one), but there were many warnings about
> > > > orphan nodes etc. After some investigation the reason seems to be
> > > > that the rootfs is modified during the first boot (or something like
> > > > that). This is probably one of the biggest problems with updating
> > > > images instead of files.
> > >
> > > Christian, any remarks?
> > 
> > Hm, did you check that you didn't flash the filesystem you have
> > currently booted, i.e., are you overwriting the currently running
> > root filesystem? I have seen such errors when I did this by accident.
>
> I mounted rootfs with read-only.

OK, from the diffs it seems that temporary storage directories such as
/run and /var/tmp are not separate mount points from your roots?

> I checked the difference of the rootfs image between before boot and after boot,
> and at least the number of mounts had changed.
> 
> I attached following log files. I think that 0x434 is a mount count.

You can use tune2fs -l /dev/<rootdevicenode> and look for
"Mount count: <some number>" to verify this.

> 
>     mmcblk1p2-1-2.diff: The difference of rootfs image between 1st boot and 2nd boot
>     mmcblk1p2-2-3.diff: The difference of rootfs image between 2nd boot and 3rd boot
> 
> Do you have some example of A/B update with binary delta update?

Well, currently nothing written in code. But I can try to elaborate on it here:
Assume that, initially, A/version=1 and B/version=1 is on-disk.
Then, the delta artifact ART_1->2 := rdiff(version=1 -> version=2) is applied to B,
resulting in A/version=1 and B/version=2 on-disk. Boot into B/version=2, which is
assumably successful.
Then, when wanting to update A to a version=3 by an artifact
ART_2->3 := rdiff(version=2 -> version=3), first ART_1->2 has to be applied to A and
thereafter ART_2->3 has to be applied to A.

Thing is here, you may have to apply a sequence of delta updates to the
"other" partition so that applying the latest delta to it results in a
consistent state, i.e., you have to do a "catchup" so that it matches
the version the latest diff is done against.

That said, in order to not be forced to store ART_1->2 on the device,
you can apply ART_1->2 to A once successfully booted into B/version=2.
Or you can generate and apply ART_1->3 := rdiff(version=1 -> version=3) to A.
Or you can split the update into first downloading and applying ART_1->2
and the ART_2->3. There are many options, actually, depending on your
preferences....


> BTW, the warning message after binary delta update was as follows:
> 
>     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm init: deleted inode referenced: 5040
>     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm init: deleted inode referenced: 5040
>     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
>     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
>     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
>     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
>     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
>     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
>     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833
>     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12: comm mount: deleted inode referenced: 5833

Well, my suspicion is that, after a delta-update of the partition, the
filesystem's metadata is corrupt, i.e., the metdata was partially
updated by a delta update, resulting in an inconsistent overall state.
Could you elaborate on the exact steps you performed? Is the diff done
from/to the right sources? Could as well be that the journal hasn't
committed the changes... Just a wild guess though...

What kernel version are you using? There are some issues with v4.19.3
and v4.19.4 and ext4 filesystems having the same symptoms...


Kind regards,
   Christian

-- 
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 M?nchen, Germany

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error
  2019-03-18 10:18                     ` Jan Kiszka
@ 2019-03-19  5:18                       ` akihiro27.suzuki at toshiba.co.jp
  2019-03-19  7:22                         ` Claudius Heine
  2019-03-19 10:14                       ` Henning Schild
  1 sibling, 1 reply; 40+ messages in thread
From: akihiro27.suzuki at toshiba.co.jp @ 2019-03-19  5:18 UTC (permalink / raw)
  To: cip-dev

Hi,

> > That is how my qemu-arm setting looks like. Do you have a differentqemu path?
> > 
> > $ cat /proc/sys/fs/binfmt_misc/qemu-arm
> > enabled
> > interpreter /usr/bin/qemu-arm-static
> > flags: OCF
> > offset 0
> > magic 7f454c4601010100000000000000000002002800
> > mask ffffffffffffff00fffffffffffffffffeffffff
My qemu-arm setting is as follows:

    $ cat /proc/sys/fs/binfmt_misc/qemu-arm
    enabled
    interpreter /usr/bin/qemu-arm
    flags: OC
    offset 0
    magic 7f454c4601010100000000000000000002002800
    mask ffffffffffffff00fffffffffffffffffeffffff

According to this, the interpreter path was not same.
My machine used /usr/bin/qemu-arm but Claudius's machine used /usr/bin/qemu-arm-static.

If the first place, my machine didn't have /usr/bin/qemu-arm-static.
So, I installed qemu-user-static as follows:

    $ sudo aptitude install qemu-user-static
    [sudo] password for akihiro:
    The following NEW packages will be installed:
      qemu-user-static{b}
    0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
    Need to get 10.0 MB of archives. After unpacking 101 MB will be used.
    The following packages have unmet dependencies:
     qemu-user-static : Conflicts: qemu-user-binfmt but 1:2.11+dfsg-1ubuntu7.10 is installed
     qemu-user-binfmt : Conflicts: qemu-user-static but 1:2.11+dfsg-1ubuntu7.10 is to be installed
    The following actions will resolve these dependencies:
    
         Remove the following packages:
    1)     qemu-user-binfmt [1:2.11+dfsg-1ubuntu7.10 (bionic-updates, now)]
    
    Accept this solution? [Y/n/q/?] Y
    The following NEW packages will be installed:
      qemu-user-static
    The following packages will be REMOVED:
      qemu-user-binfmt{a}
    0 packages upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
    Need to get 10.0 MB of archives. After unpacking 101 MB will be used.
    Do you want to continue? [Y/n/?] Y
    Get: 1 http://ftp.jaist.ac.jp/pub/Linux/ubuntu bionic-updates/universe amd64 qemu-user-static amd64 1:2.11+dfsg-1ubuntu7.10 [10.0 MB]
    Fetched 10.0 MB in 1min 5s (155 kB/s)
    (Reading database ... 299683 files and directories currently installed.)
    Removing qemu-user-binfmt (1:2.11+dfsg-1ubuntu7.10) ...
    Selecting previously unselected package qemu-user-static.
    (Reading database ... 299683 files and directories currently installed.)
    Preparing to unpack .../qemu-user-static_1%3a2.11+dfsg-1ubuntu7.10_amd64.deb ...
    Unpacking qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
    Setting up qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
    Processing triggers for man-db (2.8.3-2ubuntu0.1) ...

After that, I checked my qemu-arm setting.
The interpreter path has been changed to /usr/bin/qemu-arm-static as below:

    $ cat /proc/sys/fs/binfmt_misc/qemu-arm
    enabled
    interpreter /usr/bin/qemu-arm-static
    flags: OC
    offset 0
    magic 7f454c4601010100000000000000000002002800
    mask ffffffffffffff00fffffffffffffffffeffffff

After that, I built board-bbb.yml as below, and it succeeded!

    $ ./kas-docker --isar build kas.yml:board-bbb.yml

The root cause of this error is that my machine was not using
statically linked user mode qemu binaries?

Best regards,
Suzuki

> -----Original Message-----
> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
> Sent: Monday, March 18, 2019 7:19 PM
> To: Claudius Heine <claudius.heine.ext@siemens.com>; suzuki akihiro(?
> ? ?? ????????) <akihiro27.suzuki@toshiba.co.jp>;
> isar-users at googlegroups.com; ch at denx.de
> Cc: sangorrin daniel(????? ???? ????????)
> <daniel.sangorrin@toshiba.co.jp>; cip-dev at lists.cip-project.org
> Subject: Re: debootrap error
> 
> On 18.03.19 11:17, Claudius Heine wrote:
> > Hi,,
> >
> > On 18/03/2019 11.14, akihiro27.suzuki at toshiba.co.jp wrote:
> >> Hi,
> >>
> >>> That's a good hint: Suzuki-san, could you check if binfmt_misc is
> >>> available as
> >>> kernel feature/module on that machine? There may also be some warning
> >>> during the
> >>> container startup.
> >> I checked it and maybe it is available.
> >>
> >> ???? $ mount | grep binfmt
> >> ???? systemd-1 on /proc/sys/fs/binfmt_misc type autofs
> >>
> (rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pip
> e_ino=18804)
> >> ???? binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
> (rw,relatime)
> >> ???? $ lsmod | grep binfmt
> >> ???? binfmt_misc??????????? 20480? 1
> >> ???? $ cat /boot/config-4.15.0-46-generic? | grep BINFMT
> >> ???? CONFIG_BINFMT_ELF=y
> >> ???? CONFIG_COMPAT_BINFMT_ELF=y
> >> ???? CONFIG_BINFMT_SCRIPT=y
> >> ???? CONFIG_BINFMT_MISC=m
> >> ???? $ ls /proc/sys/fs/binfmt_misc/
> >> ???? python2.7???? qemu-armeb?????? qemu-mips64????? qemu-ppc64
> le
> >> qemu-sparc??????? status
> >> ???? python3.5???? qemu-cris??????? qemu-mips64el??? qemu-riscv
> 32
> >> qemu-sparc32plus
> >> ???? python3.6???? qemu-hppa??????? qemu-mipsel????? qemu-riscv
> 64? qemu-sparc64
> >> ???? qemu-aarch64? qemu-m68k??????? qemu-ppc???????? qemu-s390x
> ??? qemu-xtensa
> >> ???? qemu-alpha??? qemu-microblaze? qemu-ppc64?????? qemu-sh4
> ??? qemu-xtensaeb
> >> ???? qemu-arm????? qemu-mips??????? qemu-ppc64abi32? qemu-sh4eb
> ??? register
> >> ???? $ cat /proc/sys/fs/binfmt_misc/status
> >> ???? enabled
> >
> > That is how my qemu-arm setting looks like. Do you have a different
> qemu path?
> 
> Even if, it shouldn't be after starting the container: We allow it to
> adjust the
> system-wide binfmt configuration (one reason for --privileged).
> 
> Jan
> 
> >
> > $ cat /proc/sys/fs/binfmt_misc/qemu-arm
> > enabled
> > interpreter /usr/bin/qemu-arm-static
> > flags: OCF
> > offset 0
> > magic 7f454c4601010100000000000000000002002800
> > mask ffffffffffffff00fffffffffffffffffeffffff
> >
> > regards,
> > Claudius
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error
  2019-03-19  5:18                       ` akihiro27.suzuki at toshiba.co.jp
@ 2019-03-19  7:22                         ` Claudius Heine
  2019-03-19  7:51                           ` Jan Kiszka
  0 siblings, 1 reply; 40+ messages in thread
From: Claudius Heine @ 2019-03-19  7:22 UTC (permalink / raw)
  To: cip-dev

Hi Suzuki-san,

On 19/03/2019 06.18, akihiro27.suzuki at toshiba.co.jp wrote:
> Hi,
> 
>>> That is how my qemu-arm setting looks like. Do you have a differentqemu path?
>>>
>>> $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>>> enabled
>>> interpreter /usr/bin/qemu-arm-static
>>> flags: OCF
>>> offset 0
>>> magic 7f454c4601010100000000000000000002002800
>>> mask ffffffffffffff00fffffffffffffffffeffffff
> My qemu-arm setting is as follows:
> 
>      $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>      enabled
>      interpreter /usr/bin/qemu-arm
>      flags: OC
>      offset 0
>      magic 7f454c4601010100000000000000000002002800
>      mask ffffffffffffff00fffffffffffffffffeffffff
> 
> According to this, the interpreter path was not same.
> My machine used /usr/bin/qemu-arm but Claudius's machine used /usr/bin/qemu-arm-static.
> 
> If the first place, my machine didn't have /usr/bin/qemu-arm-static.
> So, I installed qemu-user-static as follows:
> 
>      $ sudo aptitude install qemu-user-static
>      [sudo] password for akihiro:
>      The following NEW packages will be installed:
>        qemu-user-static{b}
>      0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
>      Need to get 10.0 MB of archives. After unpacking 101 MB will be used.
>      The following packages have unmet dependencies:
>       qemu-user-static : Conflicts: qemu-user-binfmt but 1:2.11+dfsg-1ubuntu7.10 is installed
>       qemu-user-binfmt : Conflicts: qemu-user-static but 1:2.11+dfsg-1ubuntu7.10 is to be installed
>      The following actions will resolve these dependencies:
>      
>           Remove the following packages:
>      1)     qemu-user-binfmt [1:2.11+dfsg-1ubuntu7.10 (bionic-updates, now)]
>      
>      Accept this solution? [Y/n/q/?] Y
>      The following NEW packages will be installed:
>        qemu-user-static
>      The following packages will be REMOVED:
>        qemu-user-binfmt{a}
>      0 packages upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
>      Need to get 10.0 MB of archives. After unpacking 101 MB will be used.
>      Do you want to continue? [Y/n/?] Y
>      Get: 1 http://ftp.jaist.ac.jp/pub/Linux/ubuntu bionic-updates/universe amd64 qemu-user-static amd64 1:2.11+dfsg-1ubuntu7.10 [10.0 MB]
>      Fetched 10.0 MB in 1min 5s (155 kB/s)
>      (Reading database ... 299683 files and directories currently installed.)
>      Removing qemu-user-binfmt (1:2.11+dfsg-1ubuntu7.10) ...
>      Selecting previously unselected package qemu-user-static.
>      (Reading database ... 299683 files and directories currently installed.)
>      Preparing to unpack .../qemu-user-static_1%3a2.11+dfsg-1ubuntu7.10_amd64.deb ...
>      Unpacking qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
>      Setting up qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
>      Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
> 
> After that, I checked my qemu-arm setting.
> The interpreter path has been changed to /usr/bin/qemu-arm-static as below:
> 
>      $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>      enabled
>      interpreter /usr/bin/qemu-arm-static
>      flags: OC
>      offset 0
>      magic 7f454c4601010100000000000000000002002800
>      mask ffffffffffffff00fffffffffffffffffeffffff
> 
> After that, I built board-bbb.yml as below, and it succeeded!
> 
>      $ ./kas-docker --isar build kas.yml:board-bbb.yml
> 
> The root cause of this error is that my machine was not using
> statically linked user mode qemu binaries?

Well the docker container has the 'qemu-user-static' files installed as 
a dependency of qemu-debootstrap. The dynamic linking version would not 
work here, because qemu-deboostrap will copy just the one binary to the 
bootstrapped rootfs before chrooting into it. The binfmt_misc settings 
needs to point to the qemu static binary that was copied to the rootfs 
for this to work. The error of course is pretty misleading and stumbled 
over that very often myself.

And what your problem shows as well is that the call of 'update-binfmts 
--enable' (which happens in the docker entry point script) does not seem 
to fix the path.

kind regards,
Claudius

> 
> Best regards,
> Suzuki
> 
>> -----Original Message-----
>> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
>> Sent: Monday, March 18, 2019 7:19 PM
>> To: Claudius Heine <claudius.heine.ext@siemens.com>; suzuki akihiro(?
>> ? ?? ????????) <akihiro27.suzuki@toshiba.co.jp>;
>> isar-users at googlegroups.com; ch at denx.de
>> Cc: sangorrin daniel(????? ???? ????????)
>> <daniel.sangorrin@toshiba.co.jp>; cip-dev at lists.cip-project.org
>> Subject: Re: debootrap error
>>
>> On 18.03.19 11:17, Claudius Heine wrote:
>>> Hi,,
>>>
>>> On 18/03/2019 11.14, akihiro27.suzuki at toshiba.co.jp wrote:
>>>> Hi,
>>>>
>>>>> That's a good hint: Suzuki-san, could you check if binfmt_misc is
>>>>> available as
>>>>> kernel feature/module on that machine? There may also be some warning
>>>>> during the
>>>>> container startup.
>>>> I checked it and maybe it is available.
>>>>
>>>>  ???? $ mount | grep binfmt
>>>>  ???? systemd-1 on /proc/sys/fs/binfmt_misc type autofs
>>>>
>> (rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pip
>> e_ino=18804)
>>>>  ???? binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
>> (rw,relatime)
>>>>  ???? $ lsmod | grep binfmt
>>>>  ???? binfmt_misc??????????? 20480? 1
>>>>  ???? $ cat /boot/config-4.15.0-46-generic? | grep BINFMT
>>>>  ???? CONFIG_BINFMT_ELF=y
>>>>  ???? CONFIG_COMPAT_BINFMT_ELF=y
>>>>  ???? CONFIG_BINFMT_SCRIPT=y
>>>>  ???? CONFIG_BINFMT_MISC=m
>>>>  ???? $ ls /proc/sys/fs/binfmt_misc/
>>>>  ???? python2.7???? qemu-armeb?????? qemu-mips64????? qemu-ppc64
>> le
>>>> qemu-sparc??????? status
>>>>  ???? python3.5???? qemu-cris??????? qemu-mips64el??? qemu-riscv
>> 32
>>>> qemu-sparc32plus
>>>>  ???? python3.6???? qemu-hppa??????? qemu-mipsel????? qemu-riscv
>> 64? qemu-sparc64
>>>>  ???? qemu-aarch64? qemu-m68k??????? qemu-ppc???????? qemu-s390x
>>  ??? qemu-xtensa
>>>>  ???? qemu-alpha??? qemu-microblaze? qemu-ppc64?????? qemu-sh4
>>  ??? qemu-xtensaeb
>>>>  ???? qemu-arm????? qemu-mips??????? qemu-ppc64abi32? qemu-sh4eb
>>  ??? register
>>>>  ???? $ cat /proc/sys/fs/binfmt_misc/status
>>>>  ???? enabled
>>>
>>> That is how my qemu-arm setting looks like. Do you have a different
>> qemu path?
>>
>> Even if, it shouldn't be after starting the container: We allow it to
>> adjust the
>> system-wide binfmt configuration (one reason for --privileged).
>>
>> Jan
>>
>>>
>>> $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>>> enabled
>>> interpreter /usr/bin/qemu-arm-static
>>> flags: OCF
>>> offset 0
>>> magic 7f454c4601010100000000000000000002002800
>>> mask ffffffffffffff00fffffffffffffffffeffffff
>>>
>>> regards,
>>> Claudius
>>
>> --
>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>> Corporate Competence Center Embedded Linux
> 

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch at denx.de

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error
  2019-03-19  7:22                         ` Claudius Heine
@ 2019-03-19  7:51                           ` Jan Kiszka
  2019-03-19  8:01                             ` Claudius Heine
  0 siblings, 1 reply; 40+ messages in thread
From: Jan Kiszka @ 2019-03-19  7:51 UTC (permalink / raw)
  To: cip-dev

On 19.03.19 08:22, Claudius Heine wrote:
> Hi Suzuki-san,
> 
> On 19/03/2019 06.18, akihiro27.suzuki at toshiba.co.jp wrote:
>> Hi,
>>
>>>> That is how my qemu-arm setting looks like. Do you have a differentqemu path?
>>>>
>>>> $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>>>> enabled
>>>> interpreter /usr/bin/qemu-arm-static
>>>> flags: OCF
>>>> offset 0
>>>> magic 7f454c4601010100000000000000000002002800
>>>> mask ffffffffffffff00fffffffffffffffffeffffff
>> My qemu-arm setting is as follows:
>>
>> ???? $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>> ???? enabled
>> ???? interpreter /usr/bin/qemu-arm
>> ???? flags: OC
>> ???? offset 0
>> ???? magic 7f454c4601010100000000000000000002002800
>> ???? mask ffffffffffffff00fffffffffffffffffeffffff
>>
>> According to this, the interpreter path was not same.
>> My machine used /usr/bin/qemu-arm but Claudius's machine used 
>> /usr/bin/qemu-arm-static.
>>
>> If the first place, my machine didn't have /usr/bin/qemu-arm-static.
>> So, I installed qemu-user-static as follows:
>>
>> ???? $ sudo aptitude install qemu-user-static
>> ???? [sudo] password for akihiro:
>> ???? The following NEW packages will be installed:
>> ?????? qemu-user-static{b}
>> ???? 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
>> ???? Need to get 10.0 MB of archives. After unpacking 101 MB will be used.
>> ???? The following packages have unmet dependencies:
>> ????? qemu-user-static : Conflicts: qemu-user-binfmt but 
>> 1:2.11+dfsg-1ubuntu7.10 is installed
>> ????? qemu-user-binfmt : Conflicts: qemu-user-static but 
>> 1:2.11+dfsg-1ubuntu7.10 is to be installed
>> ???? The following actions will resolve these dependencies:
>> ????????? Remove the following packages:
>> ???? 1)???? qemu-user-binfmt [1:2.11+dfsg-1ubuntu7.10 (bionic-updates, now)]
>> ???? Accept this solution? [Y/n/q/?] Y
>> ???? The following NEW packages will be installed:
>> ?????? qemu-user-static
>> ???? The following packages will be REMOVED:
>> ?????? qemu-user-binfmt{a}
>> ???? 0 packages upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
>> ???? Need to get 10.0 MB of archives. After unpacking 101 MB will be used.
>> ???? Do you want to continue? [Y/n/?] Y
>> ???? Get: 1 http://ftp.jaist.ac.jp/pub/Linux/ubuntu bionic-updates/universe 
>> amd64 qemu-user-static amd64 1:2.11+dfsg-1ubuntu7.10 [10.0 MB]
>> ???? Fetched 10.0 MB in 1min 5s (155 kB/s)
>> ???? (Reading database ... 299683 files and directories currently installed.)
>> ???? Removing qemu-user-binfmt (1:2.11+dfsg-1ubuntu7.10) ...
>> ???? Selecting previously unselected package qemu-user-static.
>> ???? (Reading database ... 299683 files and directories currently installed.)
>> ???? Preparing to unpack 
>> .../qemu-user-static_1%3a2.11+dfsg-1ubuntu7.10_amd64.deb ...
>> ???? Unpacking qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
>> ???? Setting up qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
>> ???? Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
>>
>> After that, I checked my qemu-arm setting.
>> The interpreter path has been changed to /usr/bin/qemu-arm-static as below:
>>
>> ???? $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>> ???? enabled
>> ???? interpreter /usr/bin/qemu-arm-static
>> ???? flags: OC
>> ???? offset 0
>> ???? magic 7f454c4601010100000000000000000002002800
>> ???? mask ffffffffffffff00fffffffffffffffffeffffff
>>
>> After that, I built board-bbb.yml as below, and it succeeded!
>>
>> ???? $ ./kas-docker --isar build kas.yml:board-bbb.yml
>>
>> The root cause of this error is that my machine was not using
>> statically linked user mode qemu binaries?
> 
> Well the docker container has the 'qemu-user-static' files installed as a 
> dependency of qemu-debootstrap. The dynamic linking version would not work here, 
> because qemu-deboostrap will copy just the one binary to the bootstrapped rootfs 
> before chrooting into it. The binfmt_misc settings needs to point to the qemu 
> static binary that was copied to the rootfs for this to work. The error of 
> course is pretty misleading and stumbled over that very often myself.
> 
> And what your problem shows as well is that the call of 'update-binfmts 
> --enable' (which happens in the docker entry point script) does not seem to fix 
> the path.

...which is good to know. Maybe it gets tricked by something being enabled 
already. But I thought I tested this. Anyway, I guess we need to study that 
script /wrt how to achieve some reliable rewriting of the settings.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error
  2019-03-19  7:51                           ` Jan Kiszka
@ 2019-03-19  8:01                             ` Claudius Heine
  2019-03-19  9:09                               ` Jan Kiszka
  0 siblings, 1 reply; 40+ messages in thread
From: Claudius Heine @ 2019-03-19  8:01 UTC (permalink / raw)
  To: cip-dev

On Tue, 2019-03-19 at 08:51 +0100, Jan Kiszka wrote:
> On 19.03.19 08:22, Claudius Heine wrote:
> > Hi Suzuki-san,
> > 
> > On 19/03/2019 06.18, akihiro27.suzuki at toshiba.co.jp wrote:
> > > Hi,
> > > 
> > > > > That is how my qemu-arm setting looks like. Do you have a
> > > > > differentqemu path?
> > > > > 
> > > > > $ cat /proc/sys/fs/binfmt_misc/qemu-arm
> > > > > enabled
> > > > > interpreter /usr/bin/qemu-arm-static
> > > > > flags: OCF
> > > > > offset 0
> > > > > magic 7f454c4601010100000000000000000002002800
> > > > > mask ffffffffffffff00fffffffffffffffffeffffff
> > > My qemu-arm setting is as follows:
> > > 
> > >      $ cat /proc/sys/fs/binfmt_misc/qemu-arm
> > >      enabled
> > >      interpreter /usr/bin/qemu-arm
> > >      flags: OC
> > >      offset 0
> > >      magic 7f454c4601010100000000000000000002002800
> > >      mask ffffffffffffff00fffffffffffffffffeffffff
> > > 
> > > According to this, the interpreter path was not same.
> > > My machine used /usr/bin/qemu-arm but Claudius's machine used 
> > > /usr/bin/qemu-arm-static.
> > > 
> > > If the first place, my machine didn't have /usr/bin/qemu-arm-
> > > static.
> > > So, I installed qemu-user-static as follows:
> > > 
> > >      $ sudo aptitude install qemu-user-static
> > >      [sudo] password for akihiro:
> > >      The following NEW packages will be installed:
> > >        qemu-user-static{b}
> > >      0 packages upgraded, 1 newly installed, 0 to remove and 0
> > > not upgraded.
> > >      Need to get 10.0 MB of archives. After unpacking 101 MB will
> > > be used.
> > >      The following packages have unmet dependencies:
> > >       qemu-user-static : Conflicts: qemu-user-binfmt but 
> > > 1:2.11+dfsg-1ubuntu7.10 is installed
> > >       qemu-user-binfmt : Conflicts: qemu-user-static but 
> > > 1:2.11+dfsg-1ubuntu7.10 is to be installed
> > >      The following actions will resolve these dependencies:
> > >           Remove the following packages:
> > >      1)     qemu-user-binfmt [1:2.11+dfsg-1ubuntu7.10 (bionic-
> > > updates, now)]
> > >      Accept this solution? [Y/n/q/?] Y
> > >      The following NEW packages will be installed:
> > >        qemu-user-static
> > >      The following packages will be REMOVED:
> > >        qemu-user-binfmt{a}
> > >      0 packages upgraded, 1 newly installed, 1 to remove and 0
> > > not upgraded.
> > >      Need to get 10.0 MB of archives. After unpacking 101 MB will
> > > be used.
> > >      Do you want to continue? [Y/n/?] Y
> > >      Get: 1 http://ftp.jaist.ac.jp/pub/Linux/ubuntu bionic-
> > > updates/universe 
> > > amd64 qemu-user-static amd64 1:2.11+dfsg-1ubuntu7.10 [10.0 MB]
> > >      Fetched 10.0 MB in 1min 5s (155 kB/s)
> > >      (Reading database ... 299683 files and directories currently
> > > installed.)
> > >      Removing qemu-user-binfmt (1:2.11+dfsg-1ubuntu7.10) ...
> > >      Selecting previously unselected package qemu-user-static.
> > >      (Reading database ... 299683 files and directories currently
> > > installed.)
> > >      Preparing to unpack 
> > > .../qemu-user-static_1%3a2.11+dfsg-1ubuntu7.10_amd64.deb ...
> > >      Unpacking qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
> > >      Setting up qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
> > >      Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
> > > 
> > > After that, I checked my qemu-arm setting.
> > > The interpreter path has been changed to /usr/bin/qemu-arm-static 
> > > as below:
> > > 
> > >      $ cat /proc/sys/fs/binfmt_misc/qemu-arm
> > >      enabled
> > >      interpreter /usr/bin/qemu-arm-static
> > >      flags: OC
> > >      offset 0
> > >      magic 7f454c4601010100000000000000000002002800
> > >      mask ffffffffffffff00fffffffffffffffffeffffff
> > > 
> > > After that, I built board-bbb.yml as below, and it succeeded!
> > > 
> > >      $ ./kas-docker --isar build kas.yml:board-bbb.yml
> > > 
> > > The root cause of this error is that my machine was not using
> > > statically linked user mode qemu binaries?
> > 
> > Well the docker container has the 'qemu-user-static' files
> > installed as a 
> > dependency of qemu-debootstrap. The dynamic linking version would
> > not work here, 
> > because qemu-deboostrap will copy just the one binary to the
> > bootstrapped rootfs 
> > before chrooting into it. The binfmt_misc settings needs to point
> > to the qemu 
> > static binary that was copied to the rootfs for this to work. The
> > error of 
> > course is pretty misleading and stumbled over that very often
> > myself.
> > 
> > And what your problem shows as well is that the call of 'update-
> > binfmts 
> > --enable' (which happens in the docker entry point script) does not
> > seem to fix 
> > the path.
> 
> ...which is good to know. Maybe it gets tricked by something being
> enabled 
> already. But I thought I tested this. Anyway, I guess we need to
> study that 
> script /wrt how to achieve some reliable rewriting of the settings.

Well you could just call '/var/lib/dpkg/info/qemu-user-static.postinst' 
from the docker entry point :)

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error
  2019-03-19  8:01                             ` Claudius Heine
@ 2019-03-19  9:09                               ` Jan Kiszka
  2019-03-19  9:26                                 ` Claudius Heine
  0 siblings, 1 reply; 40+ messages in thread
From: Jan Kiszka @ 2019-03-19  9:09 UTC (permalink / raw)
  To: cip-dev

On 19.03.19 09:01, Claudius Heine wrote:
> On Tue, 2019-03-19 at 08:51 +0100, Jan Kiszka wrote:
>> On 19.03.19 08:22, Claudius Heine wrote:
>>> Hi Suzuki-san,
>>>
>>> On 19/03/2019 06.18, akihiro27.suzuki at toshiba.co.jp wrote:
>>>> Hi,
>>>>
>>>>>> That is how my qemu-arm setting looks like. Do you have a
>>>>>> differentqemu path?
>>>>>>
>>>>>> $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>>>>>> enabled
>>>>>> interpreter /usr/bin/qemu-arm-static
>>>>>> flags: OCF
>>>>>> offset 0
>>>>>> magic 7f454c4601010100000000000000000002002800
>>>>>> mask ffffffffffffff00fffffffffffffffffeffffff
>>>> My qemu-arm setting is as follows:
>>>>
>>>>       $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>>>>       enabled
>>>>       interpreter /usr/bin/qemu-arm
>>>>       flags: OC
>>>>       offset 0
>>>>       magic 7f454c4601010100000000000000000002002800
>>>>       mask ffffffffffffff00fffffffffffffffffeffffff
>>>>
>>>> According to this, the interpreter path was not same.
>>>> My machine used /usr/bin/qemu-arm but Claudius's machine used
>>>> /usr/bin/qemu-arm-static.
>>>>
>>>> If the first place, my machine didn't have /usr/bin/qemu-arm-
>>>> static.
>>>> So, I installed qemu-user-static as follows:
>>>>
>>>>       $ sudo aptitude install qemu-user-static
>>>>       [sudo] password for akihiro:
>>>>       The following NEW packages will be installed:
>>>>         qemu-user-static{b}
>>>>       0 packages upgraded, 1 newly installed, 0 to remove and 0
>>>> not upgraded.
>>>>       Need to get 10.0 MB of archives. After unpacking 101 MB will
>>>> be used.
>>>>       The following packages have unmet dependencies:
>>>>        qemu-user-static : Conflicts: qemu-user-binfmt but
>>>> 1:2.11+dfsg-1ubuntu7.10 is installed
>>>>        qemu-user-binfmt : Conflicts: qemu-user-static but
>>>> 1:2.11+dfsg-1ubuntu7.10 is to be installed
>>>>       The following actions will resolve these dependencies:
>>>>            Remove the following packages:
>>>>       1)     qemu-user-binfmt [1:2.11+dfsg-1ubuntu7.10 (bionic-
>>>> updates, now)]
>>>>       Accept this solution? [Y/n/q/?] Y
>>>>       The following NEW packages will be installed:
>>>>         qemu-user-static
>>>>       The following packages will be REMOVED:
>>>>         qemu-user-binfmt{a}
>>>>       0 packages upgraded, 1 newly installed, 1 to remove and 0
>>>> not upgraded.
>>>>       Need to get 10.0 MB of archives. After unpacking 101 MB will
>>>> be used.
>>>>       Do you want to continue? [Y/n/?] Y
>>>>       Get: 1 http://ftp.jaist.ac.jp/pub/Linux/ubuntu bionic-
>>>> updates/universe
>>>> amd64 qemu-user-static amd64 1:2.11+dfsg-1ubuntu7.10 [10.0 MB]
>>>>       Fetched 10.0 MB in 1min 5s (155 kB/s)
>>>>       (Reading database ... 299683 files and directories currently
>>>> installed.)
>>>>       Removing qemu-user-binfmt (1:2.11+dfsg-1ubuntu7.10) ...
>>>>       Selecting previously unselected package qemu-user-static.
>>>>       (Reading database ... 299683 files and directories currently
>>>> installed.)
>>>>       Preparing to unpack
>>>> .../qemu-user-static_1%3a2.11+dfsg-1ubuntu7.10_amd64.deb ...
>>>>       Unpacking qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
>>>>       Setting up qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
>>>>       Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
>>>>
>>>> After that, I checked my qemu-arm setting.
>>>> The interpreter path has been changed to /usr/bin/qemu-arm-static
>>>> as below:
>>>>
>>>>       $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>>>>       enabled
>>>>       interpreter /usr/bin/qemu-arm-static
>>>>       flags: OC
>>>>       offset 0
>>>>       magic 7f454c4601010100000000000000000002002800
>>>>       mask ffffffffffffff00fffffffffffffffffeffffff
>>>>
>>>> After that, I built board-bbb.yml as below, and it succeeded!
>>>>
>>>>       $ ./kas-docker --isar build kas.yml:board-bbb.yml
>>>>
>>>> The root cause of this error is that my machine was not using
>>>> statically linked user mode qemu binaries?
>>>
>>> Well the docker container has the 'qemu-user-static' files
>>> installed as a
>>> dependency of qemu-debootstrap. The dynamic linking version would
>>> not work here,
>>> because qemu-deboostrap will copy just the one binary to the
>>> bootstrapped rootfs
>>> before chrooting into it. The binfmt_misc settings needs to point
>>> to the qemu
>>> static binary that was copied to the rootfs for this to work. The
>>> error of
>>> course is pretty misleading and stumbled over that very often
>>> myself.
>>>
>>> And what your problem shows as well is that the call of 'update-
>>> binfmts
>>> --enable' (which happens in the docker entry point script) does not
>>> seem to fix
>>> the path.
>>
>> ...which is good to know. Maybe it gets tricked by something being
>> enabled
>> already. But I thought I tested this. Anyway, I guess we need to
>> study that
>> script /wrt how to achieve some reliable rewriting of the settings.
> 
> Well you could just call '/var/lib/dpkg/info/qemu-user-static.postinst'
> from the docker entry point :)
> 

Ugly... And that call will actually be nop due to how the script works (if it 
works at all).

It seems this binfmt installation never worked for the isar-kas
container:

builder at 384a365634ab:~$ ls /usr/share/binfmts/
python2.7  python3.5

And python2.7 does a file installation+ an update-binfmt --import - rather than 
a --install - during its postinst.

"For packages, this is preferable to using the --install option, as
a format file can be installed without update-binfmts needing to be
available."
[update-binfmt man page]

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error
  2019-03-19  9:09                               ` Jan Kiszka
@ 2019-03-19  9:26                                 ` Claudius Heine
  2019-03-19  9:45                                   ` Jan Kiszka
  0 siblings, 1 reply; 40+ messages in thread
From: Claudius Heine @ 2019-03-19  9:26 UTC (permalink / raw)
  To: cip-dev



On 19/03/2019 10.09, Jan Kiszka wrote:
> On 19.03.19 09:01, Claudius Heine wrote:
>> On Tue, 2019-03-19 at 08:51 +0100, Jan Kiszka wrote:
>>> On 19.03.19 08:22, Claudius Heine wrote:
>>>> Hi Suzuki-san,
>>>>
>>>> On 19/03/2019 06.18, akihiro27.suzuki at toshiba.co.jp wrote:
>>>>> Hi,
>>>>>
>>>>>>> That is how my qemu-arm setting looks like. Do you have a
>>>>>>> differentqemu path?
>>>>>>>
>>>>>>> $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>>>>>>> enabled
>>>>>>> interpreter /usr/bin/qemu-arm-static
>>>>>>> flags: OCF
>>>>>>> offset 0
>>>>>>> magic 7f454c4601010100000000000000000002002800
>>>>>>> mask ffffffffffffff00fffffffffffffffffeffffff
>>>>> My qemu-arm setting is as follows:
>>>>>
>>>>> ????? $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>>>>> ????? enabled
>>>>> ????? interpreter /usr/bin/qemu-arm
>>>>> ????? flags: OC
>>>>> ????? offset 0
>>>>> ????? magic 7f454c4601010100000000000000000002002800
>>>>> ????? mask ffffffffffffff00fffffffffffffffffeffffff
>>>>>
>>>>> According to this, the interpreter path was not same.
>>>>> My machine used /usr/bin/qemu-arm but Claudius's machine used
>>>>> /usr/bin/qemu-arm-static.
>>>>>
>>>>> If the first place, my machine didn't have /usr/bin/qemu-arm-
>>>>> static.
>>>>> So, I installed qemu-user-static as follows:
>>>>>
>>>>> ????? $ sudo aptitude install qemu-user-static
>>>>> ????? [sudo] password for akihiro:
>>>>> ????? The following NEW packages will be installed:
>>>>> ??????? qemu-user-static{b}
>>>>> ????? 0 packages upgraded, 1 newly installed, 0 to remove and 0
>>>>> not upgraded.
>>>>> ????? Need to get 10.0 MB of archives. After unpacking 101 MB will
>>>>> be used.
>>>>> ????? The following packages have unmet dependencies:
>>>>> ?????? qemu-user-static : Conflicts: qemu-user-binfmt but
>>>>> 1:2.11+dfsg-1ubuntu7.10 is installed
>>>>> ?????? qemu-user-binfmt : Conflicts: qemu-user-static but
>>>>> 1:2.11+dfsg-1ubuntu7.10 is to be installed
>>>>> ????? The following actions will resolve these dependencies:
>>>>> ?????????? Remove the following packages:
>>>>> ????? 1)???? qemu-user-binfmt [1:2.11+dfsg-1ubuntu7.10 (bionic-
>>>>> updates, now)]
>>>>> ????? Accept this solution? [Y/n/q/?] Y
>>>>> ????? The following NEW packages will be installed:
>>>>> ??????? qemu-user-static
>>>>> ????? The following packages will be REMOVED:
>>>>> ??????? qemu-user-binfmt{a}
>>>>> ????? 0 packages upgraded, 1 newly installed, 1 to remove and 0
>>>>> not upgraded.
>>>>> ????? Need to get 10.0 MB of archives. After unpacking 101 MB will
>>>>> be used.
>>>>> ????? Do you want to continue? [Y/n/?] Y
>>>>> ????? Get: 1 http://ftp.jaist.ac.jp/pub/Linux/ubuntu bionic-
>>>>> updates/universe
>>>>> amd64 qemu-user-static amd64 1:2.11+dfsg-1ubuntu7.10 [10.0 MB]
>>>>> ????? Fetched 10.0 MB in 1min 5s (155 kB/s)
>>>>> ????? (Reading database ... 299683 files and directories currently
>>>>> installed.)
>>>>> ????? Removing qemu-user-binfmt (1:2.11+dfsg-1ubuntu7.10) ...
>>>>> ????? Selecting previously unselected package qemu-user-static.
>>>>> ????? (Reading database ... 299683 files and directories currently
>>>>> installed.)
>>>>> ????? Preparing to unpack
>>>>> .../qemu-user-static_1%3a2.11+dfsg-1ubuntu7.10_amd64.deb ...
>>>>> ????? Unpacking qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
>>>>> ????? Setting up qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
>>>>> ????? Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
>>>>>
>>>>> After that, I checked my qemu-arm setting.
>>>>> The interpreter path has been changed to /usr/bin/qemu-arm-static
>>>>> as below:
>>>>>
>>>>> ????? $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>>>>> ????? enabled
>>>>> ????? interpreter /usr/bin/qemu-arm-static
>>>>> ????? flags: OC
>>>>> ????? offset 0
>>>>> ????? magic 7f454c4601010100000000000000000002002800
>>>>> ????? mask ffffffffffffff00fffffffffffffffffeffffff
>>>>>
>>>>> After that, I built board-bbb.yml as below, and it succeeded!
>>>>>
>>>>> ????? $ ./kas-docker --isar build kas.yml:board-bbb.yml
>>>>>
>>>>> The root cause of this error is that my machine was not using
>>>>> statically linked user mode qemu binaries?
>>>>
>>>> Well the docker container has the 'qemu-user-static' files
>>>> installed as a
>>>> dependency of qemu-debootstrap. The dynamic linking version would
>>>> not work here,
>>>> because qemu-deboostrap will copy just the one binary to the
>>>> bootstrapped rootfs
>>>> before chrooting into it. The binfmt_misc settings needs to point
>>>> to the qemu
>>>> static binary that was copied to the rootfs for this to work. The
>>>> error of
>>>> course is pretty misleading and stumbled over that very often
>>>> myself.
>>>>
>>>> And what your problem shows as well is that the call of 'update-
>>>> binfmts
>>>> --enable' (which happens in the docker entry point script) does not
>>>> seem to fix
>>>> the path.
>>>
>>> ...which is good to know. Maybe it gets tricked by something being
>>> enabled
>>> already. But I thought I tested this. Anyway, I guess we need to
>>> study that
>>> script /wrt how to achieve some reliable rewriting of the settings.
>>
>> Well you could just call '/var/lib/dpkg/info/qemu-user-static.postinst'
>> from the docker entry point :)
>>
> 
> Ugly... And that call will actually be nop due to how the script works 
> (if it works at all).

Well dpkg-reconfigure would be a bit nicer...

Claudius

> 
> It seems this binfmt installation never worked for the isar-kas
> container:
> 
> builder at 384a365634ab:~$ ls /usr/share/binfmts/
> python2.7? python3.5
> 
> And python2.7 does a file installation+ an update-binfmt --import - 
> rather than a --install - during its postinst.
> 
> "For packages, this is preferable to using the --install option, as
> a format file can be installed without update-binfmts needing to be
> available."
> [update-binfmt man page]
> 
> Jan
> 

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch at denx.de

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error
  2019-03-19  9:26                                 ` Claudius Heine
@ 2019-03-19  9:45                                   ` Jan Kiszka
  0 siblings, 0 replies; 40+ messages in thread
From: Jan Kiszka @ 2019-03-19  9:45 UTC (permalink / raw)
  To: cip-dev

On 19.03.19 10:26, Claudius Heine wrote:
> 
> 
> On 19/03/2019 10.09, Jan Kiszka wrote:
>> On 19.03.19 09:01, Claudius Heine wrote:
>>> On Tue, 2019-03-19 at 08:51 +0100, Jan Kiszka wrote:
>>>> On 19.03.19 08:22, Claudius Heine wrote:
>>>>> Hi Suzuki-san,
>>>>>
>>>>> On 19/03/2019 06.18, akihiro27.suzuki at toshiba.co.jp wrote:
>>>>>> Hi,
>>>>>>
>>>>>>>> That is how my qemu-arm setting looks like. Do you have a
>>>>>>>> differentqemu path?
>>>>>>>>
>>>>>>>> $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>>>>>>>> enabled
>>>>>>>> interpreter /usr/bin/qemu-arm-static
>>>>>>>> flags: OCF
>>>>>>>> offset 0
>>>>>>>> magic 7f454c4601010100000000000000000002002800
>>>>>>>> mask ffffffffffffff00fffffffffffffffffeffffff
>>>>>> My qemu-arm setting is as follows:
>>>>>>
>>>>>> ????? $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>>>>>> ????? enabled
>>>>>> ????? interpreter /usr/bin/qemu-arm
>>>>>> ????? flags: OC
>>>>>> ????? offset 0
>>>>>> ????? magic 7f454c4601010100000000000000000002002800
>>>>>> ????? mask ffffffffffffff00fffffffffffffffffeffffff
>>>>>>
>>>>>> According to this, the interpreter path was not same.
>>>>>> My machine used /usr/bin/qemu-arm but Claudius's machine used
>>>>>> /usr/bin/qemu-arm-static.
>>>>>>
>>>>>> If the first place, my machine didn't have /usr/bin/qemu-arm-
>>>>>> static.
>>>>>> So, I installed qemu-user-static as follows:
>>>>>>
>>>>>> ????? $ sudo aptitude install qemu-user-static
>>>>>> ????? [sudo] password for akihiro:
>>>>>> ????? The following NEW packages will be installed:
>>>>>> ??????? qemu-user-static{b}
>>>>>> ????? 0 packages upgraded, 1 newly installed, 0 to remove and 0
>>>>>> not upgraded.
>>>>>> ????? Need to get 10.0 MB of archives. After unpacking 101 MB will
>>>>>> be used.
>>>>>> ????? The following packages have unmet dependencies:
>>>>>> ?????? qemu-user-static : Conflicts: qemu-user-binfmt but
>>>>>> 1:2.11+dfsg-1ubuntu7.10 is installed
>>>>>> ?????? qemu-user-binfmt : Conflicts: qemu-user-static but
>>>>>> 1:2.11+dfsg-1ubuntu7.10 is to be installed
>>>>>> ????? The following actions will resolve these dependencies:
>>>>>> ?????????? Remove the following packages:
>>>>>> ????? 1)???? qemu-user-binfmt [1:2.11+dfsg-1ubuntu7.10 (bionic-
>>>>>> updates, now)]
>>>>>> ????? Accept this solution? [Y/n/q/?] Y
>>>>>> ????? The following NEW packages will be installed:
>>>>>> ??????? qemu-user-static
>>>>>> ????? The following packages will be REMOVED:
>>>>>> ??????? qemu-user-binfmt{a}
>>>>>> ????? 0 packages upgraded, 1 newly installed, 1 to remove and 0
>>>>>> not upgraded.
>>>>>> ????? Need to get 10.0 MB of archives. After unpacking 101 MB will
>>>>>> be used.
>>>>>> ????? Do you want to continue? [Y/n/?] Y
>>>>>> ????? Get: 1 http://ftp.jaist.ac.jp/pub/Linux/ubuntu bionic-
>>>>>> updates/universe
>>>>>> amd64 qemu-user-static amd64 1:2.11+dfsg-1ubuntu7.10 [10.0 MB]
>>>>>> ????? Fetched 10.0 MB in 1min 5s (155 kB/s)
>>>>>> ????? (Reading database ... 299683 files and directories currently
>>>>>> installed.)
>>>>>> ????? Removing qemu-user-binfmt (1:2.11+dfsg-1ubuntu7.10) ...
>>>>>> ????? Selecting previously unselected package qemu-user-static.
>>>>>> ????? (Reading database ... 299683 files and directories currently
>>>>>> installed.)
>>>>>> ????? Preparing to unpack
>>>>>> .../qemu-user-static_1%3a2.11+dfsg-1ubuntu7.10_amd64.deb ...
>>>>>> ????? Unpacking qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
>>>>>> ????? Setting up qemu-user-static (1:2.11+dfsg-1ubuntu7.10) ...
>>>>>> ????? Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
>>>>>>
>>>>>> After that, I checked my qemu-arm setting.
>>>>>> The interpreter path has been changed to /usr/bin/qemu-arm-static
>>>>>> as below:
>>>>>>
>>>>>> ????? $ cat /proc/sys/fs/binfmt_misc/qemu-arm
>>>>>> ????? enabled
>>>>>> ????? interpreter /usr/bin/qemu-arm-static
>>>>>> ????? flags: OC
>>>>>> ????? offset 0
>>>>>> ????? magic 7f454c4601010100000000000000000002002800
>>>>>> ????? mask ffffffffffffff00fffffffffffffffffeffffff
>>>>>>
>>>>>> After that, I built board-bbb.yml as below, and it succeeded!
>>>>>>
>>>>>> ????? $ ./kas-docker --isar build kas.yml:board-bbb.yml
>>>>>>
>>>>>> The root cause of this error is that my machine was not using
>>>>>> statically linked user mode qemu binaries?
>>>>>
>>>>> Well the docker container has the 'qemu-user-static' files
>>>>> installed as a
>>>>> dependency of qemu-debootstrap. The dynamic linking version would
>>>>> not work here,
>>>>> because qemu-deboostrap will copy just the one binary to the
>>>>> bootstrapped rootfs
>>>>> before chrooting into it. The binfmt_misc settings needs to point
>>>>> to the qemu
>>>>> static binary that was copied to the rootfs for this to work. The
>>>>> error of
>>>>> course is pretty misleading and stumbled over that very often
>>>>> myself.
>>>>>
>>>>> And what your problem shows as well is that the call of 'update-
>>>>> binfmts
>>>>> --enable' (which happens in the docker entry point script) does not
>>>>> seem to fix
>>>>> the path.
>>>>
>>>> ...which is good to know. Maybe it gets tricked by something being
>>>> enabled
>>>> already. But I thought I tested this. Anyway, I guess we need to
>>>> study that
>>>> script /wrt how to achieve some reliable rewriting of the settings.
>>>
>>> Well you could just call '/var/lib/dpkg/info/qemu-user-static.postinst'
>>> from the docker entry point :)
>>>
>>
>> Ugly... And that call will actually be nop due to how the script works (if it 
>> works at all).
> 
> Well dpkg-reconfigure would be a bit nicer...
> 

Checked, this seems to work (lesson learned: never create a test entry in 
binfmt_misc with magic:mask of 0:0).

Will write a kas patch.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error
  2019-03-18 10:18                     ` Jan Kiszka
  2019-03-19  5:18                       ` akihiro27.suzuki at toshiba.co.jp
@ 2019-03-19 10:14                       ` Henning Schild
  2019-03-19 10:27                         ` Jan Kiszka
  1 sibling, 1 reply; 40+ messages in thread
From: Henning Schild @ 2019-03-19 10:14 UTC (permalink / raw)
  To: cip-dev

Am Mon, 18 Mar 2019 11:18:54 +0100
schrieb "[ext] Jan Kiszka" <jan.kiszka@siemens.com>:

> On 18.03.19 11:17, Claudius Heine wrote:
> > Hi,,
> > 
> > On 18/03/2019 11.14, akihiro27.suzuki at toshiba.co.jp wrote:  
> >> Hi,
> >>  
> >>> That's a good hint: Suzuki-san, could you check if binfmt_misc is
> >>> available as
> >>> kernel feature/module on that machine? There may also be some
> >>> warning during the
> >>> container startup.  
> >> I checked it and maybe it is available.
> >>
> >> ???? $ mount | grep binfmt
> >> ???? systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
> >> (rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=18804)
> >> ???? binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
> >> (rw,relatime) $ lsmod | grep binfmt
> >> ???? binfmt_misc??????????? 20480? 1
> >> ???? $ cat /boot/config-4.15.0-46-generic? | grep BINFMT
> >> ???? CONFIG_BINFMT_ELF=y
> >> ???? CONFIG_COMPAT_BINFMT_ELF=y
> >> ???? CONFIG_BINFMT_SCRIPT=y
> >> ???? CONFIG_BINFMT_MISC=m
> >> ???? $ ls /proc/sys/fs/binfmt_misc/
> >> ???? python2.7???? qemu-armeb?????? qemu-mips64????? qemu-ppc64le  
> >> qemu-sparc??????? status
> >> ???? python3.5???? qemu-cris??????? qemu-mips64el??? qemu-riscv32  
> >> qemu-sparc32plus
> >> ???? python3.6???? qemu-hppa??????? qemu-mipsel????? qemu-riscv64
> >> qemu-sparc64 qemu-aarch64? qemu-m68k??????? qemu-ppc
> >> qemu-s390x??? qemu-xtensa qemu-alpha??? qemu-microblaze
> >> qemu-ppc64?????? qemu-sh4????? qemu-xtensaeb qemu-arm
> >> qemu-mips??????? qemu-ppc64abi32? qemu-sh4eb??? register $
> >> cat /proc/sys/fs/binfmt_misc/status enabled  
> > 
> > That is how my qemu-arm setting looks like. Do you have a different
> > qemu path?  
> 
> Even if, it shouldn't be after starting the container: We allow it to
> adjust the system-wide binfmt configuration (one reason for
> --privileged).

We really need a kernel patch for a binfmt cgroup/namespace.

Henning

> Jan
> 
> > 
> > $ cat /proc/sys/fs/binfmt_misc/qemu-arm
> > enabled
> > interpreter /usr/bin/qemu-arm-static
> > flags: OCF
> > offset 0
> > magic 7f454c4601010100000000000000000002002800
> > mask ffffffffffffff00fffffffffffffffffeffffff
> > 
> > regards,
> > Claudius  
> 

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] debootrap error
  2019-03-19 10:14                       ` Henning Schild
@ 2019-03-19 10:27                         ` Jan Kiszka
  0 siblings, 0 replies; 40+ messages in thread
From: Jan Kiszka @ 2019-03-19 10:27 UTC (permalink / raw)
  To: cip-dev

On 19.03.19 11:14, Henning Schild wrote:
> Am Mon, 18 Mar 2019 11:18:54 +0100
> schrieb "[ext] Jan Kiszka" <jan.kiszka@siemens.com>:
> 
>> On 18.03.19 11:17, Claudius Heine wrote:
>>> Hi,,
>>>
>>> On 18/03/2019 11.14, akihiro27.suzuki at toshiba.co.jp wrote:
>>>> Hi,
>>>>   
>>>>> That's a good hint: Suzuki-san, could you check if binfmt_misc is
>>>>> available as
>>>>> kernel feature/module on that machine? There may also be some
>>>>> warning during the
>>>>> container startup.
>>>> I checked it and maybe it is available.
>>>>
>>>>  ???? $ mount | grep binfmt
>>>>  ???? systemd-1 on /proc/sys/fs/binfmt_misc type autofs
>>>> (rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=18804)
>>>>  ???? binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
>>>> (rw,relatime) $ lsmod | grep binfmt
>>>>  ???? binfmt_misc??????????? 20480? 1
>>>>  ???? $ cat /boot/config-4.15.0-46-generic? | grep BINFMT
>>>>  ???? CONFIG_BINFMT_ELF=y
>>>>  ???? CONFIG_COMPAT_BINFMT_ELF=y
>>>>  ???? CONFIG_BINFMT_SCRIPT=y
>>>>  ???? CONFIG_BINFMT_MISC=m
>>>>  ???? $ ls /proc/sys/fs/binfmt_misc/
>>>>  ???? python2.7???? qemu-armeb?????? qemu-mips64????? qemu-ppc64le
>>>> qemu-sparc??????? status
>>>>  ???? python3.5???? qemu-cris??????? qemu-mips64el??? qemu-riscv32
>>>> qemu-sparc32plus
>>>>  ???? python3.6???? qemu-hppa??????? qemu-mipsel????? qemu-riscv64
>>>> qemu-sparc64 qemu-aarch64? qemu-m68k??????? qemu-ppc
>>>> qemu-s390x??? qemu-xtensa qemu-alpha??? qemu-microblaze
>>>> qemu-ppc64?????? qemu-sh4????? qemu-xtensaeb qemu-arm
>>>> qemu-mips??????? qemu-ppc64abi32? qemu-sh4eb??? register $
>>>> cat /proc/sys/fs/binfmt_misc/status enabled
>>>
>>> That is how my qemu-arm setting looks like. Do you have a different
>>> qemu path?
>>
>> Even if, it shouldn't be after starting the container: We allow it to
>> adjust the system-wide binfmt configuration (one reason for
>> --privileged).
> 
> We really need a kernel patch for a binfmt cgroup/namespace.
> 

I don't disagree. I have no idea how much effort that would mean. Maybe it's 
worth asking around on LKML for suggestions.

In any case, it will take 2 year - at least - to have that available in all 
major distros.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-18 10:27         ` Christian Storm
@ 2019-03-22  5:01           ` akihiro27.suzuki at toshiba.co.jp
  2019-03-22 12:37             ` Christian Storm
  0 siblings, 1 reply; 40+ messages in thread
From: akihiro27.suzuki at toshiba.co.jp @ 2019-03-22  5:01 UTC (permalink / raw)
  To: cip-dev

Hi Christian,

Sorry for the late reply.

> > I mounted rootfs with read-only.
> 
> OK, from the diffs it seems that temporary storage directories such as
> /run and /var/tmp are not separate mount points from your roots?
I built the rootfs image by poky with "read-only-rootfs" option like following URL.
<https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#creating-the-root-filesystem>

I think that the temporary storage directories were mounted as tmpfs as follows:

    root at beaglebone:~# df -T
    Filesystem     Type     1K-blocks  Used Available Use% Mounted on
    /dev/root      ext4        135221 75902     49409  61% /
    devtmpfs       devtmpfs    243420     0    243420   0% /dev
    tmpfs          tmpfs       252124   124    252000   1% /run
    tmpfs          tmpfs       252124   252    251872   1% /var/volatile

    root at beaglebone:~# mount
    /dev/mmcblk1p2 on / type ext4 (ro,relatime,data=ordered)
    devtmpfs on /dev type devtmpfs (rw,relatime,size=243420k,nr_inodes=60855,mode=755)
    proc on /proc type proc (rw,relatime)
    sysfs on /sys type sysfs (rw,relatime)
    debugfs on /sys/kernel/debug type debugfs (rw,relatime)
    tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
    tmpfs on /var/volatile type tmpfs (rw,relatime)
    devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
    tmpfs on /var/lib type tmpfs (rw,relatime)

    root at beaglebone:~# ls -l /var
    total 4
    drwxr-xr-x  2 root root 1024 Feb 13 08:41 backups
    drwxr-xr-x  4 root root 1024 Mar 19 07:47 cache
    drwxr-xr-x 10 root root  220 Mar 19 08:20 lib
    drwxr-xr-x  2 root root 1024 Feb 13 08:41 local
    lrwxrwxrwx  1 root root    9 Mar 19 07:47 lock -> /run/lock
    lrwxrwxrwx  1 root root   17 Mar 19 07:47 log -> /var/volatile/log
    lrwxrwxrwx  1 root root    4 Mar 19 07:47 run -> /run
    drwxr-xr-x  4 root root 1024 Mar 19 07:47 spool
    lrwxrwxrwx  1 root root   17 Mar 19 07:47 tmp -> /var/volatile/tmp
    drwxrwxrwt  5 root root  100 Mar 19 08:20 volatile

> > I checked the difference of the rootfs image between before boot and
> after boot,
> > and at least the number of mounts had changed.
> >
> > I attached following log files. I think that 0x434 is a mount count.
> 
> You can use tune2fs -l /dev/<rootdevicenode> and look for
> "Mount count: <some number>" to verify this.
I checked this by tune2fs, and it was correct.

    After the 1st boot:

        root at beaglebone:~# tune2fs -l /dev/mmcblk1p2 | grep "Mount count"
        Mount count:              1

        root at beaglebone:~# hexdump -C -n 2048 /dev/mmcblk1p2 | grep 430
        00000430  81 43 6d 38 01 00 ff ff  53 ef 01 00 01 00 00 00  |.Cm8....S.......|

    After the 2nd boot:

        root at beaglebone:~# tune2fs -l /dev/mmcblk1p2 | grep "Mount count"
        Mount count:              2

        root at beaglebone:~# hexdump -C -n 2048 /dev/mmcblk1p2 | grep 430
        00000430  f4 a4 90 5c 02 00 ff ff  53 ef 01 00 01 00 00 00  |...\....S.......|

    After the 3rd boot:

        root at beaglebone:~# tune2fs -l /dev/mmcblk1p2 | grep "Mount count"
        Mount count:              3

        root at beaglebone:~# hexdump -C -n 2048 /dev/mmcblk1p2 | grep 430
        00000430  63 a6 90 5c 03 00 ff ff  53 ef 01 00 01 00 00 00  |c..\....S.......|

BTW, the values of "Last mount time", "Last write time" and "Lifetime writes" were also changed.

I'm concerned that if the partition which is set to rdiffbase is changed as above,
the binary delta update will be done correctly or not.

> Well, currently nothing written in code. But I can try to elaborate on
> it here:
> Assume that, initially, A/version=1 and B/version=1 is on-disk.
> Then, the delta artifact ART_1->2 := rdiff(version=1 -> version=2) is
> applied to B,
> resulting in A/version=1 and B/version=2 on-disk. Boot into B/version=2,
> which is
> assumably successful.
> Then, when wanting to update A to a version=3 by an artifact
> ART_2->3 := rdiff(version=2 -> version=3), first ART_1->2 has to be
> applied to A and
> thereafter ART_2->3 has to be applied to A.
Thank you for the detailed explanation. 
I was thinking the same way, too.

> > BTW, the warning message after binary delta update was as follows:
> >
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm init: deleted inode referenced: 5040
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm init: deleted inode referenced: 5040
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> 
> Well, my suspicion is that, after a delta-update of the partition, the
> filesystem's metadata is corrupt, i.e., the metdata was partially
> updated by a delta update, resulting in an inconsistent overall state.
> Could you elaborate on the exact steps you performed? Is the diff done
> from/to the right sources? Could as well be that the journal hasn't
> committed the changes... Just a wild guess though...
The exact steps I performed are as follows:

     1. Build rootfs image as v1 by poky by reference to the following article:
        <https://mkrak.org/2018/01/26/updating-embedded-linux-devices-part2/>
     2. Boot BeagleBone Black (BBB) from microSD
     3. Write "core-image-full-cmdline-beaglebone.wic" to /dev/mmcblk1 (eMMC) on BBB
     4. Write "core-image-full-cmdline-beaglebone.ext4" to /dev/mmcblk1p2
     5. Make /dev/mmcblk1p3 partition by fdisk and copy /dev/mmcblk1p2 to /dev/mmcblk1p3
     6. Shutdown BBB and boot from /dev/mmcblk1p3
     7. Add a change to the recipe of poky and rebuild rootfs image as v2
     8. Make a delta image from v1 and v2 by rdiff command
     9. Make swu image from attached sw-description, emmcsetup.lua, and the delta image
    10. Access http://[IP address of BBB]:8080/ by Web browser and upload the above swu image
        (After the update is finished, It reboots automatically)
    11. Check the update is done correctly
        (It boots from /dev/mmcblk1p2 and the rootfs image version is v2)
    12. Do the step of No.10 to update the rootfs image on /dev/mmcblk1p3 to v2
    13. After updating and rebooting, BBB is booted from /dev/mmcblk1p3 and
        the rootfs image version is v2, but the ext4 warning message is shown

If you need more detailed steps, please let me know.

To tell the truth, at first, I set the different partition to "device" and "rdiffbase" field at sw-description.
If "/dev/mmcblk1p2" was set to "device", I set "/dev/mmcblk1p3" to "rdiffbase" -- and vice versa.
When I used this sw-description, the ext4 warning message was shown at the step of No.11.

> What kernel version are you using? There are some issues with v4.19.3
> and v4.19.4 and ext4 filesystems having the same symptoms...
The kernel version is v4.12.28, but I think that it is no relation of this issue...

    root at beaglebone:~# uname -a
    Linux beaglebone 4.12.28-yocto-standard #1 PREEMPT Wed Feb 13 09:33:37 UTC 2019 armv7l armv7l armv7l GNU/Linux

Best regards,
Suzuki

> -----Original Message-----
> From: Christian Storm [mailto:christian.storm at siemens.com]
> Sent: Monday, March 18, 2019 7:28 PM
> To: cip-dev at lists.cip-project.org
> Cc: suzuki akihiro(???? ???? ????????????????)
> <akihiro27.suzuki@toshiba.co.jp>; jan.kiszka at siemens.com;
> SZ.Lin at moxa.com
> Subject: Re: [cip-dev] CIP IRC weekly meeting today
> 
> Hi Suzuki,
> 
> > > > > [Note] we are planning to develop the SWUpdate demo using ISAR,
> any
> > > > > advice or news about how to build SWUpdate on ISAR with the right
> > > > > U-Boot environment?
> > > > >
> > > > > - Regarding SWUpdate we hit an issue that we had not expected
> > > > > before. Suzuki-san was trying to update the standard BBB debian
> > > > > image (or a yocto-made one), but there were many warnings about
> > > > > orphan nodes etc. After some investigation the reason seems to
> be
> > > > > that the rootfs is modified during the first boot (or something
> like
> > > > > that). This is probably one of the biggest problems with updating
> > > > > images instead of files.
> > > >
> > > > Christian, any remarks?
> > >
> > > Hm, did you check that you didn't flash the filesystem you have
> > > currently booted, i.e., are you overwriting the currently running
> > > root filesystem? I have seen such errors when I did this by accident.
> >
> > I mounted rootfs with read-only.
> 
> OK, from the diffs it seems that temporary storage directories such as
> /run and /var/tmp are not separate mount points from your roots?
> 
> > I checked the difference of the rootfs image between before boot and
> after boot,
> > and at least the number of mounts had changed.
> >
> > I attached following log files. I think that 0x434 is a mount count.
> 
> You can use tune2fs -l /dev/<rootdevicenode> and look for
> "Mount count: <some number>" to verify this.
> 
> >
> >     mmcblk1p2-1-2.diff: The difference of rootfs image between 1st boot
> and 2nd boot
> >     mmcblk1p2-2-3.diff: The difference of rootfs image between 2nd boot
> and 3rd boot
> >
> > Do you have some example of A/B update with binary delta update?
> 
> Well, currently nothing written in code. But I can try to elaborate on
> it here:
> Assume that, initially, A/version=1 and B/version=1 is on-disk.
> Then, the delta artifact ART_1->2 := rdiff(version=1 -> version=2) is
> applied to B,
> resulting in A/version=1 and B/version=2 on-disk. Boot into B/version=2,
> which is
> assumably successful.
> Then, when wanting to update A to a version=3 by an artifact
> ART_2->3 := rdiff(version=2 -> version=3), first ART_1->2 has to be
> applied to A and
> thereafter ART_2->3 has to be applied to A.
> 
> Thing is here, you may have to apply a sequence of delta updates to the
> "other" partition so that applying the latest delta to it results in a
> consistent state, i.e., you have to do a "catchup" so that it matches
> the version the latest diff is done against.
> 
> That said, in order to not be forced to store ART_1->2 on the device,
> you can apply ART_1->2 to A once successfully booted into B/version=2.
> Or you can generate and apply ART_1->3 := rdiff(version=1 -> version=3)
> to A.
> Or you can split the update into first downloading and applying ART_1->2
> and the ART_2->3. There are many options, actually, depending on your
> preferences....
> 
> 
> > BTW, the warning message after binary delta update was as follows:
> >
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm init: deleted inode referenced: 5040
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm init: deleted inode referenced: 5040
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> comm mount: deleted inode referenced: 5833
> 
> Well, my suspicion is that, after a delta-update of the partition, the
> filesystem's metadata is corrupt, i.e., the metdata was partially
> updated by a delta update, resulting in an inconsistent overall state.
> Could you elaborate on the exact steps you performed? Is the diff done
> from/to the right sources? Could as well be that the journal hasn't
> committed the changes... Just a wild guess though...
> 
> What kernel version are you using? There are some issues with v4.19.3
> and v4.19.4 and ext4 filesystems having the same symptoms...
> 
> 
> Kind regards,
>    Christian
> 
> --
> Dr. Christian Storm
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Otto-Hahn-Ring 6, 81739 M??nchen, Germany
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sw-description
Type: application/octet-stream
Size: 1178 bytes
Desc: sw-description
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20190322/e3b6a710/attachment-0001.obj>

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-22  5:01           ` akihiro27.suzuki at toshiba.co.jp
@ 2019-03-22 12:37             ` Christian Storm
  2019-03-27  8:25               ` akihiro27.suzuki at toshiba.co.jp
  0 siblings, 1 reply; 40+ messages in thread
From: Christian Storm @ 2019-03-22 12:37 UTC (permalink / raw)
  To: cip-dev

Hi Suzuki,

> > > I mounted rootfs with read-only.
> >
> > OK, from the diffs it seems that temporary storage directories such as
> > /run and /var/tmp are not separate mount points from your roots?
> I built the rootfs image by poky with "read-only-rootfs" option like following URL.
> <https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#creating-the-root-filesystem>

Ah, OK, didn't try that myself yet.


> I think that the temporary storage directories were mounted as tmpfs as follows:
>
>     root at beaglebone:~# df -T
>     Filesystem     Type     1K-blocks  Used Available Use% Mounted on
>     /dev/root      ext4        135221 75902     49409  61% /
>     devtmpfs       devtmpfs    243420     0    243420   0% /dev
>     tmpfs          tmpfs       252124   124    252000   1% /run
>     tmpfs          tmpfs       252124   252    251872   1% /var/volatile
>
>     root at beaglebone:~# mount
>     /dev/mmcblk1p2 on / type ext4 (ro,relatime,data=ordered)
>     devtmpfs on /dev type devtmpfs (rw,relatime,size=243420k,nr_inodes=60855,mode=755)
>     proc on /proc type proc (rw,relatime)
>     sysfs on /sys type sysfs (rw,relatime)
>     debugfs on /sys/kernel/debug type debugfs (rw,relatime)
>     tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
>     tmpfs on /var/volatile type tmpfs (rw,relatime)
>     devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
>     tmpfs on /var/lib type tmpfs (rw,relatime)

Looks good as / is mounted ro. Question is whether this is done via a
remount,ro or whether it's ro right from the start?

To find out what's touching the files you can, e.g., turn on block_dump
$ echo 1 > /proc/sys/vm/block_dump
quite early in the boot process and filter it by grepping dmesg like
$ dmesg | grep dirtied | grep "on sda" | sort


> > > I checked the difference of the rootfs image between before boot and
> > after boot,
> > > and at least the number of mounts had changed.
> > >
> > > I attached following log files. I think that 0x434 is a mount count.
> >
> > You can use tune2fs -l /dev/<rootdevicenode> and look for
> > "Mount count: <some number>" to verify this.
> I checked this by tune2fs, and it was correct.
>
>     After the 1st boot:
>
>         root at beaglebone:~# tune2fs -l /dev/mmcblk1p2 | grep "Mount count"
>         Mount count:              1
>
>         root at beaglebone:~# hexdump -C -n 2048 /dev/mmcblk1p2 | grep 430
>         00000430  81 43 6d 38 01 00 ff ff  53 ef 01 00 01 00 00 00  |.Cm8....S.......|
>
>     After the 2nd boot:
>
>         root at beaglebone:~# tune2fs -l /dev/mmcblk1p2 | grep "Mount count"
>         Mount count:              2
>
>         root at beaglebone:~# hexdump -C -n 2048 /dev/mmcblk1p2 | grep 430
>         00000430  f4 a4 90 5c 02 00 ff ff  53 ef 01 00 01 00 00 00  |...\....S.......|
>
>     After the 3rd boot:
>
>         root at beaglebone:~# tune2fs -l /dev/mmcblk1p2 | grep "Mount count"
>         Mount count:              3
>
>         root at beaglebone:~# hexdump -C -n 2048 /dev/mmcblk1p2 | grep 430
>         00000430  63 a6 90 5c 03 00 ff ff  53 ef 01 00 01 00 00 00  |c..\....S.......|
>
> BTW, the values of "Last mount time", "Last write time" and "Lifetime writes" were also changed.
>
> I'm concerned that if the partition which is set to rdiffbase is changed as above,
> the binary delta update will be done correctly or not.

Well, technically it's just a patch, so if there is a difference in the
two partition images you diff, and be it the filesystem's mount count,
then this will end up in the patch and be applied on the device. If
that's deemed incorrect, then such filesystem metadata has to be
excluded from the diff by means of preprocessing both partition images
so that there's no difference in the metadata that could end up in the
binary patch.

The resulting partition's data is copied from the partition designated
by rdiffbase except for the patch contents that overrule these. So, to
stay in the above example, if the filesystem's mount count is not in the
binary patch, it's taken from rdiffbase.


> > > BTW, the warning message after binary delta update was as follows:
> > >
> > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > comm init: deleted inode referenced: 5040
> > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > comm init: deleted inode referenced: 5040
> > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > comm mount: deleted inode referenced: 5833
> > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > comm mount: deleted inode referenced: 5833
> > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > comm mount: deleted inode referenced: 5833
> > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > comm mount: deleted inode referenced: 5833
> > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > comm mount: deleted inode referenced: 5833
> > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > comm mount: deleted inode referenced: 5833
> > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > comm mount: deleted inode referenced: 5833
> > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > comm mount: deleted inode referenced: 5833
> >
> > Well, my suspicion is that, after a delta-update of the partition, the
> > filesystem's metadata is corrupt, i.e., the metdata was partially
> > updated by a delta update, resulting in an inconsistent overall state.
> > Could you elaborate on the exact steps you performed? Is the diff done
> > from/to the right sources? Could as well be that the journal hasn't
> > committed the changes... Just a wild guess though...
> The exact steps I performed are as follows:
>
>      1. Build rootfs image as v1 by poky by reference to the following article:
>         <https://mkrak.org/2018/01/26/updating-embedded-linux-devices-part2/>
>      2. Boot BeagleBone Black (BBB) from microSD
>      3. Write "core-image-full-cmdline-beaglebone.wic" to /dev/mmcblk1 (eMMC) on BBB
>      4. Write "core-image-full-cmdline-beaglebone.ext4" to /dev/mmcblk1p2
>      5. Make /dev/mmcblk1p3 partition by fdisk and copy /dev/mmcblk1p2 to /dev/mmcblk1p3
>      6. Shutdown BBB and boot from /dev/mmcblk1p3
>      7. Add a change to the recipe of poky and rebuild rootfs image as v2
>      8. Make a delta image from v1 and v2 by rdiff command
>      9. Make swu image from attached sw-description, emmcsetup.lua, and the delta image

Well, in the attached sw-description, you're using
						device = "/dev/mmcblk1p2";
						properties: {
							rdiffbase = ["/dev/mmcblk1p2"];
						};
for "copy1" and
						device = "/dev/mmcblk1p3";
						properties: {
							rdiffbase = ["/dev/mmcblk1p3"];
						};
for "copy2" which basically says use /dev/mmcblk1p{2,3} as rdiffbase
(i.e. copy source) *and* target, hence you're overwriting
/dev/mmcblk1p{2,3} with /dev/mmcblk1p{2,3} + binary patch applied.
If /dev/mmcblk1p{2,3} happens to be mounted, then you'll get the ext4
errors as you're overwriting a mounted filesystem on the block layer.

>     10. Access http://[IP address of BBB]:8080/ by Web browser and upload the above swu image
>         (After the update is finished, It reboots automatically)

Well, how did you instruct SWUpdate to choose "copy1" or "copy2"?
Can you provide the logs of the SWUpdate runs and the information from
which partition you booted while running SWUpdate?

>     11. Check the update is done correctly
>         (It boots from /dev/mmcblk1p2 and the rootfs image version is v2)

Well, I cannot tell about your setup but does
  value = "... setenv bootpart 1:3 ..." 
in "copy2" instruct to boot from /dev/mmcblk1p2? Same question applies to "copy1".

>     12. Do the step of No.10 to update the rootfs image on /dev/mmcblk1p3 to v2
>     13. After updating and rebooting, BBB is booted from /dev/mmcblk1p3 and
>         the rootfs image version is v2, but the ext4 warning message is shown
>
> If you need more detailed steps, please let me know.
>
> To tell the truth, at first, I set the different partition to "device" and "rdiffbase" field at sw-description.
> If "/dev/mmcblk1p2" was set to "device", I set "/dev/mmcblk1p3" to "rdiffbase" -- and vice versa.
> When I used this sw-description, the ext4 warning message was shown at the step of No.11.



Kind regards,
   Christian

-- 
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 M?nchen, Germany

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-22 12:37             ` Christian Storm
@ 2019-03-27  8:25               ` akihiro27.suzuki at toshiba.co.jp
  2019-03-29 13:21                 ` Christian Storm
  0 siblings, 1 reply; 40+ messages in thread
From: akihiro27.suzuki at toshiba.co.jp @ 2019-03-27  8:25 UTC (permalink / raw)
  To: cip-dev

Hi Christian,

I'm sorry to bother you.

> Looks good as / is mounted ro. Question is whether this is done via a
> remount,ro or whether it's ro right from the start?
I didn't remount / with ro manually,
but I have found that /proc/cmdline of the booted BBB includes "rw" as follows:

    root at beaglebone:~# cat /proc/cmdline
    console=ttyO0,115200n8 root=PARTUUID=770dcaeb-02 rw rootfstype=ext4 rootwait

This is because "args_mmc" (the environment variable of u-boot) was not changed
even though I had built the rootfs with "read-only-rootfs" option in poky.
(Although "/" in /etc/fstab was changed from "rw" to "ro" by the option)

The "args_mmc" was as follows:

    args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}

When I changed "rw" on args_mmc to "ro" and booted the BBB, /proc/cmdline was changed as follows:

    root at beaglebone:~# cat /proc/cmdline
    console=ttyO0,115200n8 root=PARTUUID=770dcaeb-02 ro rootfstype=ext4 rootwait

Because of this, the rootfs came to able to be mounted with ro from the start.
Actually, I booted the BBB on several times,
and I checked that there were no changes in the partition.
Of course the binary delta update was successful with this configuration.
It seems for me that this issue has been resolved.
Thank you for your great help!

BTW, I have found the cause of the ext4 error messages.
This is because "/run/utmp" and "/run/mount" were created
before "/" was remounted automatically with ro according to /etc/fstab in the boot process.
Their inodes were created but they were overwritten by zero by the binary delta update.
But the inode of /run, their parent directory, was not overwritten by the update,
and the dentries of "utmp" and "mount" remained inside the inode of /run.
So the ext4 error messages were shown.
Currently, "utmp" and "mount" are not created because I can boot the rootfs with "ro" from the start.
So this issue does not occur.

> Well, how did you instruct SWUpdate to choose "copy1" or "copy2"?
Sorry for the lack of explanation.
I used the method adopted by meta-swupdate-boards.
The important file is the following startup script of swupdate.
<https://github.com/sbabic/meta-swupdate-boards/blob/master/recipes-support/swupdate/swupdate/beaglebone/swupdate>
The script checks the current rootfs partition and executes swupdate with "-e stable,copy{1|2}" as follows:

    root at beaglebone:~# cat /etc/init.d/swupdate
    #! /bin/sh
    -------- (snip) --------
    DAEMON=/usr/bin/swupdate
    -------- (snip) --------
    rootfs=`mount | grep "on / type" | cut -d':' -f 2 | cut -d' ' -f 1`

    if [ $rootfs == '/dev/mmcblk1p2' ];then
            selection="-e stable,copy2"
    else
            selection="-e stable,copy1"
    fi
    -------- (snip) --------
    exec $DAEMON -v -H beaglebone:1.0 ${selection} -f /etc/swupdate.cfg -u "$EXTRA_ARGS" -w "" &
    -------- (snip) --------

If the BBB is booted from /dev/mmcblk1p2, swupdate is executed with "-e stable,copy2" as follows:

    root at beaglebone:~# ps aux | grep swupdate
    root       500  0.0  0.2   1704  1164 ?        S    13:15   0:00 /usr/bin/swupdate-progress -w -p -r
    root       501  0.2  1.2  49456  6504 ?        Sl   13:15   0:00 /usr/bin/swupdate -v -H beaglebone 1.0 -e stable,copy2 -f /etc/swupdate.cfg -u  -w
    root       522  0.2  0.7  31016  3868 ?        Sl   13:15   0:00 /usr/bin/swupdate -v -H beaglebone 1.0 -e stable,copy2 -f /etc/swupdate.cfg -u  -w
    root       524  0.0  0.9  24200  4840 ?        S    13:15   0:00 /usr/bin/swupdate -v -H beaglebone 1.0 -e stable,copy2 -f /etc/swupdate.cfg -u  -w
    root       551  0.0  0.2   1884  1040 ttyO0    S+   13:19   0:00 grep swupdate
    (I'm not sure why /usr/bin/swupdate is running with 3 processes)

If you update now, the rule described in the "copy2" section in sw-description is used.
In the sw-description which was attached in my previous email,
the update target in the "copy2" section is /dev/mmcblk1p3.
Besides, bootcmd_legacy_mmc1 (the environment variable of u-boot)
is modified to use /dev/mmcblk1p3 as the next boot target.
If the BBB is booted from /dev/mmcblk1p3, the "copy1" section is used.
In the "copy1" section, the update and next boot target are /dev/mmcblk1p2.

Best regards,
Suzuki

> -----Original Message-----
> From: cip-dev-bounces at lists.cip-project.org
> [mailto:cip-dev-bounces at lists.cip-project.org] On Behalf Of Christian
> Storm
> Sent: Friday, March 22, 2019 9:37 PM
> To: cip-dev at lists.cip-project.org
> Subject: Re: [cip-dev] CIP IRC weekly meeting today
> 
> Hi Suzuki,
> 
> > > > I mounted rootfs with read-only.
> > >
> > > OK, from the diffs it seems that temporary storage directories such
> as
> > > /run and /var/tmp are not separate mount points from your roots?
> > I built the rootfs image by poky with "read-only-rootfs" option like
> following URL.
> >
> <https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.h
> tml#creating-the-root-filesystem>
> 
> Ah, OK, didn't try that myself yet.
> 
> 
> > I think that the temporary storage directories were mounted as tmpfs
> as follows:
> >
> >     root at beaglebone:~# df -T
> >     Filesystem     Type     1K-blocks  Used Available Use% Mounted
> on
> >     /dev/root      ext4        135221 75902     49409  61% /
> >     devtmpfs       devtmpfs    243420     0    243420   0% /dev
> >     tmpfs          tmpfs       252124   124    252000   1% /run
> >     tmpfs          tmpfs       252124   252    251872   1%
> /var/volatile
> >
> >     root at beaglebone:~# mount
> >     /dev/mmcblk1p2 on / type ext4 (ro,relatime,data=ordered)
> >     devtmpfs on /dev type devtmpfs
> (rw,relatime,size=243420k,nr_inodes=60855,mode=755)
> >     proc on /proc type proc (rw,relatime)
> >     sysfs on /sys type sysfs (rw,relatime)
> >     debugfs on /sys/kernel/debug type debugfs (rw,relatime)
> >     tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
> >     tmpfs on /var/volatile type tmpfs (rw,relatime)
> >     devpts on /dev/pts type devpts
> (rw,relatime,gid=5,mode=620,ptmxmode=000)
> >     tmpfs on /var/lib type tmpfs (rw,relatime)
> 
> Looks good as / is mounted ro. Question is whether this is done via a
> remount,ro or whether it's ro right from the start?
> 
> To find out what's touching the files you can, e.g., turn on block_dump
> $ echo 1 > /proc/sys/vm/block_dump
> quite early in the boot process and filter it by grepping dmesg like
> $ dmesg | grep dirtied | grep "on sda" | sort
> 
> 
> > > > I checked the difference of the rootfs image between before boot
> and
> > > after boot,
> > > > and at least the number of mounts had changed.
> > > >
> > > > I attached following log files. I think that 0x434 is a mount count.
> > >
> > > You can use tune2fs -l /dev/<rootdevicenode> and look for
> > > "Mount count: <some number>" to verify this.
> > I checked this by tune2fs, and it was correct.
> >
> >     After the 1st boot:
> >
> >         root at beaglebone:~# tune2fs -l /dev/mmcblk1p2 | grep "Mount
> count"
> >         Mount count:              1
> >
> >         root at beaglebone:~# hexdump -C -n 2048 /dev/mmcblk1p2 | grep
> 430
> >         00000430  81 43 6d 38 01 00 ff ff  53 ef 01 00 01 00 00 00
> |.Cm8....S.......|
> >
> >     After the 2nd boot:
> >
> >         root at beaglebone:~# tune2fs -l /dev/mmcblk1p2 | grep "Mount
> count"
> >         Mount count:              2
> >
> >         root at beaglebone:~# hexdump -C -n 2048 /dev/mmcblk1p2 | grep
> 430
> >         00000430  f4 a4 90 5c 02 00 ff ff  53 ef 01 00 01 00 00 00
> |...\....S.......|
> >
> >     After the 3rd boot:
> >
> >         root at beaglebone:~# tune2fs -l /dev/mmcblk1p2 | grep "Mount
> count"
> >         Mount count:              3
> >
> >         root at beaglebone:~# hexdump -C -n 2048 /dev/mmcblk1p2 | grep
> 430
> >         00000430  63 a6 90 5c 03 00 ff ff  53 ef 01 00 01 00 00 00
> |c..\....S.......|
> >
> > BTW, the values of "Last mount time", "Last write time" and "Lifetime
> writes" were also changed.
> >
> > I'm concerned that if the partition which is set to rdiffbase is changed
> as above,
> > the binary delta update will be done correctly or not.
> 
> Well, technically it's just a patch, so if there is a difference in the
> two partition images you diff, and be it the filesystem's mount count,
> then this will end up in the patch and be applied on the device. If
> that's deemed incorrect, then such filesystem metadata has to be
> excluded from the diff by means of preprocessing both partition images
> so that there's no difference in the metadata that could end up in the
> binary patch.
> 
> The resulting partition's data is copied from the partition designated
> by rdiffbase except for the patch contents that overrule these. So, to
> stay in the above example, if the filesystem's mount count is not in the
> binary patch, it's taken from rdiffbase.
> 
> 
> > > > BTW, the warning message after binary delta update was as follows:
> > > >
> > > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > > comm init: deleted inode referenced: 5040
> > > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > > comm init: deleted inode referenced: 5040
> > > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > > comm mount: deleted inode referenced: 5833
> > > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > > comm mount: deleted inode referenced: 5833
> > > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > > comm mount: deleted inode referenced: 5833
> > > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > > comm mount: deleted inode referenced: 5833
> > > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > > comm mount: deleted inode referenced: 5833
> > > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > > comm mount: deleted inode referenced: 5833
> > > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > > comm mount: deleted inode referenced: 5833
> > > >     EXT4-fs error (device mmcblk1p3): ext4_lookup:1584: inode #12:
> > > comm mount: deleted inode referenced: 5833
> > >
> > > Well, my suspicion is that, after a delta-update of the partition,
> the
> > > filesystem's metadata is corrupt, i.e., the metdata was partially
> > > updated by a delta update, resulting in an inconsistent overall state.
> > > Could you elaborate on the exact steps you performed? Is the diff
> done
> > > from/to the right sources? Could as well be that the journal hasn't
> > > committed the changes... Just a wild guess though...
> > The exact steps I performed are as follows:
> >
> >      1. Build rootfs image as v1 by poky by reference to the following
> article:
> >
> <https://mkrak.org/2018/01/26/updating-embedded-linux-devices-part2/
> >
> >      2. Boot BeagleBone Black (BBB) from microSD
> >      3. Write "core-image-full-cmdline-beaglebone.wic" to
> /dev/mmcblk1 (eMMC) on BBB
> >      4. Write "core-image-full-cmdline-beaglebone.ext4" to
> /dev/mmcblk1p2
> >      5. Make /dev/mmcblk1p3 partition by fdisk and copy /dev/mmcblk1p2
> to /dev/mmcblk1p3
> >      6. Shutdown BBB and boot from /dev/mmcblk1p3
> >      7. Add a change to the recipe of poky and rebuild rootfs image
> as v2
> >      8. Make a delta image from v1 and v2 by rdiff command
> >      9. Make swu image from attached sw-description, emmcsetup.lua,
> and the delta image
> 
> Well, in the attached sw-description, you're using
> 						device =
> "/dev/mmcblk1p2";
> 						properties: {
> 							rdiffbase =
> ["/dev/mmcblk1p2"];
> 						};
> for "copy1" and
> 						device =
> "/dev/mmcblk1p3";
> 						properties: {
> 							rdiffbase =
> ["/dev/mmcblk1p3"];
> 						};
> for "copy2" which basically says use /dev/mmcblk1p{2,3} as rdiffbase
> (i.e. copy source) *and* target, hence you're overwriting
> /dev/mmcblk1p{2,3} with /dev/mmcblk1p{2,3} + binary patch applied.
> If /dev/mmcblk1p{2,3} happens to be mounted, then you'll get the ext4
> errors as you're overwriting a mounted filesystem on the block layer.
> 
> >     10. Access http://[IP address of BBB]:8080/ by Web browser and
> upload the above swu image
> >         (After the update is finished, It reboots automatically)
> 
> Well, how did you instruct SWUpdate to choose "copy1" or "copy2"?
> Can you provide the logs of the SWUpdate runs and the information from
> which partition you booted while running SWUpdate?
> 
> >     11. Check the update is done correctly
> >         (It boots from /dev/mmcblk1p2 and the rootfs image version is
> v2)
> 
> Well, I cannot tell about your setup but does
>   value = "... setenv bootpart 1:3 ..."
> in "copy2" instruct to boot from /dev/mmcblk1p2? Same question applies
> to "copy1".
> 
> >     12. Do the step of No.10 to update the rootfs image on /dev/mmcblk1p3
> to v2
> >     13. After updating and rebooting, BBB is booted from /dev/mmcblk1p3
> and
> >         the rootfs image version is v2, but the ext4 warning message
> is shown
> >
> > If you need more detailed steps, please let me know.
> >
> > To tell the truth, at first, I set the different partition to "device"
> and "rdiffbase" field at sw-description.
> > If "/dev/mmcblk1p2" was set to "device", I set "/dev/mmcblk1p3" to
> "rdiffbase" -- and vice versa.
> > When I used this sw-description, the ext4 warning message was shown
> at the step of No.11.
> 
> 
> 
> Kind regards,
>    Christian
> 
> --
> Dr. Christian Storm
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Otto-Hahn-Ring 6, 81739 M?nchen, Germany
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-27  8:25               ` akihiro27.suzuki at toshiba.co.jp
@ 2019-03-29 13:21                 ` Christian Storm
  2019-04-01  2:48                   ` akihiro27.suzuki at toshiba.co.jp
  0 siblings, 1 reply; 40+ messages in thread
From: Christian Storm @ 2019-03-29 13:21 UTC (permalink / raw)
  To: cip-dev

Hi Suzuki,


> I'm sorry to bother you.

You're always welcome.


> > Looks good as / is mounted ro. Question is whether this is done via a
> > remount,ro or whether it's ro right from the start?
> I didn't remount / with ro manually,
> but I have found that /proc/cmdline of the booted BBB includes "rw" as follows:
> 
>     root at beaglebone:~# cat /proc/cmdline
>     console=ttyO0,115200n8 root=PARTUUID=770dcaeb-02 rw rootfstype=ext4 rootwait
> 
> This is because "args_mmc" (the environment variable of u-boot) was not changed
> even though I had built the rootfs with "read-only-rootfs" option in poky.
> (Although "/" in /etc/fstab was changed from "rw" to "ro" by the option)
> 
> The "args_mmc" was as follows:
> 
>     args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}
> 
> When I changed "rw" on args_mmc to "ro" and booted the BBB, /proc/cmdline was changed as follows:
> 
>     root at beaglebone:~# cat /proc/cmdline
>     console=ttyO0,115200n8 root=PARTUUID=770dcaeb-02 ro rootfstype=ext4 rootwait
> 
> Because of this, the rootfs came to able to be mounted with ro from the start.
> Actually, I booted the BBB on several times,
> and I checked that there were no changes in the partition.
> Of course the binary delta update was successful with this configuration.
> It seems for me that this issue has been resolved.
> Thank you for your great help!

That sounds good! Glad I could help here.


> BTW, I have found the cause of the ext4 error messages.
> This is because "/run/utmp" and "/run/mount" were created
> before "/" was remounted automatically with ro according to /etc/fstab in the boot process.
> Their inodes were created but they were overwritten by zero by the binary delta update.
> But the inode of /run, their parent directory, was not overwritten by the update,
> and the dentries of "utmp" and "mount" remained inside the inode of /run.
> So the ext4 error messages were shown.
> Currently, "utmp" and "mount" are not created because I can boot the rootfs with "ro" from the start.
> So this issue does not occur.

Sounds reasonable, good to have it sorted out.


> > Well, how did you instruct SWUpdate to choose "copy1" or "copy2"?
> Sorry for the lack of explanation.
> I used the method adopted by meta-swupdate-boards.
> The important file is the following startup script of swupdate.
> <https://github.com/sbabic/meta-swupdate-boards/blob/master/recipes-support/swupdate/swupdate/beaglebone/swupdate>
> The script checks the current rootfs partition and executes swupdate with "-e stable,copy{1|2}" as follows:
> 
>     root at beaglebone:~# cat /etc/init.d/swupdate
>     #! /bin/sh
>     -------- (snip) --------
>     DAEMON=/usr/bin/swupdate
>     -------- (snip) --------
>     rootfs=`mount | grep "on / type" | cut -d':' -f 2 | cut -d' ' -f 1`
> 
>     if [ $rootfs == '/dev/mmcblk1p2' ];then
>             selection="-e stable,copy2"
>     else
>             selection="-e stable,copy1"
>     fi
>     -------- (snip) --------
>     exec $DAEMON -v -H beaglebone:1.0 ${selection} -f /etc/swupdate.cfg -u "$EXTRA_ARGS" -w "" &
>     -------- (snip) --------
> 
> If the BBB is booted from /dev/mmcblk1p2, swupdate is executed with "-e stable,copy2" as follows:
> 
>     root at beaglebone:~# ps aux | grep swupdate
>     root       500  0.0  0.2   1704  1164 ?        S    13:15   0:00 /usr/bin/swupdate-progress -w -p -r
>     root       501  0.2  1.2  49456  6504 ?        Sl   13:15   0:00 /usr/bin/swupdate -v -H beaglebone 1.0 -e stable,copy2 -f /etc/swupdate.cfg -u  -w
>     root       522  0.2  0.7  31016  3868 ?        Sl   13:15   0:00 /usr/bin/swupdate -v -H beaglebone 1.0 -e stable,copy2 -f /etc/swupdate.cfg -u  -w
>     root       524  0.0  0.9  24200  4840 ?        S    13:15   0:00 /usr/bin/swupdate -v -H beaglebone 1.0 -e stable,copy2 -f /etc/swupdate.cfg -u  -w
>     root       551  0.0  0.2   1884  1040 ttyO0    S+   13:19   0:00 grep swupdate
>     (I'm not sure why /usr/bin/swupdate is running with 3 processes)

This is because SWUpdate is designed around a multi-process model with
IPC among the processes via sockets. This has, as one example, the
benefit that one can run the multiple components of SWUpdate with
different privileges. Apart from this, there's a clean interface also
imposed on the code structure which helps the modularization of the
source code.


> If you update now, the rule described in the "copy2" section in sw-description is used.
> In the sw-description which was attached in my previous email,
> the update target in the "copy2" section is /dev/mmcblk1p3.
> Besides, bootcmd_legacy_mmc1 (the environment variable of u-boot)
> is modified to use /dev/mmcblk1p3 as the next boot target.
> If the BBB is booted from /dev/mmcblk1p3, the "copy1" section is used.
> In the "copy1" section, the update and next boot target are /dev/mmcblk1p2.

Ah, OK. This is the "official" in the sense of exemplary implemented way
how to do round-robin A/B firmware update. That said, this is in my very
personal opinion a bit too involved and spread out over too many places.
That was also one reason I brought forward the Lua handler feature that
allows you to implement a handler in Lua. Lua handlers are feature-wise
on par with C handlers by now, i.e., they are equally powerful. So, you
can write a Lua handler that does the target partition round-robin
calculation, flashing, and updating of the bootloader environment in one
place. The sw-description becomes simpler as well since you don't need
to specify the A/B layout there but instead the Lua handler will take
care of this.



Kind regards,
   Christian

-- 
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 M?nchen, Germany

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-03-29 13:21                 ` Christian Storm
@ 2019-04-01  2:48                   ` akihiro27.suzuki at toshiba.co.jp
  2019-04-01  6:48                     ` Christian Storm
  0 siblings, 1 reply; 40+ messages in thread
From: akihiro27.suzuki at toshiba.co.jp @ 2019-04-01  2:48 UTC (permalink / raw)
  To: cip-dev

Hi Christian,

> This is because SWUpdate is designed around a multi-process model with
> IPC among the processes via sockets. This has, as one example, the
> benefit that one can run the multiple components of SWUpdate with
> different privileges. Apart from this, there's a clean interface also
> imposed on the code structure which helps the modularization of the
> source code.
I understand. Thank you for the explanation.

> Ah, OK. This is the "official" in the sense of exemplary implemented way
> how to do round-robin A/B firmware update. That said, this is in my very
> personal opinion a bit too involved and spread out over too many places.
> That was also one reason I brought forward the Lua handler feature that
> allows you to implement a handler in Lua. Lua handlers are feature-wise
> on par with C handlers by now, i.e., they are equally powerful. So, you
> can write a Lua handler that does the target partition round-robin
> calculation, flashing, and updating of the bootloader environment in one
> place. The sw-description becomes simpler as well since you don't need
> to specify the A/B layout there but instead the Lua handler will take
> care of this.
That makes sense.
I thought that the A/B update way adopted by meta-swupdate-boards was
a little difficult to understand and not very flexible.
I would like to use Lua handler to implement the flexible A/B update
which can be used in various situations.

Best regards,
Suzuki

> -----Original Message-----
> From: cip-dev-bounces at lists.cip-project.org
> [mailto:cip-dev-bounces at lists.cip-project.org] On Behalf Of Christian
> Storm
> Sent: Friday, March 29, 2019 10:22 PM
> To: cip-dev at lists.cip-project.org
> Subject: Re: [cip-dev] CIP IRC weekly meeting today
> 
> Hi Suzuki,
> 
> 
> > I'm sorry to bother you.
> 
> You're always welcome.
> 
> 
> > > Looks good as / is mounted ro. Question is whether this is done via
> a
> > > remount,ro or whether it's ro right from the start?
> > I didn't remount / with ro manually,
> > but I have found that /proc/cmdline of the booted BBB includes "rw"
> as follows:
> >
> >     root at beaglebone:~# cat /proc/cmdline
> >     console=ttyO0,115200n8 root=PARTUUID=770dcaeb-02 rw
> rootfstype=ext4 rootwait
> >
> > This is because "args_mmc" (the environment variable of u-boot) was
> not changed
> > even though I had built the rootfs with "read-only-rootfs" option in
> poky.
> > (Although "/" in /etc/fstab was changed from "rw" to "ro" by the option)
> >
> > The "args_mmc" was as follows:
> >
> >     args_mmc=run finduuid;setenv bootargs console=${console}
> ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}
> >
> > When I changed "rw" on args_mmc to "ro" and booted the BBB, /proc/cmdline
> was changed as follows:
> >
> >     root at beaglebone:~# cat /proc/cmdline
> >     console=ttyO0,115200n8 root=PARTUUID=770dcaeb-02 ro
> rootfstype=ext4 rootwait
> >
> > Because of this, the rootfs came to able to be mounted with ro from
> the start.
> > Actually, I booted the BBB on several times,
> > and I checked that there were no changes in the partition.
> > Of course the binary delta update was successful with this
> configuration.
> > It seems for me that this issue has been resolved.
> > Thank you for your great help!
> 
> That sounds good! Glad I could help here.
> 
> 
> > BTW, I have found the cause of the ext4 error messages.
> > This is because "/run/utmp" and "/run/mount" were created
> > before "/" was remounted automatically with ro according to /etc/fstab
> in the boot process.
> > Their inodes were created but they were overwritten by zero by the binary
> delta update.
> > But the inode of /run, their parent directory, was not overwritten by
> the update,
> > and the dentries of "utmp" and "mount" remained inside the inode of
> /run.
> > So the ext4 error messages were shown.
> > Currently, "utmp" and "mount" are not created because I can boot the
> rootfs with "ro" from the start.
> > So this issue does not occur.
> 
> Sounds reasonable, good to have it sorted out.
> 
> 
> > > Well, how did you instruct SWUpdate to choose "copy1" or "copy2"?
> > Sorry for the lack of explanation.
> > I used the method adopted by meta-swupdate-boards.
> > The important file is the following startup script of swupdate.
> >
> <https://github.com/sbabic/meta-swupdate-boards/blob/master/recipes-
> support/swupdate/swupdate/beaglebone/swupdate>
> > The script checks the current rootfs partition and executes swupdate
> with "-e stable,copy{1|2}" as follows:
> >
> >     root at beaglebone:~# cat /etc/init.d/swupdate
> >     #! /bin/sh
> >     -------- (snip) --------
> >     DAEMON=/usr/bin/swupdate
> >     -------- (snip) --------
> >     rootfs=`mount | grep "on / type" | cut -d':' -f 2 | cut -d' ' -f
> 1`
> >
> >     if [ $rootfs == '/dev/mmcblk1p2' ];then
> >             selection="-e stable,copy2"
> >     else
> >             selection="-e stable,copy1"
> >     fi
> >     -------- (snip) --------
> >     exec $DAEMON -v -H beaglebone:1.0 ${selection} -f
> /etc/swupdate.cfg -u "$EXTRA_ARGS" -w "" &
> >     -------- (snip) --------
> >
> > If the BBB is booted from /dev/mmcblk1p2, swupdate is executed with
> "-e stable,copy2" as follows:
> >
> >     root at beaglebone:~# ps aux | grep swupdate
> >     root       500  0.0  0.2   1704  1164 ?        S    13:15
> 0:00 /usr/bin/swupdate-progress -w -p -r
> >     root       501  0.2  1.2  49456  6504 ?        Sl   13:15
> 0:00 /usr/bin/swupdate -v -H beaglebone 1.0 -e stable,copy2 -f
> /etc/swupdate.cfg -u  -w
> >     root       522  0.2  0.7  31016  3868 ?        Sl   13:15
> 0:00 /usr/bin/swupdate -v -H beaglebone 1.0 -e stable,copy2 -f
> /etc/swupdate.cfg -u  -w
> >     root       524  0.0  0.9  24200  4840 ?        S    13:15
> 0:00 /usr/bin/swupdate -v -H beaglebone 1.0 -e stable,copy2 -f
> /etc/swupdate.cfg -u  -w
> >     root       551  0.0  0.2   1884  1040 ttyO0    S+   13:19
> 0:00 grep swupdate
> >     (I'm not sure why /usr/bin/swupdate is running with 3 processes)
> 
> This is because SWUpdate is designed around a multi-process model with
> IPC among the processes via sockets. This has, as one example, the
> benefit that one can run the multiple components of SWUpdate with
> different privileges. Apart from this, there's a clean interface also
> imposed on the code structure which helps the modularization of the
> source code.
> 
> 
> > If you update now, the rule described in the "copy2" section in
> sw-description is used.
> > In the sw-description which was attached in my previous email,
> > the update target in the "copy2" section is /dev/mmcblk1p3.
> > Besides, bootcmd_legacy_mmc1 (the environment variable of u-boot)
> > is modified to use /dev/mmcblk1p3 as the next boot target.
> > If the BBB is booted from /dev/mmcblk1p3, the "copy1" section is used.
> > In the "copy1" section, the update and next boot target are
> /dev/mmcblk1p2.
> 
> Ah, OK. This is the "official" in the sense of exemplary implemented way
> how to do round-robin A/B firmware update. That said, this is in my very
> personal opinion a bit too involved and spread out over too many places.
> That was also one reason I brought forward the Lua handler feature that
> allows you to implement a handler in Lua. Lua handlers are feature-wise
> on par with C handlers by now, i.e., they are equally powerful. So, you
> can write a Lua handler that does the target partition round-robin
> calculation, flashing, and updating of the bootloader environment in one
> place. The sw-description becomes simpler as well since you don't need
> to specify the A/B layout there but instead the Lua handler will take
> care of this.
> 
> 
> 
> Kind regards,
>    Christian
> 
> --
> Dr. Christian Storm
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Otto-Hahn-Ring 6, 81739 M?nchen, Germany
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-04-01  2:48                   ` akihiro27.suzuki at toshiba.co.jp
@ 2019-04-01  6:48                     ` Christian Storm
  2019-04-02  3:50                       ` akihiro27.suzuki at toshiba.co.jp
  0 siblings, 1 reply; 40+ messages in thread
From: Christian Storm @ 2019-04-01  6:48 UTC (permalink / raw)
  To: cip-dev

Hi Suzuki,

> > Ah, OK. This is the "official" in the sense of exemplary implemented way
> > how to do round-robin A/B firmware update. That said, this is in my very
> > personal opinion a bit too involved and spread out over too many places.
> > That was also one reason I brought forward the Lua handler feature that
> > allows you to implement a handler in Lua. Lua handlers are feature-wise
> > on par with C handlers by now, i.e., they are equally powerful. So, you
> > can write a Lua handler that does the target partition round-robin
> > calculation, flashing, and updating of the bootloader environment in one
> > place. The sw-description becomes simpler as well since you don't need
> > to specify the A/B layout there but instead the Lua handler will take
> > care of this.
> That makes sense.
> I thought that the A/B update way adopted by meta-swupdate-boards was
> a little difficult to understand and not very flexible.
> I would like to use Lua handler to implement the flexible A/B update
> which can be used in various situations.

OK, then I'd propose having a meeting about this so that I can explain how this
variant works and how we make use of it. When do you think you'll come to this
point so that a meeting makes sense?


Kind regards,
   Christian

-- 
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 M?nchen, Germany

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-04-01  6:48                     ` Christian Storm
@ 2019-04-02  3:50                       ` akihiro27.suzuki at toshiba.co.jp
  2019-04-02  6:45                         ` Christian Storm
  0 siblings, 1 reply; 40+ messages in thread
From: akihiro27.suzuki at toshiba.co.jp @ 2019-04-02  3:50 UTC (permalink / raw)
  To: cip-dev

Hi Christian,

> > > Ah, OK. This is the "official" in the sense of exemplary implemented way
> > > how to do round-robin A/B firmware update. That said, this is in my very
> > > personal opinion a bit too involved and spread out over too many places.
> > > That was also one reason I brought forward the Lua handler feature that
> > > allows you to implement a handler in Lua. Lua handlers are feature-wise
> > > on par with C handlers by now, i.e., they are equally powerful. So, you
> > > can write a Lua handler that does the target partition round-robin
> > > calculation, flashing, and updating of the bootloader environment in one
> > > place. The sw-description becomes simpler as well since you don't need
> > > to specify the A/B layout there but instead the Lua handler will take
> > > care of this.
> > That makes sense.
> > I thought that the A/B update way adopted by meta-swupdate-boards was
> > a little difficult to understand and not very flexible.
> > I would like to use Lua handler to implement the flexible A/B update
> > which can be used in various situations.
> 
> OK, then I'd propose having a meeting about this so that I can explain how this
> variant works and how we make use of it. When do you think you'll come to this
> point so that a meeting makes sense?

Thank you for your proposal.
Just in case, please let me make sure the meaning of your proposal.

Which one did you mean?

  (A) In a meeting, you will tell me about how to use Lua handler for the A/B update.
  (B) I should have a meeting after I implemented the A/B update by using Lua handler.

If you meant (A), I'd like some time, 1 or 2 weeks, to try Lua before the meeting
because I haven't used it.

If you meant (B), I will have a meeting after implementing it,
but maybe the implementation (and tests) will take at least 1 month.

Best regards,
Suzuki


> -----Original Message-----
> From: cip-dev-bounces at lists.cip-project.org
> [mailto:cip-dev-bounces at lists.cip-project.org] On Behalf Of Christian
> Storm
> Sent: Monday, April 01, 2019 3:49 PM
> To: cip-dev at lists.cip-project.org
> Subject: Re: [cip-dev] CIP IRC weekly meeting today
> 
> Hi Suzuki,
> 
> > > Ah, OK. This is the "official" in the sense of exemplary implemented way
> > > how to do round-robin A/B firmware update. That said, this is in my very
> > > personal opinion a bit too involved and spread out over too many places.
> > > That was also one reason I brought forward the Lua handler feature that
> > > allows you to implement a handler in Lua. Lua handlers are feature-wise
> > > on par with C handlers by now, i.e., they are equally powerful. So, you
> > > can write a Lua handler that does the target partition round-robin
> > > calculation, flashing, and updating of the bootloader environment in one
> > > place. The sw-description becomes simpler as well since you don't need
> > > to specify the A/B layout there but instead the Lua handler will take
> > > care of this.
> > That makes sense.
> > I thought that the A/B update way adopted by meta-swupdate-boards was
> > a little difficult to understand and not very flexible.
> > I would like to use Lua handler to implement the flexible A/B update
> > which can be used in various situations.
> 
> OK, then I'd propose having a meeting about this so that I can explain
> how this
> variant works and how we make use of it. When do you think you'll come
> to this
> point so that a meeting makes sense?
> 
> 
> Kind regards,
>    Christian
> 
> --
> Dr. Christian Storm
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Otto-Hahn-Ring 6, 81739 M?nchen, Germany
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-04-02  3:50                       ` akihiro27.suzuki at toshiba.co.jp
@ 2019-04-02  6:45                         ` Christian Storm
  2019-04-02  8:14                           ` akihiro27.suzuki at toshiba.co.jp
  2019-04-26 10:34                           ` akihiro27.suzuki at toshiba.co.jp
  0 siblings, 2 replies; 40+ messages in thread
From: Christian Storm @ 2019-04-02  6:45 UTC (permalink / raw)
  To: cip-dev

Hi Suzuki,

> > > > Ah, OK. This is the "official" in the sense of exemplary implemented way
> > > > how to do round-robin A/B firmware update. That said, this is in my very
> > > > personal opinion a bit too involved and spread out over too many places.
> > > > That was also one reason I brought forward the Lua handler feature that
> > > > allows you to implement a handler in Lua. Lua handlers are feature-wise
> > > > on par with C handlers by now, i.e., they are equally powerful. So, you
> > > > can write a Lua handler that does the target partition round-robin
> > > > calculation, flashing, and updating of the bootloader environment in one
> > > > place. The sw-description becomes simpler as well since you don't need
> > > > to specify the A/B layout there but instead the Lua handler will take
> > > > care of this.
> > > That makes sense.
> > > I thought that the A/B update way adopted by meta-swupdate-boards was
> > > a little difficult to understand and not very flexible.
> > > I would like to use Lua handler to implement the flexible A/B update
> > > which can be used in various situations.
> > 
> > OK, then I'd propose having a meeting about this so that I can explain how this
> > variant works and how we make use of it. When do you think you'll come to this
> > point so that a meeting makes sense?
> 
> Thank you for your proposal.
> Just in case, please let me make sure the meaning of your proposal.
> 
> Which one did you mean?
> 
>   (A) In a meeting, you will tell me about how to use Lua handler for the A/B update.
>   (B) I should have a meeting after I implemented the A/B update by using Lua handler.
> 
> If you meant (A), I'd like some time, 1 or 2 weeks, to try Lua before the meeting
> because I haven't used it.
> 
> If you meant (B), I will have a meeting after implementing it,
> but maybe the implementation (and tests) will take at least 1 month.

I meant (A) to spare you (re)exploring the path I went :)
I'd like to show off some features you may find useful along the way as
well. Just let me know when you're ready and I'll setup the metting
then.


Kind regards,
   Christian

-- 
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 M?nchen, Germany

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-04-02  6:45                         ` Christian Storm
@ 2019-04-02  8:14                           ` akihiro27.suzuki at toshiba.co.jp
  2019-04-26 10:34                           ` akihiro27.suzuki at toshiba.co.jp
  1 sibling, 0 replies; 40+ messages in thread
From: akihiro27.suzuki at toshiba.co.jp @ 2019-04-02  8:14 UTC (permalink / raw)
  To: cip-dev

Hi Christian,

> > > OK, then I'd propose having a meeting about this so that I can explain how this
> > > variant works and how we make use of it. When do you think you'll come to this
> > > point so that a meeting makes sense?
> >
> > Thank you for your proposal.
> > Just in case, please let me make sure the meaning of your proposal.
> >
> > Which one did you mean?
> >
> >   (A) In a meeting, you will tell me about how to use Lua handler for the A/B update.
> >   (B) I should have a meeting after I implemented the A/B update by using Lua handler.
> >
> > If you meant (A), I'd like some time, 1 or 2 weeks, to try Lua before the meeting
> > because I haven't used it.
> >
> > If you meant (B), I will have a meeting after implementing it,
> > but maybe the implementation (and tests) will take at least 1 month.
> 
> I meant (A) to spare you (re)exploring the path I went :)
> I'd like to show off some features you may find useful along the way as
> well. Just let me know when you're ready and I'll setup the metting
> then.

OK, I see. Thanks a lot!
I'll let you know when I'm ready.

Best regards,
Suzuki


> -----Original Message-----
> From: cip-dev-bounces at lists.cip-project.org [mailto:cip-dev-bounces at lists.cip-project.org] On Behalf Of Christian
> Storm
> Sent: Tuesday, April 02, 2019 3:46 PM
> To: cip-dev at lists.cip-project.org
> Subject: Re: [cip-dev] CIP IRC weekly meeting today
> 
> Hi Suzuki,
> 
> > > > > Ah, OK. This is the "official" in the sense of exemplary implemented way
> > > > > how to do round-robin A/B firmware update. That said, this is in my very
> > > > > personal opinion a bit too involved and spread out over too many places.
> > > > > That was also one reason I brought forward the Lua handler feature that
> > > > > allows you to implement a handler in Lua. Lua handlers are feature-wise
> > > > > on par with C handlers by now, i.e., they are equally powerful. So, you
> > > > > can write a Lua handler that does the target partition round-robin
> > > > > calculation, flashing, and updating of the bootloader environment in one
> > > > > place. The sw-description becomes simpler as well since you don't need
> > > > > to specify the A/B layout there but instead the Lua handler will take
> > > > > care of this.
> > > > That makes sense.
> > > > I thought that the A/B update way adopted by meta-swupdate-boards was
> > > > a little difficult to understand and not very flexible.
> > > > I would like to use Lua handler to implement the flexible A/B update
> > > > which can be used in various situations.
> > >
> > > OK, then I'd propose having a meeting about this so that I can explain how this
> > > variant works and how we make use of it. When do you think you'll come to this
> > > point so that a meeting makes sense?
> >
> > Thank you for your proposal.
> > Just in case, please let me make sure the meaning of your proposal.
> >
> > Which one did you mean?
> >
> >   (A) In a meeting, you will tell me about how to use Lua handler for the A/B update.
> >   (B) I should have a meeting after I implemented the A/B update by using Lua handler.
> >
> > If you meant (A), I'd like some time, 1 or 2 weeks, to try Lua before the meeting
> > because I haven't used it.
> >
> > If you meant (B), I will have a meeting after implementing it,
> > but maybe the implementation (and tests) will take at least 1 month.
> 
> I meant (A) to spare you (re)exploring the path I went :)
> I'd like to show off some features you may find useful along the way as
> well. Just let me know when you're ready and I'll setup the metting
> then.
> 
> 
> Kind regards,
>    Christian
> 
> --
> Dr. Christian Storm
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Otto-Hahn-Ring 6, 81739 M?nchen, Germany
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

^ permalink raw reply	[flat|nested] 40+ messages in thread
* [cip-dev] CIP IRC weekly meeting today
  2019-04-02  6:45                         ` Christian Storm
  2019-04-02  8:14                           ` akihiro27.suzuki at toshiba.co.jp
@ 2019-04-26 10:34                           ` akihiro27.suzuki at toshiba.co.jp
  1 sibling, 0 replies; 40+ messages in thread
From: akihiro27.suzuki at toshiba.co.jp @ 2019-04-26 10:34 UTC (permalink / raw)
  To: cip-dev

Hi Christian,

Sorry for my late reply.
I was a little busy with work unrelated to CIP.

I tried Lua handler and I was able to understand it a little.
I referred to the following example.
<https://github.com/andi8086/meta-iot2000/blob/iot2000-ebg-swu/meta-iot2000-example/recipes-support/swupdate/swupdate/swupdate_handlers.lua>

I made "sw-description" and "swupdate_handlers.lua" for BBB.
They are working fine for now.
BTW, I needed to patch "0001-Fix-Lua-handler-issue.patch" to SWUpdate.

I think I'm ready, so I'd like to have a meeting with you.
However, Japan has consecutive national holidays from tomorrow to May 6th.
Could you please wait until the holidays end?
After the holidays, I'll let you know my several convenient time for the meeting.

Best regards,
Suzuki

> -----Original Message-----
> From: suzuki akihiro(???? ???? ????????????????)
> Sent: Tuesday, April 02, 2019 5:14 PM
> To: Christian Storm <christian.storm@siemens.com>; cip-dev at lists.cip-project.org
> Subject: RE: [cip-dev] CIP IRC weekly meeting today
> 
> Hi Christian,
> 
> > > > OK, then I'd propose having a meeting about this so that I can explain how this
> > > > variant works and how we make use of it. When do you think you'll come to this
> > > > point so that a meeting makes sense?
> > >
> > > Thank you for your proposal.
> > > Just in case, please let me make sure the meaning of your proposal.
> > >
> > > Which one did you mean?
> > >
> > >   (A) In a meeting, you will tell me about how to use Lua handler for the A/B update.
> > >   (B) I should have a meeting after I implemented the A/B update by using Lua handler.
> > >
> > > If you meant (A), I'd like some time, 1 or 2 weeks, to try Lua before the meeting
> > > because I haven't used it.
> > >
> > > If you meant (B), I will have a meeting after implementing it,
> > > but maybe the implementation (and tests) will take at least 1 month.
> >
> > I meant (A) to spare you (re)exploring the path I went :)
> > I'd like to show off some features you may find useful along the way as
> > well. Just let me know when you're ready and I'll setup the metting
> > then.
> 
> OK, I see. Thanks a lot!
> I'll let you know when I'm ready.
> 
> Best regards,
> Suzuki
> 
> 
> > -----Original Message-----
> > From: cip-dev-bounces at lists.cip-project.org [mailto:cip-dev-bounces at lists.cip-project.org] On Behalf Of Christian
> > Storm
> > Sent: Tuesday, April 02, 2019 3:46 PM
> > To: cip-dev at lists.cip-project.org
> > Subject: Re: [cip-dev] CIP IRC weekly meeting today
> >
> > Hi Suzuki,
> >
> > > > > > Ah, OK. This is the "official" in the sense of exemplary implemented way
> > > > > > how to do round-robin A/B firmware update. That said, this is in my very
> > > > > > personal opinion a bit too involved and spread out over too many places.
> > > > > > That was also one reason I brought forward the Lua handler feature that
> > > > > > allows you to implement a handler in Lua. Lua handlers are feature-wise
> > > > > > on par with C handlers by now, i.e., they are equally powerful. So, you
> > > > > > can write a Lua handler that does the target partition round-robin
> > > > > > calculation, flashing, and updating of the bootloader environment in one
> > > > > > place. The sw-description becomes simpler as well since you don't need
> > > > > > to specify the A/B layout there but instead the Lua handler will take
> > > > > > care of this.
> > > > > That makes sense.
> > > > > I thought that the A/B update way adopted by meta-swupdate-boards was
> > > > > a little difficult to understand and not very flexible.
> > > > > I would like to use Lua handler to implement the flexible A/B update
> > > > > which can be used in various situations.
> > > >
> > > > OK, then I'd propose having a meeting about this so that I can explain how this
> > > > variant works and how we make use of it. When do you think you'll come to this
> > > > point so that a meeting makes sense?
> > >
> > > Thank you for your proposal.
> > > Just in case, please let me make sure the meaning of your proposal.
> > >
> > > Which one did you mean?
> > >
> > >   (A) In a meeting, you will tell me about how to use Lua handler for the A/B update.
> > >   (B) I should have a meeting after I implemented the A/B update by using Lua handler.
> > >
> > > If you meant (A), I'd like some time, 1 or 2 weeks, to try Lua before the meeting
> > > because I haven't used it.
> > >
> > > If you meant (B), I will have a meeting after implementing it,
> > > but maybe the implementation (and tests) will take at least 1 month.
> >
> > I meant (A) to spare you (re)exploring the path I went :)
> > I'd like to show off some features you may find useful along the way as
> > well. Just let me know when you're ready and I'll setup the metting
> > then.
> >
> >
> > Kind regards,
> >    Christian
> >
> > --
> > Dr. Christian Storm
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Otto-Hahn-Ring 6, 81739 M??nchen, Germany
> > _______________________________________________
> > cip-dev mailing list
> > cip-dev at lists.cip-project.org
> > https://lists.cip-project.org/mailman/listinfo/cip-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sw-description
Type: application/octet-stream
Size: 201 bytes
Desc: sw-description
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20190426/2734cf4a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: swupdate_handlers.lua
Type: application/octet-stream
Size: 2294 bytes
Desc: swupdate_handlers.lua
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20190426/2734cf4a/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-Lua-handler-issue.patch
Type: application/octet-stream
Size: 1478 bytes
Desc: 0001-Fix-Lua-handler-issue.patch
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20190426/2734cf4a/attachment-0002.obj>

^ permalink raw reply	[flat|nested] 40+ messages in thread
end of thread, other threads:[~2019-04-26 10:34 UTC | newest]

Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-14  1:55 [cip-dev] CIP IRC weekly meeting today SZ Lin (林上智)
2019-03-14  4:38 ` Nobuhiro Iwamatsu
2019-03-14  7:26 ` daniel.sangorrin at toshiba.co.jp
2019-03-14  9:19   ` Chris Paterson
2019-03-14  9:23   ` Patryk Mungai Ndungu
2019-03-15  9:24   ` Jan Kiszka
2019-03-15  9:48     ` akihiro27.suzuki at toshiba.co.jp
2019-03-15 10:50       ` Jan Kiszka
2019-03-18  1:42         ` akihiro27.suzuki at toshiba.co.jp
2019-03-18  9:05           ` [cip-dev] debootrap error (was: Re: CIP IRC weekly meeting today) Jan Kiszka
2019-03-18  9:11             ` Claudius Heine
2019-03-18  9:39               ` [cip-dev] debootrap error Jan Kiszka
2019-03-18 10:14                 ` akihiro27.suzuki at toshiba.co.jp
2019-03-18 10:17                   ` Claudius Heine
2019-03-18 10:18                     ` Jan Kiszka
2019-03-19  5:18                       ` akihiro27.suzuki at toshiba.co.jp
2019-03-19  7:22                         ` Claudius Heine
2019-03-19  7:51                           ` Jan Kiszka
2019-03-19  8:01                             ` Claudius Heine
2019-03-19  9:09                               ` Jan Kiszka
2019-03-19  9:26                                 ` Claudius Heine
2019-03-19  9:45                                   ` Jan Kiszka
2019-03-19 10:14                       ` Henning Schild
2019-03-19 10:27                         ` Jan Kiszka
2019-03-18  2:53         ` [cip-dev] CIP IRC weekly meeting today akihiro27.suzuki at toshiba.co.jp
2019-03-18  8:56           ` [cip-dev] debootstrap error (was: Re: CIP IRC weekly meeting today) Jan Kiszka
2019-03-18  8:59             ` akihiro27.suzuki at toshiba.co.jp
2019-03-18  8:42     ` [cip-dev] CIP IRC weekly meeting today Christian Storm
2019-03-18  9:14       ` akihiro27.suzuki at toshiba.co.jp
2019-03-18 10:27         ` Christian Storm
2019-03-22  5:01           ` akihiro27.suzuki at toshiba.co.jp
2019-03-22 12:37             ` Christian Storm
2019-03-27  8:25               ` akihiro27.suzuki at toshiba.co.jp
2019-03-29 13:21                 ` Christian Storm
2019-04-01  2:48                   ` akihiro27.suzuki at toshiba.co.jp
2019-04-01  6:48                     ` Christian Storm
2019-04-02  3:50                       ` akihiro27.suzuki at toshiba.co.jp
2019-04-02  6:45                         ` Christian Storm
2019-04-02  8:14                           ` akihiro27.suzuki at toshiba.co.jp
2019-04-26 10:34                           ` akihiro27.suzuki at toshiba.co.jp

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).