* [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] 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] 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] 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-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] 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] 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] 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] 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] 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).