From: christian.storm@siemens.com (Christian Storm)
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] CIP IRC weekly meeting today
Date: Mon, 18 Mar 2019 11:27:56 +0100 [thread overview]
Message-ID: <20190318102756.kvqvsy4yxzl3qta3@MD1ZFJVC.ad001.siemens.net> (raw)
In-Reply-To: <TY2PR01MB514642E9DF502D9F239C224AD9470@TY2PR01MB5146.jpnprd01.prod.outlook.com>
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 prev parent reply other threads:[~2019-03-18 10:27 UTC|newest]
Thread overview: 264+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2021-05-27 1:09 masashi.kudo
2021-05-27 7:11 ` Hung Tran
2021-05-20 2:45 masashi.kudo
2021-05-20 8:59 ` Pavel Machek
2021-05-20 11:27 ` Pavel Machek
2021-05-12 23:26 masashi.kudo
2021-05-06 0:59 masashi.kudo
2021-04-22 2:00 masashi.kudo
2021-04-22 8:29 ` Nobuhiro Iwamatsu
2021-04-15 0:05 masashi.kudo
2021-04-08 1:26 masashi.kudo
2021-04-01 0:56 masashi.kudo
2021-03-25 0:02 masashi.kudo
2021-03-25 6:52 ` Nobuhiro Iwamatsu
2021-03-25 8:22 ` Kento Yoshida
2021-03-18 2:50 masashi.kudo
2021-03-18 7:25 ` Pavel Machek
2021-03-18 7:47 ` Kento Yoshida
2021-03-11 0:22 masashi.kudo
2021-03-11 8:06 ` Nobuhiro Iwamatsu
2021-03-04 2:03 masashi.kudo
2021-03-04 6:57 ` Kento Yoshida
2021-02-25 1:37 masashi.kudo
2021-02-25 2:23 ` Kento Yoshida
2021-02-18 0:09 masashi.kudo
2021-02-18 8:46 ` Chen-Yu Tsai (Moxa)
2021-02-11 1:03 masashi.kudo
2021-02-11 9:20 ` Pavel Machek
2021-02-11 9:34 ` masashi.kudo
2021-02-04 0:03 masashi.kudo
2021-02-04 7:57 ` Nobuhiro Iwamatsu
2021-01-27 23:45 masashi.kudo
2021-01-21 1:22 masashi.kudo
2021-01-21 8:08 ` Kento Yoshida
2021-01-14 0:21 masashi.kudo
2021-01-07 0:49 masashi.kudo
2020-12-17 2:09 masashi.kudo
2020-12-17 8:27 ` Pavel Machek
2020-12-10 1:21 masashi.kudo
2020-12-02 23:55 masashi.kudo
2020-11-26 0:25 masashi.kudo
2020-11-19 0:19 masashi.kudo
2020-11-19 3:20 ` Nobuhiro Iwamatsu
2020-11-19 3:22 ` masashi.kudo
2020-11-12 0:51 masashi.kudo
2020-11-04 23:20 masashi.kudo
2020-11-05 1:46 ` Chen-Yu Tsai (Moxa)
2020-11-05 7:55 ` Pavel Machek
2020-11-05 8:00 ` masashi.kudo
2020-10-21 23:50 masashi.kudo
2020-10-15 0:17 masashi.kudo
2020-10-08 0:56 masashi.kudo
2020-10-08 2:40 ` Kento Yoshida
2020-10-08 5:46 ` Nobuhiro Iwamatsu
2020-10-08 8:19 ` Chen-Yu Tsai (Moxa)
2020-10-01 0:27 masashi.kudo
2020-10-01 4:37 ` Chen-Yu Tsai (Moxa)
2020-10-01 5:37 ` Chris Paterson
2020-10-01 8:11 ` Pavel Machek
2020-09-24 0:58 masashi.kudo
2020-09-24 2:42 ` Akihiro Suzuki
2020-09-17 1:20 masashi.kudo
2020-09-17 6:58 ` Akihiro Suzuki
2020-09-10 0:23 masashi.kudo
2020-09-10 7:08 ` Nobuhiro Iwamatsu
2020-09-03 0:09 masashi.kudo
2020-08-27 0:58 masashi.kudo
2020-08-27 5:04 ` Akihiro Suzuki
2020-08-20 0:21 masashi.kudo
2020-08-05 23:51 masashi.kudo
2020-08-06 2:42 ` Akihiro Suzuki
2020-07-30 1:56 masashi.kudo
2020-07-30 8:39 ` Akihiro Suzuki
2020-07-23 2:58 masashi.kudo
2020-07-23 7:32 ` Pavel Machek
2020-07-24 8:27 ` Chris Paterson
2020-07-16 1:29 masashi.kudo
2020-07-16 6:11 ` Chen-Yu Tsai (Moxa)
2020-07-16 8:27 ` Nobuhiro Iwamatsu
2020-07-08 22:42 masashi.kudo
2020-07-09 7:06 ` Pavel Machek
2020-07-01 22:53 masashi.kudo
2020-07-02 8:43 ` Chris Paterson
2020-07-02 8:49 ` masashi.kudo
2020-06-25 1:53 masashi.kudo
2020-06-25 7:00 ` Pavel Machek
2020-06-25 7:03 ` masashi.kudo
2020-06-18 0:20 masashi.kudo
2020-06-18 2:12 ` masashi.kudo
2020-06-18 7:19 ` Nobuhiro Iwamatsu
2020-06-18 7:27 ` masashi.kudo
2020-06-10 23:55 masashi.kudo
2020-06-11 11:23 ` Pavel Machek
2020-06-11 11:47 ` masashi.kudo
2020-06-04 2:38 masashi.kudo
2020-06-04 6:58 ` Akihiro Suzuki
2020-06-04 7:12 ` masashi.kudo
2020-05-28 1:26 masashi.kudo
2020-05-21 0:36 masashi.kudo
2020-05-21 6:08 ` Nobuhiro Iwamatsu
2020-05-21 7:12 ` masashi.kudo
2020-05-13 23:27 masashi.kudo
2020-05-06 22:28 masashi.kudo
2020-04-30 0:56 masashi.kudo
2020-04-30 7:53 ` Nobuhiro Iwamatsu
2020-04-30 7:59 ` [cip-dev] " masashi.kudo
2020-04-30 8:31 ` Akihiro Suzuki
2020-04-30 8:33 ` masashi.kudo
2020-04-23 0:06 masashi.kudo
2020-04-23 8:41 ` Akihiro Suzuki
2020-04-23 8:43 ` masashi.kudo
2020-04-16 2:02 masashi.kudo
2020-04-16 7:21 ` punit1.agrawal
2020-04-16 7:28 ` masashi.kudo
2020-04-16 8:15 ` Chris Paterson
2020-04-16 8:18 ` masashi.kudo
2020-04-08 23:24 masashi.kudo
2020-04-02 0:30 masashi.kudo
2020-04-02 8:19 ` nobuhiro1.iwamatsu
2020-04-02 8:22 ` masashi.kudo
2020-03-25 22:52 masashi.kudo
2020-03-18 22:35 masashi.kudo
2020-03-19 8:17 ` nobuhiro1.iwamatsu
2020-03-19 8:20 ` masashi.kudo
2020-03-11 23:42 masashi.kudo
2020-03-05 0:28 masashi.kudo
2020-02-19 23:09 masashi.kudo
2020-02-13 1:31 masashi.kudo at cybertrust.co.jp
2020-02-05 22:58 masashi.kudo at cybertrust.co.jp
2020-02-06 7:25 ` nobuhiro1.iwamatsu at toshiba.co.jp
2020-02-06 8:04 ` masashi.kudo at cybertrust.co.jp
2020-01-29 22:54 masashi.kudo at cybertrust.co.jp
2020-01-30 7:35 ` Chris Paterson
2020-01-30 8:05 ` masashi.kudo at cybertrust.co.jp
2020-01-30 13:29 ` masashi.kudo at cybertrust.co.jp
2020-01-22 22:55 masashi.kudo at cybertrust.co.jp
2020-01-23 8:33 ` Chen-Yu Tsai
2020-01-23 8:35 ` masashi.kudo at cybertrust.co.jp
2020-01-15 23:16 masashi.kudo at cybertrust.co.jp
2020-01-16 8:53 ` nobuhiro1.iwamatsu at toshiba.co.jp
2020-01-09 0:56 masashi.kudo at cybertrust.co.jp
2019-12-25 22:52 masashi.kudo at cybertrust.co.jp
2019-12-18 23:39 masashi.kudo at cybertrust.co.jp
2019-12-12 0:59 masashi.kudo at cybertrust.co.jp
2019-12-12 7:04 ` nobuhiro1.iwamatsu at toshiba.co.jp
2019-12-12 9:50 ` masashi.kudo at cybertrust.co.jp
2019-12-12 12:56 ` masashi.kudo at cybertrust.co.jp
2019-12-05 0:28 masashi.kudo at cybertrust.co.jp
2019-11-28 1:51 SZ Lin (林上智)
2019-11-21 0:30 SZ Lin (林上智)
2019-11-21 7:38 ` Nobuhiro Iwamatsu
2019-11-21 8:53 ` Chris Paterson
2019-11-14 1:41 SZ Lin (林上智)
2019-11-07 1:56 SZ Lin (林上智)
2019-11-07 7:15 ` nobuhiro1.iwamatsu at toshiba.co.jp
2019-11-07 9:17 ` SZ Lin (林上智)
2019-10-24 1:55 SZ Lin (林上智)
2019-10-24 5:50 ` masashi.kudo at cybertrust.co.jp
2019-10-24 5:53 ` SZ Lin (林上智)
2019-10-24 6:01 ` masashi.kudo at cybertrust.co.jp
2019-10-17 2:05 SZ Lin (林上智)
2019-10-10 2:32 SZ Lin (林上智)
2019-10-03 1:56 SZ Lin (林上智)
2019-09-26 2:46 SZ Lin (林上智)
[not found] ` <CAFa_k0gBzv-2bOF_pGbpvZQyQ1ocEu-bsBNT_JsWi12cxrK-Pg@mail.gmail.com>
2019-09-26 3:01 ` masashi.kudo at cybertrust.co.jp
2019-09-28 4:30 ` masashi.kudo at cybertrust.co.jp
2019-09-30 7:19 ` Chris Paterson
2019-10-01 2:47 ` masashi.kudo at cybertrust.co.jp
2019-09-19 1:27 SZ Lin (林上智)
2019-09-19 11:08 ` Pavel Machek
2019-09-12 1:37 SZ Lin (林上智)
2019-09-12 22:46 ` nobuhiro1.iwamatsu at toshiba.co.jp
2019-09-05 1:34 SZ Lin (林上智)
2019-08-29 1:31 SZ Lin (林上智)
2019-08-29 2:51 ` masashi.kudo at cybertrust.co.jp
2019-08-29 4:05 ` SZ Lin (林上智)
2019-08-29 7:13 ` masashi.kudo at cybertrust.co.jp
2019-08-22 1:31 SZ Lin (林上智)
2019-08-22 20:35 ` Pavel Machek
2019-08-15 1:04 SZ Lin (林上智)
2019-08-08 1:55 SZ Lin (林上智)
2019-08-01 1:03 SZ Lin (林上智)
2019-08-01 8:05 ` nobuhiro1.iwamatsu at toshiba.co.jp
2019-07-25 1:06 SZ Lin (林上智)
2019-07-11 2:25 SZ Lin (林上智)
2019-07-04 0:59 SZ Lin (林上智)
2019-07-04 6:38 ` akihiro27.suzuki at toshiba.co.jp
2019-06-27 0:29 SZ Lin (林上智)
2019-06-27 5:53 ` nobuhiro1.iwamatsu at toshiba.co.jp
2019-06-20 1:11 SZ Lin (林上智)
2019-06-12 23:26 SZ Lin (林上智)
2019-06-13 6:56 ` Chris Paterson
2019-06-06 1:28 SZ Lin (林上智)
2019-06-06 2:01 ` kazuhiro3.hayashi at toshiba.co.jp
2019-05-30 1:18 SZ Lin (林上智)
2019-05-23 1:58 SZ Lin (林上智)
2019-05-16 3:55 SZ Lin (林上智)
2019-05-09 1:45 SZ Lin (林上智)
2019-04-25 2:34 SZ Lin (林上智)
2019-04-18 1:33 SZ Lin (林上智)
2019-04-11 2:28 SZ Lin (林上智)
2019-04-04 2:52 SZ Lin (林上智)
2019-03-28 4:08 SZ Lin (林上智)
2019-03-21 0:48 SZ Lin (林上智)
2019-03-07 2:19 SZ Lin (林上智)
2019-02-21 5:31 SZ Lin (林上智)
2019-02-14 6:33 SZ Lin (林上智)
2019-02-07 2:29 SZ Lin (林上智)
2019-01-24 2:22 SZ Lin (林上智)
2019-01-24 3:00 ` daniel.sangorrin at toshiba.co.jp
2019-01-24 5:40 ` SZ Lin (林上智)
2019-01-24 5:49 ` daniel.sangorrin at toshiba.co.jp
2019-01-24 7:29 ` Nobuhiro Iwamatsu
2019-01-24 7:56 ` SZ Lin (林上智)
2019-01-17 2:30 SZ Lin (林上智)
2018-12-27 2:10 SZ Lin (林上智)
2018-12-20 2:05 SZ Lin (林上智)
2018-12-13 2:55 SZ Lin (林上智)
2018-12-06 3:22 SZ Lin (林上智)
2018-12-06 5:41 ` Nobuhiro Iwamatsu
2018-12-06 6:10 ` SZ Lin (林上智)
2018-12-10 12:30 ` Nobuhiro Iwamatsu
2018-11-29 1:27 SZ Lin (林上智)
2018-11-22 4:41 SZ Lin (林上智)
2018-11-22 6:29 ` Daniel Sangorrin
2018-11-15 3:32 SZ Lin (林上智)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190318102756.kvqvsy4yxzl3qta3@MD1ZFJVC.ad001.siemens.net \
--to=christian.storm@siemens.com \
--cc=cip-dev@lists.cip-project.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).