Re: [OE-core] [PATCH] image_types: perform fsck on created ext image

2017-03-27 Thread Enrico Joerns 

Hi Daniel,

On 03/27/2017 09:37 AM, Daniel Schultz wrote:

I have sent fixes for the same problem on Monday.
These include a fix of the wrong return code after optimizations (now it
returns 0) and an fsck execution after the creation of EXT partitions.

The patch which is identical to yours wasn't applied so far, the other
ones were.


ouh, we should have checked that before, but we did not assume that
someone would have posted a fix for this relatively old behavior during
the last days. Reality disabused us... Anyway, good to see that we are
not the only one that stumbled across this issue ;)

But, there is another difference between our patches. We use `-pvfD`,
while you use `-fy` as an fsck.extN option.

I would expect `-p` to be sufficient for letting fsck perform minor
optimizations. If you use `-y` instead, fsck will fix also real issues.
This is not what it should do here, even if it will return 1 afterwards.
If the file system was created with errors I guess we should let the
image creation fail without further touching the ext4.

-D will let fsck perform further directory optimizations
-v might be helpful for debugging purpose


Yes, that's better. I will them also apply to the WIC tools.

Do you think the test expression is still needed?
My opinion is, that it will obfuscate the return code of fsck to either
true or false. This could confuse other people. What do you think?


well, as far as I see it, the test expression will only be needed if 
fsck still returns an error code for those uncritical optimizations it 
performs. With the backported patch applied you had in your series i 
guess there should be no need for the test expression, but I did not 
test it yet in this setup.


Best regards, Enrico

--
Pengutronix e.K.   | Enrico Jörns|
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] image_types: perform fsck on created ext image

2017-03-27 Thread Daniel Schultz 

Hi Enrico,

Am 24.03.2017 um 15:01 schrieb Enrico Joerns:

Hi Daniel,

On 03/24/2017 02:34 PM, Daniel Schultz wrote:

Hi Enrico,

I have sent fixes for the same problem on Monday.
These include a fix of the wrong return code after optimizations (now it
returns 0) and an fsck execution after the creation of EXT partitions.

The patch which is identical to yours wasn't applied so far, the other
ones were.


ouh, we should have checked that before, but we did not assume that
someone would have posted a fix for this relatively old behavior during
the last days. Reality disabused us... Anyway, good to see that we are
not the only one that stumbled across this issue ;)

But, there is another difference between our patches. We use `-pvfD`,
while you use `-fy` as an fsck.extN option.

I would expect `-p` to be sufficient for letting fsck perform minor
optimizations. If you use `-y` instead, fsck will fix also real issues.
This is not what it should do here, even if it will return 1 afterwards.
If the file system was created with errors I guess we should let the
image creation fail without further touching the ext4.

-D will let fsck perform further directory optimizations
-v might be helpful for debugging purpose


Yes, that's better. I will them also apply to the WIC tools.

Do you think the test expression is still needed?
My opinion is, that it will obfuscate the return code of fsck to either 
true or false. This could confuse other people. What do you think?


--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] image_types: perform fsck on created ext image

2017-03-24 Thread Burton, Ross 
On 24 March 2017 at 14:01, Enrico Joerns  wrote:

> But, there is another difference between our patches. We use `-pvfD`,
> while you use `-fy` as an fsck.extN option.
>

Indeed, I've selected your patch for my staging branch.

Cheers,
Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] image_types: perform fsck on created ext image

2017-03-24 Thread Enrico Joerns 

Hi Daniel,

On 03/24/2017 02:34 PM, Daniel Schultz wrote:

Hi Enrico,

I have sent fixes for the same problem on Monday.
These include a fix of the wrong return code after optimizations (now it
returns 0) and an fsck execution after the creation of EXT partitions.

The patch which is identical to yours wasn't applied so far, the other
ones were.


ouh, we should have checked that before, but we did not assume that 
someone would have posted a fix for this relatively old behavior during 
the last days. Reality disabused us... Anyway, good to see that we are 
not the only one that stumbled across this issue ;)


But, there is another difference between our patches. We use `-pvfD`, 
while you use `-fy` as an fsck.extN option.


I would expect `-p` to be sufficient for letting fsck perform minor 
optimizations. If you use `-y` instead, fsck will fix also real issues. 
This is not what it should do here, even if it will return 1 afterwards. 
If the file system was created with errors I guess we should let the 
image creation fail without further touching the ext4.


-D will let fsck perform further directory optimizations
-v might be helpful for debugging purpose


Best regards

Enrico

--
Pengutronix e.K.   | Enrico Jörns|
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] image_types: perform fsck on created ext image

2017-03-24 Thread Burton, Ross 
On 24 March 2017 at 13:34, Daniel Schultz  wrote:

> The patch which is identical to yours wasn't applied so far, the other
> ones were.
>

Whoops, that was marked locally as merged but wasn't in the tree.  Now it's
staged.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] image_types: perform fsck on created ext image

2017-03-24 Thread Daniel Schultz 

Hi Enrico,

I have sent fixes for the same problem on Monday.
These include a fix of the wrong return code after optimizations (now it 
returns 0) and an fsck execution after the creation of EXT partitions.


The patch which is identical to yours wasn't applied so far, the other 
ones were.


--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz

Am 24.03.2017 um 12:15 schrieb Enrico Jorns:

When performing a file system check, the image created with mkfs will
trigger Pass 3A ('Optimizing directories') which turns the file system
into state "changed" (EXT2_FLAG_CHANGED).

This will let fsck request a reboot by setting the return code flag "2".

The result of this is that each ext-image built with oe-core will
trigger a reboot during the first time an fsck is triggered.

A common case where this might occur is when fsck detects having
a future superblock write time. This always happens when booting a
newly created ext4 rootfs with a target that does not have a recent time
set.

This patch moves the initial fsck run that performs the optimization
from the target to the host system and thus prevents the target from
performing an avoidable reboot.

Signed-off-by: Enrico Jorns 
Signed-off-by: Ulrich Ölmann 
---
 meta/classes/image_types.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 1ce8334e3a..52d3af0cc1 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -66,6 +66,8 @@ oe_mkext234fs () {
# Create a sparse image block
dd if=/dev/zero 
of=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype seek=$ROOTFS_SIZE 
count=$COUNT bs=1024
mkfs.$fstype -F $extra_imagecmd 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype -d ${IMAGE_ROOTFS}
+   # Error codes 0-3 indicate successfull operation of fsck (no errors or 
errors corrected)
+   fsck.$fstype -pvfD 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype || [ $? -le 3 ]
 }

 IMAGE_CMD_ext2 = "oe_mkext234fs ext2 ${EXTRA_IMAGECMD}"



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core