[PATCH] image_types: perform fsck on created ext image

[PATCH] image_types: perform fsck on created ext image

[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 <ejo@pengutronix.de>
Signed-off-by: Ulrich Ölmann <uol@pengutronix.de>
---
 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}"
-- 
2.11.0

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

[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 <ejo@pengutronix.de>
> Signed-off-by: Ulrich Ölmann <uol@pengutronix.de>
> ---
>  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}"
>

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

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 261 bytes --]

On 24 March 2017 at 13:34, Daniel Schultz <d.schultz@phytec.de> 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

[-- Attachment #2: Type: text/html, Size: 747 bytes --]

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

[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-5555 |

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

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

On 24 March 2017 at 14:01, Enrico Joerns <ejo@pengutronix.de> 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

[-- Attachment #2: Type: text/html, Size: 705 bytes --]

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

[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

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

[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-5555 |