Hello Guest, if you are reading this it means you have not registered yet. Please take a second, Click here to register, and in a few simple steps you will be able to enjoy our community and use our OpenViX support section.

View Entry Info: Boot issues following upgrade

Category:
Possible Bug
What ViX Image build number are you using?
Please provide your ViX Team image build number. Menu > Information > About > Build number > ENTER THIS NUMBER e.g. 4.2.028
5.2.011
Have you tried a flash WITHOUT settings restore?
Have you tried this? PLEASE SELECT YES OR NO.
No
Have you tried a flash WITH settings restore?
Have you tried this? PLEASE SELECT YES OR NO.
No
Results 1 to 2 of 2

Thread: Boot issues following upgrade

  1. #1

    Title
    ViX Beta Tester
    Join Date
    Nov 2017
    Posts
    888
    Thanks
    103
    Thanked 480 Times in 285 Posts

    Boot issues following upgrade

    I've just had a somewhat difficult experience following an upgrade that went awry from 5.2.001 to 5.2.11. Not sure what went wrong exactly, but my ET8500 got into a state where it wouldn't boot into OpenVix and for some reason my usual USB stick for updating wouldn't work either. I've got it back up and running again after a couple of days of headscratching.

    The main blocker to getting booted seemed to be this message in the logs. I've not got a copy of the exact text, but the gist is this:
    Code:
    [Harddisk] Unable to determine structure of /dev
    [Harddisk] new Harddisk ->'->
    ...
    undefined variable card in Harddisk.py in bus(self) at line 132
    Looking at the code in Harddisk.py, this suggests that self.type is not set, and sure enough, there doesn't seem to be a /dev/.udev or a /dev/.devfsd on the box. This causes self.type to be set to -1. Later the code checks for the 2 defined values, so the -1 falls through, ultimately leading to a crash due to card not being set.

    Now things are up and running properly again, I can see a /dev/.udev. Google suggests that .devfsd is a bit "old school". With this in mind, would choosing udev be a sensible to default so that this crash would be avoided? I'm not familiar with any of the other boxes that OpenVix runs on, so can't say whether this is a silly idea or not!

    The other blocker to getting running was screensaver.py kicking in when there was no screen size available (did I mention that my system was *really* screwed :-D) with doMovePicture crashing when random.randint(1,self.maxx) caused an exception, due to maxx being 0.

    Once I'd patched both these, I was able to get into the OpenVix image restore menus and reflash from there. Easy enough to protect against, but very fringe.

    So the question is whether these changes are of general use and worth submitting a patch for?

  2. #2
    abu baniaz's Avatar
    Title
    Moderator
    Join Date
    Sep 2010
    Location
    East London
    Posts
    23,335
    Thanks
    6,421
    Thanked 9,146 Times in 6,224 Posts
    Only one way to find out.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
This website uses cookies
We use cookies to store session information to facilitate remembering your login information, to allow you to save website preferences, to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.