Re: [Astlinux-devel] Adding a "spinner" indicator when e2fsck is working

[Michael K. <li...@mk...>]

> Am 29.08.2017 um 20:12 schrieb Lonnie Abelbeck <li...@lo...>:
> 
> Hi Devs,
> 
> David made a good point, so I looked into piping the output of e2fsck to a "spinner" shell function, triggered by a newline and update no more often then ever second ...
> --
> spinner()
> {
>   local i sp secs nsecs line IFS
> 
>   i=0
>   secs=0
> 
>   unset IFS
>   while read line; do
>     nsecs=$(cut -d. -f1 /proc/uptime)
>     if [ $nsecs -ne $secs ]; then
>       secs=$nsecs
>       i=$(((i+1)%4))
>       case $i in
>         1) sp='-' ;;
>         2) sp='\' ;;
>         3) sp='|' ;;
>         *) sp='/' ;;
>       esac
>       echo -ne " Working[${sp}] \r"
>     fi
>   done
> 
>   echo -ne "            \r"
> }
> --
> It took some work getting this to work without printf, no date, no bash ${str:1:1}, etc., but it works with the current Busybox configs.
> 
> But ... here are the two places "spinner" would apply to ...
> 
> 1) in the initrd, linuxrc ...
> --
>     e2fsck -y $ASTURW >/dev/null
>     status=$?
> 
>     case $status in
> --
> 
> 2) in astlinux, /etc/rc ...
> --
>   echo "Checking $1"
>   e2fsck -y $1 >/dev/null
> 
>   status="$?"
> 
>   case $status in
> --
> 
> The plan would be to use:
> --
> e2fsck -y $1 | spinner
> --
> But the return value of $? is no longer from e2fsck, but rather spinner
> 
> You might try ...
> --
> ( e2fsck -y $1 ; status="$?" ) | spinner
> --
> Almost, but now "status" is defined in a subshell which is not propagated up and lost.
> 
> A simple but ugly solution is to use a temp file ...
> --
> ( e2fsck -y $1 ; echo "$?" > /tmp/e2fsck_status ) | spinner
> status="$(cat /tmp/e2fsck_status)"
> rm /tmp/e2fsck_status
> --
> but not to mention the initrd does not currently mount a /tmp filesystem. We would have to have to create and delete a tmpfs filesystem just to get the return value from e2fsck. :-(
> 
> I'm leaning toward leaving things as is, comments ?
> 
> Lonnie
> 
> 
> On Aug 29, 2017, at 8:20 AM, Lonnie Abelbeck <li...@lo...> wrote:
> 
>> Hi David,
>> 
>> Agreed, no e2fsck output when it is forced to work for a long period is not ideal.  Thankfully this is a very rare occurrence.
>> 
>> If we can come up with a clever spinning wheel or such counting the lines e2fsck generates might be a good addition.
>> 
>> Recall this all occurs in the "initrd", so the available packages and BusyBox config is quite limited.
>> 
>> Any further discussion on this idea should move to the astlinux-devel list.
>> 
>> Lonnie
>> 
>> 
>> On Aug 29, 2017, at 7:48 AM, David Kerr <Da...@Ke...> wrote:
>> 
>>> Is that a good idea (redirecting e2fsck to null)?  15 minutes is a long time to wait with no indication of anything happening.
>>> 
>>> David
>>> 
>>> On Tue, Aug 29, 2017 at 8:33 AM, Lonnie Abelbeck <li...@lo...> wrote:
>>> Hi Tim,
>>> 
>>> Yes, it was running "e2fsck" with stdout redirected to /dev/null so you did not see it working ... eventually e2fsck will return with a result code if left long enough.
>>> 
>>> Good to hear your filesystem is now clean, you might reboot once again to make sure the filesystem is good.
>>> 
>>> BTW, if the automatic e2fsck repair did not work, here is the manual fallback procedure:
>>> --
>>> ## reboot, and quickly when the RUNNIX boot menu appears type "shell"
>>> boot: shell
>>> 
>>> ## Wait for a "runnix# " CLI prompt.
>>> ## determine the first Linux ext2 partition, usually always /dev/sda2
>>> runnix# findfs LABEL=ASTURW
>>> 
>>> ## using the findfs result, run e2fsck manually, you may want to add -y or -p options
>>> runnix# e2fsck /dev/sda2
>>> 
>>> ## output a list of options for e2fsck
>>> runnix# e2fsck
>>> Usage: e2fsck [-panyrcdfktvDFV] [-b superblock] [-B blocksize]
>>>                [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
>>>                [-E extended-options] [-z undo_file] device
>>> 
>>> Emergency help:
>>> -p                   Automatic repair (no questions)
>>> -n                   Make no changes to the filesystem
>>> -y                   Assume "yes" to all questions
>>> -c                   Check for bad blocks and add them to the badblock list
>>> -f                   Force checking even if filesystem is marked clean
>>> -v                   Be verbose
>>> -b superblock        Use alternative superblock
>>> -B blocksize         Force blocksize when looking for superblock
>>> -j external_journal  Set location of the external journal
>>> -l bad_blocks_file   Add to badblocks list
>>> -L bad_blocks_file   Set badblocks list
>>> -z undo_file         Create an undo file
>>> 
>>> ## Depending on how you initially configured AstLinux, check if you also have a ASTKD partition
>>> ## (typically /dev/sda3 if it exists)
>>> runnix# findfs LABEL=ASTKD
>>> ## If the ASTKD label exists repeat the e2fsck steps above using the ASTKD label partition.
>>> 
>>> ## reboot by issuing "exit"
>>> runnix# exit
>>> --
>>> 
>>> Lonnie
>>> 
>>> 
>>> On Aug 29, 2017, at 7:02 AM, Tim Turpin <tt...@z-...> wrote:
>>> 
>>>> Never mind.  After sitting at that point for about 15 minutes, it somehow recovered and finished booting up.  All seems well now.
>>>> 
>>>> From: Tim Turpin [mailto:tt...@z-...]
>>>> Sent: Tuesday, August 29, 2017 7:34 AM
>>>> To: ast...@li...
>>>> Subject: [Astlinux-users] ASTLinux stopped booting
>>>> 
>>>> We took a power hit on our test system yesterday, and now it will only load up to a certain point and stops with the following screen:

Lonnie, don't give up so quickly :-).
What you have already is quite a good starting point.
What about adding "something needed" to our initrd busybox.config …

Michael

http://www.mksolutions.info