Hi Gautam,
As you requested, here's the output from running fsck on the writable
partition after booting/running from the SD card. Nothing that truly
unusual I don't think?
root@bbb-dev:~# fsck -f -v /dev/mmcblk1p2
fsck from util-linux 2.25.2
e2fsck 1.43 (17-May-2016)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Unattached inode 45
Connect to /lost+found<y>? no
Unattached inode 81
Connect to /lost+found<y>? no
Pass 5: Checking group summary information
Block bitmap differences: +(96768--97021)
Fix<y>? no
Free blocks count wrong for group #2 (1174, counted=1428).
Fix<y>? no
Free blocks count wrong (1091090, counted=1091344).
Fix<y>? no
rootfs_var: ********** WARNING: Filesystem still has errors **********
5413 inodes used (1.43%, out of 378256)
20 non-contiguous files (0.4%)
2 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 5389/10
419310 blocks used (27.76%, out of 1510400)
0 bad blocks
1 large file
3987 regular files
1408 directories
0 character device files
0 block device files
0 fifos
0 links
8 symbolic links (5 fast symbolic links)
1 socket
------------
5402 files
root@bbb-dev:~#
------------------------------------------
I did re-run this and fixed the errors, and then the system could boot
again from the eMMC.
If you look at the log I posted in the original note, yes, I did eventually
lose ("hang") the serial console terminal session once the fsck failed. I
couldn't see it waiting for any confirmation, nor did I ever get to some
sort of console or login prompt.
And yes, this is going into an actual product. Our H/W folks are looking at
building a circuit that will watch for power failure (or an external power
button push) and assert the line that the BBB power button currently does,
to send a signal to the processor to initiate a shutdown. There is also
some sort of backup battery now planned to provide power during the
shutdown.
Dave
On Wednesday, December 6, 2017 at 12:59:08 PM UTC-5, [email protected]
wrote:
>
>
>
> On Wednesday, December 6, 2017 at 12:44:27 AM UTC+5:30, Dave Barndt wrote:
>>
>> Hi Gautam,
>>
>> Thanks for the reply! I actually had the same idea last night, and did
>> manage to boot the board using an image on an SD card, and was able to run
>> the fsck from there against the bad partition on the eMMC, and saw the
>> details of the corruption. I was able to repair the partition and
>> ultimately reflashed the board. So thanks for the reply and the
>> confirmation!
>>
>> But, what I'm still baffled about is: *Why the fsck couldn't run as part
>> of the kernel startup when the system was booted normally?* I assume the
>> partition hasn't been mounted at that point yet, so why would the fsck fail
>> to start? It's really just more of an understanding-type of question.
>>
>> Anyway, we 're now looking at ways to prevent sudden or unexpected power
>> downs from potentially effecting such behavior/corruptions. Found this
>> reference which looks pretty helpful:
>> https://www.embeddedarm.com/about/resource/preventing-filesystem-corruption-in-embedded-linux
>>
>> ... and the BBB has power down signalling (section 5.10 of the ref manual)
>> that we take advantage of as well.
>>
>> Thanks again!
>>
>> Dave
>>
>>
> Hi Dave,
>
> Could you please let me know what the corruption was once you ran fsck
> from the SD card? I am interested to the see what the corruption was.
>
> In case of fsck failure on startup did you lose your tty terminal once the
> fsck started? Due to this was it waiting for some confirmation or had it
> just started and you lost the output messages?
>
> Is this for something which will go into an actual product and is the
> requirement to have a robust FS during power failure?
>
> Thanks,
> Gautam.
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/0b73cf69-befb-4ea1-ba78-56a08eb75339%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
