Jump to content

Unraid updates failing


Blade

Recommended Posts

I am getting this trying to update my one unraid server from 6.5.0

The others update just fine

 

plugin: updating: unRAIDServer.plg
plugin: downloading: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.5.3-x86_64.zip ... done
plugin: downloading: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.5.3-x86_64.md5 ... done
Archive: /tmp/unRAIDServer.zip
creating: /tmp/unRAIDServer/EFI-/
creating: /tmp/unRAIDServer/EFI-/boot/
inflating: /tmp/unRAIDServer/EFI-/boot/bootx64.efi 
inflating: /tmp/unRAIDServer/EFI-/boot/ldlinux.e64 
inflating: /tmp/unRAIDServer/EFI-/boot/libcom32.c32 
inflating: /tmp/unRAIDServer/EFI-/boot/libutil.c32 
inflating: /tmp/unRAIDServer/EFI-/boot/mboot.c32 
inflating: /tmp/unRAIDServer/EFI-/boot/menu.c32 
inflating: /tmp/unRAIDServer/EFI-/boot/syslinux.cfg 
inflating: /tmp/unRAIDServer/bzfirmware 
inflating: /tmp/unRAIDServer/bzimage 
inflating: /tmp/unRAIDServer/bzmodules 
inflating: /tmp/unRAIDServer/bzroot unzip error 0
plugin: run failed: /bin/bash retval: 1

 

Here is some syslog info

 

Jun 15 15:31:25 Tower2 emhttpd: req (4): cmd=/plugins/dynamix.plugin.manager/scripts/plugin&arg1=update&arg2=unRAIDServer.plg&csrf_token=****************
Jun 15 15:31:25 Tower2 emhttpd: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin update unRAIDServer.plg
Jun 15 15:31:25 Tower2 root: plugin: creating: /tmp/unRAIDServer.sh - from INLINE content
Jun 15 15:31:25 Tower2 root: plugin: running: /tmp/unRAIDServer.sh
Jun 15 15:31:25 Tower2 root: plugin: creating: /tmp/unRAIDServer.zip - downloading from URL https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.5.3-x86_64.zip
Jun 15 15:32:48 Tower2 root: plugin: creating: /tmp/unRAIDServer.md5 - downloading from URL https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.5.3-x86_64.md5
Jun 15 15:32:49 Tower2 root: plugin: creating: /tmp/unRAIDServer.sh - from INLINE content
Jun 15 15:32:49 Tower2 root: plugin: running: /tmp/unRAIDServer.sh
Jun 15 15:33:22 Tower2 emhttpd: req (5): cmd=/plugins/dynamix.plugin.manager/scripts/plugin&arg1=checkos&csrf_token=****************
Jun 15 15:33:22 Tower2 emhttpd: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin checkos
Jun 15 15:34:01 Tower2 crond[1489]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null
Jun 15 15:35:01 Tower2 crond[1489]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null
Link to comment

Looks like my root disk is full

Can I make it bigger?

 

My other tower rootfs is 1.8Gb

 

Filesystem      Size  Used Avail Use% Mounted on
rootfs          831M  831M  8.0K 100% /
tmpfs            32M  500K   32M   2% /run
devtmpfs        831M     0  831M   0% /dev
tmpfs           874M     0  874M   0% /dev/shm
cgroup_root     8.0M     0  8.0M   0% /sys/fs/cgroup
tmpfs           128M  528K  128M   1% /var/log
/dev/sda1       3.8G  164M  3.6G   5% /boot
/dev/loop0      7.5M  7.5M     0 100% /lib/modules
/dev/loop1      4.5M  4.5M     0 100% /lib/firmware

 

Link to comment
24 minutes ago, Blade said:

I have the same RAM in my other tower and it is just fine

Why would this one be different

 

 

From the command line you can do

du -x / | sort -n

This will indicate what is filling the root file system. -x informs that du should ignore other file systems mounted.

 

You'll see a mix of sizes for specific files and summaries for directory trees.

Link to comment

Seems normal.

 

The only thing I see you could potentially do something about is if you don't run the Dynamix System Statistics plugin. It is creating the files in /var/sa/ and it consumes 168 MB of the RAM.

 

But as @jonathanm notes - the recommended action is to consider more RAM.

 

The more RAM you have, the larger the rootfs will be. One of my unRAID machines has 16 GB RAM and has allocated 8 GB to the rootfs. I'm not sure about the actual policy used by unRAID when deciding the size of the rootfs.

Link to comment

hello,

i had the same pb yesterday, trying to go from 6.3.2 to 6.5.3.

i have the same rootfs size : 867M used 700M.

After  tracking the pb to not enough space in /tmp for download and unzip.

my solution was to move /tmp to /boot because i have 7G available there ( i know i was using the usb stick for that)

 

[do not copy, if you do not understand]

mv /tmp to /tmpori  (rename tmp)

ln -s /tmp /boot/tmp  (create a link from /tmp to /boot/tmp)

mkdir /boot/tmp

 

tested by touch /tmp/toto , ls -l /boot/tmp , ok the file toto is present

cp -R * /tmpori /tmp ( recopy old tmp to new tmp)

 

and there upgrade , everything went fine , reboot , OK , restart array , OK.

 My new rootfs is  : rootfs          867M  703M  165M  81% /

 

i think i will have to do the same for each upgrade, since i have only 2G memory and no pb for a file server only purpose.

 

Link to comment
19 minutes ago, pgnyc said:

my solution was to move /tmp to /boot because i have 7G available there ( i know i was using the usb stick for that)

Instead of using the USB flash with your license attached, you would be MUCH better off mapping to a cache drive, unassigned devices drive, or array drive, in that order.

 

Putting that much wear on your USB is not a good idea.

Link to comment

yes you are right  ,

i could have use a unassigned devices drive , but since i  was using a terminal screen , i did not think about it , was not on a df listing !!!

same using an array disk !!!

 

next time !!

 

in fact , the biggest pb is everything works so well, that you do not touch and forget .

 

Pascal

 

 

 

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...