Jump to content

OrangePI PC reboots during apt-upgrade


sovking

Recommended Posts

Hi,

some times ago I installed an Orange PI with armbian-5.31 (stable, kernel 3.4.113).

Now I needed to upgrade some installed packages, but when I run apt-get upgrade at some point the process interrupts and the system reboots.

Now I have an interrupted upgrade process, and each time I try to restart this process with sudo dpkg --configure -a

the system try to upgrade the policykit-1, it reboots.

 

Looking at messages or syslog I don't find any particular error.

Any suggestion where to look for this problem ?

Watchdog process could be responsible for such reboots ?

 

Thanks in advance for any suggestion

Link to comment
Share on other sites

i'd like to suggest to get a new micro sd card and start afresh, i.e. new install from image, then apt-get upgrade armbian-config followed by things like running armbian-config (for 'switch to nightly' and other upgrades etc).

sometimes such 'hardware issues' could be due to power issues, or rather the lack thereof. some 'mobile phone chargers' couldn't really deliver the 2 amps which i think orange pi pc easily consumes. if you consider that usb supplies 5v on the rails and it is 2 amps that the sbc / soc draws, that is a whopping 10 watts of power. it means one would need to get a 'phone charger' that can supply well in excess of 10 watts to keep the sbc and the sd card happy and running. those high amp chargers are available these days and try to go for those better ones with reliable specs. in addition, the usb cable connecting between the power supply (phone charger) to the sbc matters as well, get a good 'thick' copper wired cable so that it'd supply the power and not fail

Link to comment
Share on other sites

This system is working 24h/7/365 with installed quite a lot of daemon needed for automation system, that works and log to sd: the load is usually between 2 and 3.

The power supply is the original power supply provided with OrangePI.

Now I don't remember the SD card brand & model, usually I use premium ones because these systems are installed in remote locations.

However I ran armbianmonitor -C on both partition of SD card (the first one is the system and the second one is for data and local automation programs).

These are the results:

 

orangepipc:~$ armbianmonitor -C /mnt/
Starting to fill /dev/mmcblk0p1 with test patterns, please be patient this might take a very long time
Free space: 2.08 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Free space: 48.91 MB
Average writing speed: 1.67 MB/s

Now verifying the written data:
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ...   73624/        0/      0/      0

  Data OK: 2.04 GB (4267928 sectors)
Data LOST: 0.00 Byte (0 sectors)
               Corrupted: 0.00 Byte (0 sectors)
        Slightly changed: 0.00 Byte (0 sectors)
             Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 19.74 MB/s

Starting iozone tests. Be patient, this can take a very long time to complete:
        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Tue Sep 25 19:52:39 2018

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 102400 kB
        Record Size 4 kB
        Record Size 512 kB
        Record Size 16384 kB
        Command line used: iozone -e -I -a -s 100M -r 4k -r 512k -r 16M -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     1402     1812     6524     6962     6876      531                                                          
          102400     512     8538     8357    15965    20754    20937      885                                                          
          102400   16384     6792     4577    18907    22626    22657     5715                                                          

iozone test complete.

The results from testing /dev/mmcblk0p1 (ext4):
Data LOST: 0.00 Byte (0 sectors)
Average writing speed: 1.67 MB/s
Average reading speed: 19.74 MB/s
  Data OK: 2.04 GB (4267928 sectors)
                                            random    random
reclen    write  rewrite    read    reread    read     write
     4     1402     1812     6524     6962     6876      531                                                          
   512     8538     8357    15965    20754    20937      885                                                          
 16384     6792     4577    18907    22626    22657     5715                                                          

Health summary: OK

Performance summary:
Sequential reading speed: 19.74 MB/s
 4K random reading speed:  6876 KB/s
Sequential writing speed:  1.67 MB/s (way too low)
 4K random writing speed:   531 KB/s (too low)

The device you tested seems to perform too slow to be used with Armbian.
This applies especially to desktop images where slow storage is responsible
for sluggish behaviour. If you want to have fun with your device do NOT use
this media to put the OS image or the user homedirs on.

 

 

orangepipc:~$ armbianmonitor -C /home/
Starting to fill /dev/mmcblk0p2 with test patterns, please be patient this might take a very long time
Free space: 956.04 MB
Creating file 1.h2w ... OK!
Free space: 174.16 MB
Average writing speed: 2.07 MB/s

Now verifying the written data:
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 1601272/        0/      0/      0

  Data OK: 781.87 MB (1601272 sectors)
Data LOST: 0.00 Byte (0 sectors)
               Corrupted: 0.00 Byte (0 sectors)
        Slightly changed: 0.00 Byte (0 sectors)
             Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 18.41 MB/s

Starting iozone tests. Be patient, this can take a very long time to complete:
        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Tue Sep 25 19:10:09 2018

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 102400 kB
        Record Size 4 kB
        Record Size 512 kB
        Record Size 16384 kB
        Command line used: iozone -e -I -a -s 100M -r 4k -r 512k -r 16M -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     1152     1333     6787     6787     6085      407                                                          
          102400     512     3787     2493    18622    20376    20797     1145                                                          
          102400   16384     3553     2476    19991    14727    18804     2787                                                          

iozone test complete.

The results from testing /dev/mmcblk0p2 (ext4):
Data LOST: 0.00 Byte (0 sectors)
Average writing speed: 2.07 MB/s
Average reading speed: 18.41 MB/s
  Data OK: 781.87 MB (1601272 sectors)
                                            random    random
reclen    write  rewrite    read    reread    read     write
     4     1152     1333     6787     6787     6085      407                                                          
   512     3787     2493    18622    20376    20797     1145                                                          
 16384     3553     2476    19991    14727    18804     2787                                                          

Health summary: OK

Performance summary:
Sequential reading speed: 18.41 MB/s
 4K random reading speed:  6085 KB/s
Sequential writing speed:  2.07 MB/s (way too low)
 4K random writing speed:   407 KB/s (too low)

The device you tested seems to perform too slow to be used with Armbian.
This applies especially to desktop images where slow storage is responsible
for sluggish behaviour. If you want to have fun with your device do NOT use
this media to put the OS image or the user homedirs on.

 

Then h3consumption settings are quite conservative as you can see:

 

root@orangepipc:~# h3consumption  -p
Active settings:

cpu       912 mhz allowed, 1200 mhz possible, 4 cores active

dram      624 mhz

hdmi/gpu  off

usb ports active

eth0      100Mb/s/Full, Link: yes

 

Because the system is remote,  swapping card and other manual intervation takes a lot of time (at least 1 day) and money;
if there is not another major problem: the system can run even in this state.

If a blocking problem arise I'll bring there a complete new system (board, sd, psu) and I'll investigate later at home.

 

However I would like to check if there is anything I can do, safely, from remote.

I'm quite skeptical about sd card or psu problem because the system is quite loaded and probably it shoud show these problem during other activities too, and not only during polkit upgrade.

There is any way to diagnose what force a reboot during such operation ?

 

Another doubt I have is on that system there are configured both systemd watchdog and the usual software watchdog: I don't know if they can interfere one with the other.

 

Link to comment
Share on other sites

Try limiting the max cpufreq down to max of 816MHz on all cores...my OPiPC was doing that as well..ran GREAT for a few days then just *hork* locked up

After changing the /etc/default/cpufrequtils to max=816000 and set to interactive, no more problems, runs stable and still has enough horsepower to run a personal web based nexcloud server with no issues

 

Biggest thing is heat, those H2+ and H3 chips run hot hot hot...need a beefy heatsink and even better active cooling as well to ensure heat doesn't cause the CPU to go squiffy
 

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines