July 14, 201312 yr 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.
July 15, 201312 yr 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
July 15, 201312 yr 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.
July 15, 201312 yr 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?
July 15, 201312 yr 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.
July 16, 201312 yr 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
July 16, 201312 yr Ok, but the go-safe file is included in the RC16c source so What procedure runs the go-safe file?
July 16, 201312 yr 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
July 16, 201312 yr Author 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.
July 16, 201312 yr 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??
July 16, 201312 yr 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".
July 16, 201312 yr 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 ?
July 16, 201312 yr guess somebody would have to make a cron editor plg script that loads the saved cron jobs .... just first idea what comes in my head ... or tom could make it a gui feature
July 16, 201312 yr 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.
July 16, 201312 yr 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 ;-)
July 16, 201312 yr 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?
July 16, 201312 yr 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
July 16, 201312 yr #!/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
July 16, 201312 yr 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
July 16, 201312 yr Updated to RC16c last week and it seems to be working fine for me. It runs better than one of the older rc5 i had been running. I had to add an irqpoll option to it to get it to run properly but that is no longer needed!!
July 16, 201312 yr 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.
July 16, 201312 yr #!/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
July 16, 201312 yr 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.
July 16, 201312 yr Author 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.
July 16, 201312 yr #!/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 +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.
Archived
This topic is now archived and is closed to further replies.