CIP-dev Archive on lore.kernel.org
 help / color / Atom feed
From: akihiro27.suzuki@toshiba.co.jp (akihiro27.suzuki at toshiba.co.jp)
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] CIP IRC weekly meeting today
Date: Wed, 27 Mar 2019 08:25:45 +0000
Message-ID: <TYAPR01MB2495456763610C72BCCB9E90D9580@TYAPR01MB2495.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <20190322123711.lc44vtkgk6bbgi6y@MD1ZFJVC.ad001.siemens.net>

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

  reply index

Thread overview: 261+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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
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 [this message]
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-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=TYAPR01MB2495456763610C72BCCB9E90D9580@TYAPR01MB2495.jpnprd01.prod.outlook.com \
    --to=akihiro27.suzuki@toshiba.co.jp \
    --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

CIP-dev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/cip-dev/0 cip-dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 cip-dev cip-dev/ https://lore.kernel.org/cip-dev \
		cip-dev@lists.cip-project.org
	public-inbox-index cip-dev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.cip-project.lists.cip-dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git