unRAID Server Release 5.0-rc16c Available


Recommended Posts

Apparently unmenu is still available when booted in safe mode.

In the latest releases, the safemode flag causes the standard go file to be executed, because there are a few users that require certain statements in their go file for their array to work correctly.  This means that while plugins and addons in the extra folder are not loaded, addons like UnMENU are still loaded, including any auto-install UnMENU addons.

 

I would prefer a little different startup.  Ask users who require special commands to place them in both their regular go file and in the new go-safe file, which will only be executed in safe mode.  Then Tom would change his startup logic to:

if unraidsafemode flags

  if go-safe exists

      execute go-safe

  else

      load emhttp

else

  load plugins etc...

 

Easy to implement, easy for Tom, easy to explain, easier to support because lower chance of syntax errors if users are trying to insert safemode conditional statements...

 

Smart attributes:

 

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   118   099   006    Pre-fail  Always       -       185119076
  3 Spin_Up_Time            0x0003   099   099   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       159
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       1
  7 Seek_Error_Rate         0x000f   083   060   030    Pre-fail  Always       -       231028177
  9 Power_On_Hours          0x0032   073   073   000    Old_age   Always       -       24206
10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       124
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       21
189 High_Fly_Writes         0x003a   001   001   000    Old_age   Always       -       1014
190 Airflow_Temperature_Cel 0x0022   070   055   045    Old_age   Always       -       30 (Min/Max 25/31)
194 Temperature_Celsius     0x0022   030   045   000    Old_age   Always       -       30 (0 19 0 0)
195 Hardware_ECC_Recovered  0x001a   051   031   000    Old_age   Always       -       185119076
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       270110493269636
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       2411685787
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       534815259

 

Looks like a good Seagate with a little age on it.  It is showing a normal amount of aging, consistent with its 24000 operational hours, with some High Fly Writes, some Command Timeouts, a single remapped sector, and a Spinup time VALUE that has dropped from 100 to 99, all of which looks very good to me.  You can probably expect several more good years with this drive.  The critical attributes all look very good.

Link to comment
  • Replies 392
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I'm having a problem since at least the first rc16 release -- may just be coincidental.

 

Each time I reboot, my /home/<user> directory's permissions get changed to 777, and also affecting my .ssh directory -- which disallows me from connecting via SSH (since I use key authorization -- not sure if that matters). So, I go in through FTP and change the perms there, and it works.

 

I really haven't added any other plugins, besides the SimpleFeatures suite -- but I believe I had the latest prior to rc16.

 

Anywhere I can look to help?

 

Thanks

Link to comment

I'm having a problem since at least the first rc16 release -- may just be coincidental.

 

Each time I reboot, my /home/<user> directory's permissions get changed to 777, and also affecting my .ssh directory -- which disallows me from connecting via SSH (since I use key authorization -- not sure if that matters). So, I go in through FTP and change the perms there, and it works.

 

I really haven't added any other plugins, besides the SimpleFeatures suite -- but I believe I had the latest prior to rc16.

 

Anywhere I can look to help?

 

Thanks

 

since /home/ dir is not persistent I guess you are maybe copying it's contents from the flash on each boot? (and on the flash all is 777...) you may need to add a line on go file to adjust permissions on every boot.

Link to comment

Apparently unmenu is still available when booted in safe mode.

In the latest releases, the safemode flag causes the standard go file to be executed, because there are a few users that require certain statements in their go file for their array to work correctly.  This means that while plugins and addons in the extra folder are not loaded, addons like UnMENU are still loaded, including any auto-install UnMENU addons.

 

I would prefer a little different startup.  Ask users who require special commands to place them in both their regular go file and in the new go-safe file, which will only be executed in safe mode.  Then Tom would change his startup logic to:

if unraidsafemode flags

  if go-safe exists

      execute go-safe

  else

      load emhttp

else

  load plugins etc...

 

Easy to implement, easy for Tom, easy to explain, easier to support because lower chance of syntax errors if users are trying to insert safemode conditional statements...

 

That was my understanding of how I thought it works, what is the go-safe file if not for the " few users that require certain statements in their go file for their array to work correctly". Isn't the go file skipped and go-safe run instead?

Link to comment

I'm having a problem since at least the first rc16 release -- may just be coincidental.

 

Each time I reboot, my /home/<user> directory's permissions get changed to 777, and also affecting my .ssh directory -- which disallows me from connecting via SSH (since I use key authorization -- not sure if that matters). So, I go in through FTP and change the perms there, and it works.

 

It's possible, I just don't know:

 

a) What is copying this directory over -- I've been going through my flash to see if I have any script, or a comparable folder hierarchy -- nothing.

b) Why it just started happening recently.

 

I really haven't added any other plugins, besides the SimpleFeatures suite -- but I believe I had the latest prior to rc16.

 

Anywhere I can look to help?

 

Thanks

 

since /home/ dir is not persistent I guess you are maybe copying it's contents from the flash on each boot? (and on the flash all is 777...) you may need to add a line on go file to adjust permissions on every boot.

Link to comment

Apparently unmenu is still available when booted in safe mode.

In the latest releases, the safemode flag causes the standard go file to be executed, because there are a few users that require certain statements in their go file for their array to work correctly.  This means that while plugins and addons in the extra folder are not loaded, addons like UnMENU are still loaded, including any auto-install UnMENU addons.

 

I would prefer a little different startup.  Ask users who require special commands to place them in both their regular go file and in the new go-safe file, which will only be executed in safe mode.  Then Tom would change his startup logic to:

if unraidsafemode flags

  if go-safe exists

      execute go-safe

  else

      load emhttp

else

  load plugins etc...

 

Easy to implement, easy for Tom, easy to explain, easier to support because lower chance of syntax errors if users are trying to insert safemode conditional statements...

 

That was my understanding of how I thought it works, what is the go-safe file if not for the " few users that require certain statements in their go file for their array to work correctly". Isn't the go file skipped and go-safe run instead?

It was not implemented at all like it was discussed.

 

The only way to invoke safe-mode is via the syslinux boot menu.  There is no "flag-file"

 

The safe-mode does not install /boot/extra packages, /boot/plugins or /boot/config/plugins

 

It does still invoke /boot/config/go

 

No idea why Tom decided how he wished to impliment "unraidsafemode", but it is how he did it in 5.0-rc16c

Link to comment

Apparently no procedure runs it. I did got the idea that he had intentions to to call the file for safe-mode but then changed his mind and the file was left...

 

See: http://lime-technology.com/forum/index.php?topic=27960.msg252072#msg252072

Yes that's right, file left over from an implementation where rc.local did call a "go-safe"; removed in 5.0 'stable'.  Here's why I took it out.  In the normal case, there should not be anything in the 'go' file except vital code necessary for proper operation of the h/w platform.  That is all.  Yes it's been used for more than that in the past, but I'm trying to get away from that.

 

If someone is knowledgeable enough to edit the 'go' file and add extra stuff, then it's not much effort to add a line that checks if running in 'safe' mode, if that's what you want (by examining /proc/cmdline just the way rc.local does).

 

But, I want to discourage the use of the 'go' file for doing other kinds of things like installing add-ons.  There are two methods already in place for installing add-ons: the '/boot/extra' directory for slackware-type packages, and the two plugin directories, /boot/plugins and /boot/config/plugins for installing plg-type packages.  It's easy for an add-on creator to use one of these two methods of installing their add-on, instead of using the 'go' file.

Link to comment

Apparently no procedure runs it. I did got the idea that he had intentions to to call the file for safe-mode but then changed his mind and the file was left...

 

See: http://lime-technology.com/forum/index.php?topic=27960.msg252072#msg252072

Yes that's right, file left over from an implementation where rc.local did call a "go-safe"; removed in 5.0 'stable'.  Here's why I took it out.  In the normal case, there should not be anything in the 'go' file except vital code necessary for proper operation of the h/w platform.  That is all.  Yes it's been used for more than that in the past, but I'm trying to get away from that.

 

If someone is knowledgeable enough to edit the 'go' file and add extra stuff, then it's not much effort to add a line that checks if running in 'safe' mode, if that's what you want (by examining /proc/cmdline just the way rc.local does).

 

But, I want to discourage the use of the 'go' file for doing other kinds of things like installing add-ons.  There are two methods already in place for installing add-ons: the '/boot/extra' directory for slackware-type packages, and the two plugin directories, /boot/plugins and /boot/config/plugins for installing plg-type packages.  It's easy for an add-on creator to use one of these two methods of installing their add-on, instead of using the 'go' file.

 

How close is 5.0 Stable to being released??

 

 

Link to comment

Yes that's right, file left over from an implementation where rc.local did call a "go-safe"; removed in 5.0 'stable'.  Here's why I took it out.  In the normal case, there should not be anything in the 'go' file except vital code necessary for proper operation of the h/w platform.  That is all.  Yes it's been used for more than that in the past, but I'm trying to get away from that.

 

If someone is knowledgeable enough to edit the 'go' file and add extra stuff, then it's not much effort to add a line that checks if running in 'safe' mode, if that's what you want (by examining /proc/cmdline just the way rc.local does).

 

But, I want to discourage the use of the 'go' file for doing other kinds of things like installing add-ons.  There are two methods already in place for installing add-ons: the '/boot/extra' directory for slackware-type packages, and the two plugin directories, /boot/plugins and /boot/config/plugins for installing plg-type packages.  It's easy for an add-on creator to use one of these two methods of installing their add-on, instead of using the 'go' file.

Ok, true, and understood. Its just I was thrown off as we all know unMenu has been run from 'go' for the longest and thus no way to truly have safe mode if the stock 'go' file is loaded. I guess thats why we all felt the same way "right a go-safe file, makes sense".

Link to comment

Apparently no procedure runs it. I did got the idea that he had intentions to to call the file for safe-mode but then changed his mind and the file was left...

 

See: http://lime-technology.com/forum/index.php?topic=27960.msg252072#msg252072

Yes that's right, file left over from an implementation where rc.local did call a "go-safe"; removed in 5.0 'stable'.  Here's why I took it out.  In the normal case, there should not be anything in the 'go' file except vital code necessary for proper operation of the h/w platform.  That is all.  Yes it's been used for more than that in the past, but I'm trying to get away from that.

 

If someone is knowledgeable enough to edit the 'go' file and add extra stuff, then it's not much effort to add a line that checks if running in 'safe' mode, if that's what you want (by examining /proc/cmdline just the way rc.local does).

 

But, I want to discourage the use of the 'go' file for doing other kinds of things like installing add-ons.  There are two methods already in place for installing add-ons: the '/boot/extra' directory for slackware-type packages, and the two plugin directories, /boot/plugins and /boot/config/plugins for installing plg-type packages.  It's easy for an add-on creator to use one of these two methods of installing their add-on, instead of using the 'go' file.

 

I add rsync backup jobs to cron from my go file.  Where exactly should I put those if not in the go file ?

Link to comment

Apparently no procedure runs it. I did got the idea that he had intentions to to call the file for safe-mode but then changed his mind and the file was left...

 

See: http://lime-technology.com/forum/index.php?topic=27960.msg252072#msg252072

Yes that's right, file left over from an implementation where rc.local did call a "go-safe"; removed in 5.0 'stable'.  Here's why I took it out.  In the normal case, there should not be anything in the 'go' file except vital code necessary for proper operation of the h/w platform.  That is all.  Yes it's been used for more than that in the past, but I'm trying to get away from that.

 

If someone is knowledgeable enough to edit the 'go' file and add extra stuff, then it's not much effort to add a line that checks if running in 'safe' mode, if that's what you want (by examining /proc/cmdline just the way rc.local does).

 

But, I want to discourage the use of the 'go' file for doing other kinds of things like installing add-ons.  There are two methods already in place for installing add-ons: the '/boot/extra' directory for slackware-type packages, and the two plugin directories, /boot/plugins and /boot/config/plugins for installing plg-type packages.  It's easy for an add-on creator to use one of these two methods of installing their add-on, instead of using the 'go' file.

 

I add rsync backup jobs to cron from my go file.  Where exactly should I put those if not in the go file ?

The whole point of safe mode is that those would not/should not get loaded.

 

unMenu startup and the unMenu auto_install files are the only thing in my go file.

Link to comment

I add rsync backup jobs to cron from my go file.  Where exactly should I put those if not in the go file ?

 

Or this

If someone is knowledgeable enough to edit the 'go' file and add extra stuff, then it's not much effort to add a line that checks if running in 'safe' mode, if that's what you want (by examining /proc/cmdline just the way rc.local does).

 

Of course technically *I* am knowledge enough to edit my go file but I have no idea how to do what he says.  But I bet I could figure it out if I needed.  Orrrr you could and let us know ;-)

Link to comment

Maybe this code could be included in the default go script to save people who aren't entirely sure from screwing up their installs?

 

Also, shouldn't the start emhttp line appear outside of the if/else statements, since it should always be run?

It's a matter of style and is just an example.

 

it could easily be

 

critical code safe mode code here

run emhttp

 

if grep -wq unraidsafemode /proc/cmdline ; then

  logger "unRAID Safe Mode (unraidsafemode) has been selected, exiting go script early"

  exit

fi

 

non critical code here

 

Link to comment
It's a matter of style and is just an example.

I was thinking more along the lines that in your original example, emhttp would be run in safe mode but not in normal mode? Shouldn't it be:

# Load emhttp before anything else - we always need that running ;-)
/usr/local/sbin/emhttp &

# If "unraidsafemode" present on kernel command line, skip all add-ons
if grep -wq unraidsafemode /proc/cmdline ; then
  logger "unRAID Safe Mode (unraidsafemode) has been set"

  #Do your critical safe mode code here. then exit.
  #e.g.
  #/boot/unmenu/uu
  exit
else
  #Other code if not in safe mode. 
fi

Link to comment

It's a matter of style and is just an example.

I was thinking more along the lines that in your original example, emhttp would be run in safe mode but not in normal mode? Shouldn't it be:

# Load emhttp before anything else - we always need that running ;-)
/usr/local/sbin/emhttp &

# If "unraidsafemode" present on kernel command line, skip all add-ons
if grep -wq unraidsafemode /proc/cmdline ; then
  logger "unRAID Safe Mode (unraidsafemode) has been set"

  #Do your critical safe mode code here. then exit.
  #e.g.
  #/boot/unmenu/uu
  exit
else
  #Other code if not in safe mode. 
fi

 

I would use dgaschk 's method and one liner to short circut the execution.

 

I've been doing bash for so long that It's all second nature to me and I hardly think about it.

I do so much bash stuff that I write C loadable functions which become part of the bash shell just so that I can get things to run faster.

What I posted was really quick psuedo code and I'm going to delete it now.

Link to comment

#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp &

# If "unraidsafemode" present on kernel command line, exit now
if grep -wq unraidsafemode /proc/cmdline ; then exit ; fi

#Other code if not in safe mode. 
/boot/unmenu/uu

Nice, that should be in final  ;D

Link to comment

Tom when did the unRAID code change (release) and add "fuse_remember="330" to the share.cfg file? only when clicking "apply" in the smb settings page?

Doing so "clicking apply in the smb settings page, crashed emhttp on my system, services restarted and shares/disk accessible but WebGui inaccessible). I don't see any statement in the release notes to add or click apply to have this additional value set in share.cfg file.

 

This was discovered while troubleshooting an issue in http://lime-technology.com/forum/index.php?topic=28442.msg254366#msg254366

 

Secondary, so how does one reboot gracefully via command line, as I need to right now.

Link to comment

Tom when did the unRAID code change (release) and add "fuse_remember="330" to the share.cfg file? only when clicking "apply" in the smb settings page?

Doing so "clicking apply in the smb settings page, crashed emhttp on my system, services restarted and shares/disk accessible but WebGui inaccessible). I don't see any statement in the release notes to add or click apply to have this additional value set in share.cfg file.

Please capture system log.  The presence or absence of this setting should not cause any crashes.

 

This was discovered while troubleshooting an issue in http://lime-technology.com/forum/index.php?topic=28442.msg254366#msg254366

 

Secondary, so how does one reboot gracefully via command line, as I need to right now.

Stop all plugins.  Stop all network services.  Unmount the user share file system.  Unmount all the data disks.  Stop the md-driver.  Reboot.  Or stop any I/O to the server, reboot and cancel the subsequent parity check.

Link to comment

#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp &

# If "unraidsafemode" present on kernel command line, exit now
if grep -wq unraidsafemode /proc/cmdline ; then exit ; fi

#Other code if not in safe mode. 
/boot/unmenu/uu

Nice, that should be in final  ;D

 

+1 for final.

That's a really simple and elegant solution. Still wish there was some way to trigger safe mode from the webgui though.

Link to comment
Guest
This topic is now closed to further replies.