corrupted ubi after reboot while busy
I'm trying UBI for the first time; I have the kernel 2.6.24 with UBI backported from 2.6.25-rc7.
I created a static volume (on NAND) and wrote a JFFS2 image to it with ubiupdatevol. mount succeeded, but the image was built wrongly so the jffs2 garbage collector thread to fix it. I then rebooted the system while this was running (using a proper reboot, which succeeded).
After rebooting, I can't attach the UBI volume at all:
Jan 1 00:16:34 elaraboot user.err kernel: [ 994.310000] UBI error: validate_vid_hdr: inconsistent VID header at PEB 664 Jan 1 00:16:34 elaraboot user.err kernel: [ 994.320000] UBI error: cannot attach mtd7 Jan 1 00:16:34 elaraboot user.err kernel: [ 994.320000] UBI error: cannot initialize UBI, error -22
I don't understand how a corrupt volume can cause the whole UBI to be unusable?
As an aside, is a static volume not read-only?
thanks
Hamish
Signature · 1 line
Hamish Moffatt VK3SB <[email protected]> <[email protected]>
Hi,
Quoted 6 lines · Hamish Moffatt
I'm trying UBI for the first time; I have the kernel 2.6.24 with UBI backported from 2.6.25-rc7.
I created a static volume (on NAND) and wrote a JFFS2 image to it with ubiupdatevol. mount succeeded, but the image was built wrongly so the jffs2 garbage collector thread to fix it.
Strange, the volume should be read-only, what could the GC thread do to it?
Quoted 8 lines
I then rebooted the system
while this was running (using a proper reboot, which succeeded).After rebooting, I can't attach the UBI volume at all:
Jan 1 00:16:34 elaraboot user.err kernel: [ 994.310000] UBI error: validate_vid_hdr: inconsistent VID header at PEB 664 Jan 1 00:16:34 elaraboot user.err kernel: [ 994.320000] UBI error: cannot attach mtd7 Jan 1 00:16:34 elaraboot user.err kernel: [ 994.320000] UBI error: cannot initialize UBI, error -22
Could you please enable UBI debugging (just UBI debugging, not any of debugging messages), and try to attach the MTD device again? Then send me the UBI output which you may take with dmesg?
Quoted 2 lines
I don't understand how a corrupt volume can cause the whole UBI to be unusable?
In this case UBI finds that the VID header contains some "insane" data, it's not just corruption which would be detected by CRC checking (which is OK in your case). This is why UBI refuses to keep going. This might me a bug though, the debugging should help.
Quoted 1 line
As an aside, is a static volume not read-only?
It should be, but I never tried.
Signature · 2 lines
Best regards, Artem Bityutskiy (Битюцкий Артём)
Quoted 9 lines · Artem Bityutskiy
Quoted 6 lines · Hamish Moffatt
I'm trying UBI for the first time; I have the kernel 2.6.24 with UBI backported from 2.6.25-rc7.
I created a static volume (on NAND) and wrote a JFFS2 image to it with ubiupdatevol. mount succeeded, but the image was built wrongly so the jffs2 garbage collector thread to fix it.
Strange, the volume should be read-only, what could the GC thread do to it?
That's what I thought.
Quoted 5 lines
Quoted 5 lines
I then rebooted the system
while this was running (using a proper reboot, which succeeded).After rebooting, I can't attach the UBI volume at all:
Quoted 7 lines
Quoted 3 lines
Jan 1 00:16:34 elaraboot user.err kernel: [ 994.310000] UBI error: validate_vid_hdr: inconsistent VID header at PEB 664 Jan 1 00:16:34 elaraboot user.err kernel: [ 994.320000] UBI error: cannot attach mtd7 Jan 1 00:16:34 elaraboot user.err kernel: [ 994.320000] UBI error: cannot initialize UBI, error -22Could you please enable UBI debugging (just UBI debugging, not any of debugging messages), and try to attach the MTD device again? Then send me the UBI output which you may take with dmesg?
I will try. I already erased the device to try something else, but I will try to reproduce it.
thanks
Hamish
Signature · 1 line
Hamish Moffatt VK3SB <[email protected]> <[email protected]>
Quoted 5 lines · Hamish Moffatt
Quoted 4 lines · Artem Bityutskiy
Quoted 3 lines · Hamish Moffatt
I'm trying UBI for the first time; I have the kernel 2.6.24 with UBI backported from 2.6.25-rc7.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
I created a static volume (on NAND) and wrote a JFFS2 image to it with ubiupdatevol. mount succeeded, but the image was built wrongly so the jffs2 garbage collector thread to fix it.
Strange, the volume should be read-only, what could the GC thread do to it?
That's what I thought.
Actually, static volumes are protected by CRC checksums on the UBI level, so UBI checks CRC of whole volume when you open it for the first time, which may take time. What is the size of your static volume?
JFFS2 has its own data integrity checksums, so static volumes are not really necessary. I'd suggest using a dynamic volume instead.
Signature · 2 lines
Best regards, Artem Bityutskiy (Битюцкий Артём)