mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Norbert Wiedmann <info@n-wiedmann.de>
To: barebox@lists.infradead.org
Subject: Bootchooser has unexpected changes of variable 'remaining_attempts'
Date: Mon, 24 Jul 2017 13:28:41 +0200 (CEST)	[thread overview]
Message-ID: <462439994.27865.1500895721159@ox.hosteurope.de> (raw)

Hi everyone,
I have an unexpected behaviour with my bootchooser framework since 
barebox version 2017.05.
 
After reflashing barebox, and cleaning the environment and the state partition,
the boot message shows:

stMyBoot: New state registered 'stMyBoot'
stMyBoot: Failed to find any valid state copy in any bucket
stMyBoot: Failed to read state with format dtb, -2
state stMyBoot.14: Failed to load persistent state, continuing with defaults,-2

Barebox continues with defaults, this seems OK.
I double checked this by printing the variables (default is 0xffffffff)

printenv stMyBoot.bootchooser.factory.remaining_attempts
stMyBoot.bootchooser.factory.remaining_attempts=4294967295

printenv stMyBoot.bootchooser.system1.remaining_attempts       
stMyBoot.bootchooser.system1.remaining_attempts=4294967295

printenv stMyBoot.bootchooser.system2.remaining_attempts
stMyBoot.bootchooser.system2.remaining_attempts=4294967295

Next, I call boot, and everything works fine, the target with the highest
priority, which is 'system1', boots.

booting 'bootchooser'
booting 'system1'

The system boots as expected. I have no modification within my linux.

The problem starts with the second boot, which fails:

barebox outputs:
stMyBoot: New state registered 'stMyBoot'
stMyBoot: Using bucket 0@0x00000000

This is OK, the bucket was written during the first boot, because the
remaining_attempts should be decreased. But, unexpectly, the bootchooser
is completly deactivated, all three boot targets have remaining_attempts=0

booting 'bootchooser'
bootchooser: No valid targets found:
system1
    id: 1
    priority: 22
    default_priority: 1
    remaining attempts: 0
    default attempts: 3
    boot: 'system1'
    disabled due to remaining attempts = 0
system2
    id: 2
    priority: 21
    default_priority: 1
    remaining attempts: 0
    default attempts: 3
    boot: 'system2'
    disabled due to remaining attempts = 0
factory
    id: 3
    priority: 10
    default_priority: 1
    remaining attempts: 0
    default attempts: 3
    boot: 'factory'
    disabled due to remaining attempts = 0
booting 'bootchooser' failed: No such file or directory

I placed a printenv in my boot entry file and, when booting the first time
after a new  reflashing, the output is
stMyBoot.bootchooser.system1.remaining_attempts=0

I looks like the bootchooser doesn't use the default/actual value for
'remaining_attempts' when saving the variables after he has decided which
boot target he will use.

Everything worked fine up to 2017.04
Behaviour as descriped tested with 2017.05, 2017.07.1
 
What is going wrong?
Thanks for your consideration in this matter.

Best regards
Norbert Wiedmann

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

             reply	other threads:[~2017-07-24 11:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-24 11:28 Norbert Wiedmann [this message]
2017-08-01 14:02 ` Norbert Wiedmann
2017-08-01 20:37   ` Robert Schwebel
2017-08-04 13:49   ` Norbert Wiedmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=462439994.27865.1500895721159@ox.hosteurope.de \
    --to=info@n-wiedmann.de \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox