NAS4Free 11.1.0.4.4619 released (FreeBSD 11.1-RELEASE-P1)

[zoon01]

The NAS4Free Team is pleased to announce the release of version 11.1.0.4.4619 - Atomics

Download build 11.1.0.4.4619
Please Read always the readme_11.1 file

For who wants to know a bit more, here are the
FreeBSD-11.1R-release_notes
and the
FreeBSD-11.1R-hardware_notes

Major Change!

cifs/smb note:
==============
From Samba 4.5.0 and up the default value for the "ntlm auth" option is changed from "yes" to "no".
This may have impact on very old clients which doesn't support NTLMv2 yet.
Only if you really need NTLMv1 Authentication you can set in Additional Parameters: "ntlm auth = yes".

BUILD 11.1.0.4.4619

Changes after release 11.0.0.4.4578
===============================
- Update translations.
- Add CPU microcode update feature option.
- Add new framework to log settings.
- Upgrade virtualbox-ose to 5.1.28.
- Upgrade sudo to 1.8.21p2.
- Upgrade syncthing to 0.14.38.
- Upgrade rrdtool to 1.7.0.
- Upgrade samba to 4.6.8.

Fixes
- Fix snmp start, hrPrinterTable: printcap entry for <noname?> has errors.
- Fix define class before inheriting.

Note:
Clear your browser's cache to avoid display issues after upgrade when coming from older release like past 11.0 series.
Make a new backup of your system configuration and store this on safe location.

Enjoy!

Regards,
The NAS4Free Team

[ernie]

Hello

I used update via webgui. Before I checked the checksum of the file and it was fine.
The update works but I had to import my configuration (it was updated with default configuration).
There was such message on the nas4free for the update process launch by webgui (I don't have time to write it exactly):
- skipped : backing up boot.conf
- ERROR : .... read/write .... /cf

Finally after restore of my config file, all is fine

Thanks to developpers

Edit : on nas 2 it works without issue

[doktornotor]

@ernie: Looks like your storage is toast.

Still unusable webGUI upgrade on HP Gen8, same as described here. After pressing the Enable firmware upgrade, the only thing I get in browser is ERR_EMPTY_RESPONSE.

Code: Select all

# ps auxw | grep firmware
root         42982   0.0  0.0  13180  2780  -  I    14:17       0:00.01 /bin/sh /etc/rc.firmware enable

When I kill that process, I get

Code: Select all

# ps auxw | grep firmware
root         45971   0.0  0.0  13180  2780  -  I    14:22       0:00.04 /bin/sh /etc/rc.firmware disable

which also never terminates. When I kill that, I have WebGUI back.

Note: Replacing the USB stick did not help one tiny bit, as expected.

[scardig]

@ernie: Looks like your storage is toast.

Still unusable webGUI upgrade on HP Gen8, same as described here. After pressing the Enable firmware upgrade, the only thing I get in browser is ERR_EMPTY_RESPONSE.

Code: Select all

# ps auxw | grep firmware
root         42982   0.0  0.0  13180  2780  -  I    14:17       0:00.01 /bin/sh /etc/rc.firmware enable

When I kill that process, I get

Code: Select all

# ps auxw | grep firmware
root         45971   0.0  0.0  13180  2780  -  I    14:22       0:00.04 /bin/sh /etc/rc.firmware disable

which also never terminates. When I kill that, I have WebGUI back.

Note: Replacing the USB stick did not help one tiny bit, as expected.

Concerning to the webgui upgrade problem, if you are referring to this viewtopic.php?p=79972#p79972, (I was the author) I discovered that the problem was that I tried to upload to the .IMG instead of the .XZ of the firwmare so the upgrade failed since the destination partitition was too small for the uncompressed image .

bye

[doktornotor]

No, I am not having absolutely any chance whatsoever to upload anything. The GUI is gone after "enable firmware upgrade".

[tony1]

for what it's worth I have not had any issues upgrading utilizing the web gui.

[doktornotor]

FIY, the CPU microcode update feature is broken because

/etc/rc.d/microcode_update

Code: Select all

: ${microcode_update_datadir="%%DATADIR%%"}

Needs Makefile fix to REINPLACE_CMD that. (Or just skip the -d altogether.)

[tony1]

it's not broken. %%DATADIR%% is a place holder and the firmware location is hard coded in the binary.
seems to be working fine although there is no updates for my cpu that happens to be working fine
it is skipping %%DATADIR%% and using the default location, you can use System > Advanced > rc.conf to define an alternate location with microcode_update_datadir but it's not necessary.

[doktornotor]

Well yes it's a placeholder that's not supposed to stay there, should be replaced on build with the actual value with REINPLACE_CMD.

If you add -v option there to the cpucontrol call, you can see the problem. Just ditch the -d option altogether is the fastest fix here, the directory is not needed.

Code: Select all

Updating cpucodes...
cpucontrol: skipping directory %%DATADIR%%: not accessible
cpucontrol: skipping /usr/local/share/cpucontrol/m12306a9_0000001c.fw of rev 0x1c: up to date
cpucontrol: skipping directory %%DATADIR%%: not accessible
cpucontrol: skipping /usr/local/share/cpucontrol/m12306a9_0000001c.fw of rev 0x1c: up to date
Done.

BTW, the -v option would be good to add to see what's really happening there. Like:

Code: Select all

${CMT} -u -v /dev/cpuctl${i} || \

[tony1]

removing -d will probably break the ability to use rc.conf. the way I read your log is that it is skipping %%DATADIR%% because it is not defined and using the default location. it looks like your microcode is up to date and skipping the fw in the default location.

[doktornotor]

Uhm, no... it cannot break anything beyond how it's already broken. The rc.conf is handled by

Code: Select all

rcvar=microcode_update_enable
: ${microcode_update_enable="NO"}

The whole issue here is that In Makefile's do-install, you are missing something like:

Code: Select all

	@${REINPLACE_CMD} -i '' -e "s|%%DATADIR%%|${DATADIR}|" \
		${STAGEDIR}/etc/rc.d/microcode_update

If the rc script is not part of any package that's being built, simply replace all %%DATADIR%% with /usr/local/share/cpucontrol in the script manually. That placeholder certainly is not supposed to be there as explained above.

[tony1]

you could be correct. I bet the devs will read this and look into it.
in the meantime you can goto System > Advanced > rc.conf and use microcode_update_datadir for the name and /usr/local/share/cpucontrol/ for the value. at this point %%DATADIR%% will not be used. functionality will be the the same with or with out that modification but you will not get the skipping %%DATADIR%%
take care

[ms49434]

Uhm, no... it cannot break anything beyond how it's already broken. The rc.conf is handled by

Code: Select all

rcvar=microcode_update_enable
: ${microcode_update_enable="NO"}

The whole issue here is that In Makefile's do-install, you are missing something like:

Code: Select all

	@${REINPLACE_CMD} -i '' -e "s|%%DATADIR%%|${DATADIR}|" \
		${STAGEDIR}/etc/rc.d/microcode_update

If the rc script is not part of any package that's being built, simply replace all %%DATADIR%% with /usr/local/share/cpucontrol in the script manually. That placeholder certainly is not supposed to be there as explained above.

you haven't read the whole script ,

: ${microcode_update_enable="NO"} sets rc variable microcode_update only to NO if it doesn't exist.

But microcode_update is populated via

Code: Select all

# XQUERY: -i "count(//system/microcode_update) > 0" -o "0" -b
# RCVAR: microcode_update

which is examined by updateservices() in /etc/rc.d/rcconf and which sets rc variable microcode_update to YES or NO, depending on the setting stored in config.xml.

[doktornotor]

That's NOT what I'm talking about at all. I merely replied to the previous posting claiming incorrectly that removing the broken -d option would break the rc.conf stuff. No it wouldn't, has nothing to do with it.

Now, I have really more entertaining things to do than keeping to explain the issue that's been explained in detail over and over again. The script will do the job as long as /usr/sbin/cpucontrol has the proper default firmware directory path hardcoded, no matter the broken default variable setting in the script. (Yeah really the %%DATADIR%% does not belong there and yeah, really it produces errors - invisible when you don't run cpucontrol with the verbose switch.)

Moving to more important things - could someone have a look at the lagg patches? Being able to actually use lagg would be kinda useful on NAS.

[zoon01]

Moving to more important things - could someone have a look at the lagg patches? Being able to actually use lagg would be kinda useful on NAS.

This is not so easy is it seems for you! lots of that code from the links above needs to be checked and also be used in 11 stable tree.
Only stable code is used for the 11 releases, i don't know what diffs are more made. Just add and build can brake/fix or introduce other bugs.
This is not something like lets do this today and put into n4f stable releases!

I understand the pain, but fixes needs to go in 11 stable first before i adapt to release 11.x.

[doktornotor]

Well, then it won't happen apparently. The LAGG is totally unsuable, I frankly cannot see it getting more broken.

[zoon01]

Well, then it won't happen apparently. The LAGG is totally unsuable, I frankly cannot see it getting more broken.

It needs to be fixed upstream too
otherwise on FreeBSD 11.2 we will see the problems all over again.

You could compile n4f with the patches your self too and test if that is an option?
You will see how time consume it all is.
I am a bit limited on time for highly experimental builds.

[doktornotor]

Well it's been fixed upstream, it's just that fixing things is very much useless for another year or so when they are not MFCed. These patches have been working on pfSense for 8+ months, it's the same issue - https://redmine.pfsense.org/issues/7119. (It's HW independent, same panic with bge, igb, em...)

Perhaps you could get some insight from luiz (at) netgate.com or nag him somehow to get that pushed to 11.2 at least.

Anyway, thanks for your time.

[BodgeIT]

2nd update in a row, my update from webui has failed and required boot medium format and live USB re-install.

All good after that.

[kenZ71]

Dev team, have to say you have a much better record of flawless releases as compared to my employer - one of the largest in the US.

Speedbumps happen.

[scardig]

The NAS4Free Team is pleased to announce the release of version 11.1.0.4.4619 - Atomics

Download build 11.1.0.4.4619
Please Read always the readme_11.1 file

For who wants to know a bit more, here are the
FreeBSD-11.1R-release_notes
and the
FreeBSD-11.1R-hardware_notes

Major Change!

cifs/smb note:
==============
From Samba 4.5.0 and up the default value for the "ntlm auth" option is changed from "yes" to "no".
This may have impact on very old clients which doesn't support NTLMv2 yet.
Only if you really need NTLMv1 Authentication you can set in Additional Parameters: "ntlm auth = yes".

BUILD 11.1.0.4.4619

Changes after release 11.0.0.4.4578
===============================
- Update translations.
- Add CPU microcode update feature option.
- Add new framework to log settings.
- Upgrade virtualbox-ose to 5.1.28.
- Upgrade sudo to 1.8.21p2.
- Upgrade syncthing to 0.14.38.
- Upgrade rrdtool to 1.7.0.
- Upgrade samba to 4.6.8.

Fixes
- Fix snmp start, hrPrinterTable: printcap entry for <noname?> has errors.
- Fix define class before inheriting.

Note:
Clear your browser's cache to avoid display issues after upgrade when coming from older release like past 11.0 series.
Make a new backup of your system configuration and store this on safe location.

Enjoy!

Regards,
The NAS4Free Team

Hello,

the update was OK, only a lot of the following lines in logs:

Code: Select all

smbd[2152]: [2017/09/28 09:50:19.694092, 1] ../source3/smbd/notify_inotify.c:369(watch_destructor)
Sep 28 09:50:19	nas4free	smbd[2152]: inotify_rm_watch returned Invalid argument

Bye

[reun]

Still unusable webGUI upgrade on HP Gen8, same as described here. After pressing the Enable firmware upgrade, the only thing I get in browser is ERR_EMPTY_RESPONSE.

Code: Select all

# ps auxw | grep firmware
root         42982   0.0  0.0  13180  2780  -  I    14:17       0:00.01 /bin/sh /etc/rc.firmware enable

When I kill that process, I get

Code: Select all

# ps auxw | grep firmware
root         45971   0.0  0.0  13180  2780  -  I    14:22       0:00.04 /bin/sh /etc/rc.firmware disable

which also never terminates. When I kill that, I have WebGUI back.

I had the exact same experience trying to update from NAS4Free 11.1.0.4 (4517) to this version. I've been using the embedded version of NAS4Free for two years on my home NAS and this is the first time I've had any problems with updating the firmware.

The script just hung and the WebGUI became unresponsive after I pressed the Enable Firmware Upgrade button.

I eventually got around it somewhat accidentally by commenting out these lines in /etc/rc.firmware (4 instances) while trying to make it easier to trace what the script was doing:

Code: Select all

exec </dev/console >/dev/console 2>/dev/console

After those changes everything went well. I tried these modifications multiple times on both NAS4Free versions and the results were consistent. To me it looks like either the commands above make the script hang or they have a side effect on some of the later steps.

I would've included a patch if I could've found the source code. The official repository on GitHub doesn't seem to be the one used to build the binary I'm running. Does anyone know where one could track the development process?

[ms49434]

https://sourceforge.net/p/nas4free/code/commit_browser

[reun]

https://sourceforge.net/p/nas4free/code/commit_browser

Thanks!

So, this is what I did:

Code: Select all

Index: etc/rc.firmware
===================================================================
--- etc/rc.firmware	(revision 4619)
+++ etc/rc.firmware	(working copy)
@@ -41,7 +41,7 @@
 	# Redirect I/O to console.
 	# Prevent console redirect if no physical video adapter found.
 	if /usr/sbin/pciconf -l | grep -qw "vgapci[0-9]"; then
-		exec </dev/console >/dev/console 2>/dev/console
+		#exec </dev/console >/dev/console 2>/dev/console
 	fi
 
 	# Create efficient memory file system.
@@ -60,7 +60,7 @@
 	# Redirect I/O to console.
 	# Prevent console redirect if no physical video adapter found.
 	if /usr/sbin/pciconf -l | grep -qw "vgapci[0-9]"; then
-		exec </dev/console >/dev/console 2>/dev/console
+		#exec </dev/console >/dev/console 2>/dev/console
 	fi
 
 	# Get the md device.
@@ -85,7 +85,7 @@
 	# Redirect I/O to console.
 	# Prevent console redirect if no physical video adapter found.
 	if /usr/sbin/pciconf -l | grep -qw "vgapci[0-9]"; then
-		exec </dev/console >/dev/console 2>/dev/console
+		#exec </dev/console >/dev/console 2>/dev/console
 	fi
 
 	printf "\n\n\33[37m%s\33[0m\n" "Firmware upgrade in progress. Please wait..."
@@ -381,7 +381,7 @@
 	# Redirect I/O to console.
 	# Prevent console redirect if no physical video adapter found.
 	if /usr/sbin/pciconf -l | grep -qw "vgapci[0-9]"; then
-		exec </dev/console >/dev/console 2>/dev/console
+		#exec </dev/console >/dev/console 2>/dev/console
 	fi
 
 	printf "\n\n\33[37m%s\33[0m\n" "System upgrade in progress. Please wait..."

If you encounter this exact problem we've been having, one workaround that you could try at your on risk is to save that diff to a file and then run the following command as root:

Code: Select all

patch /etc/rc.firmware name-of-file.patch

Obviously this is just a workaround and not a solution to the problem.

[doktornotor]

@reun: I've been asking what's that code supposed to do and did not receive any meaningful reply there.

I'll try to comment out that nonsense code on next update and see how it goes.

[CryoFast]

After update to latest version I see this message on login screen in browser after 5-6 hours uptime:

Code: Select all

Warning: session_start(): open(/tmp/sess_1acd536c43a305c9f763e3cabaf4a890, O_RDWR) failed: No space left on device (28) in /etc/inc/session.inc on line 52 Warning: session_start(): Failed to read session data: files (path: /tmp) in /etc/inc/session.inc on line 52 Warning: Cannot modify header information - headers already sent by (output started at /etc/inc/session.inc:52) in /usr/local/www/auth.inc on line 40

What I can do?

[raulfg3]

After update to latest version I see this message on login screen in browser after 5-6 hours uptime:

Code: Select all

Warning: session_start(): open(/tmp/sess_1acd536c43a305c9f763e3cabaf4a890, O_RDWR) failed: No space left on device (28) in /etc/inc/session.inc on line 52 Warning: session_start(): Failed to read session data: files (path: /tmp) in /etc/inc/session.inc on line 52 Warning: Cannot modify header information - headers already sent by (output started at /etc/inc/session.inc:52) in /usr/local/www/auth.inc on line 40

What I can do?

more info about your system / install is needed.

1 - do you always update system or do a fresh install on 11 series? <- This question is because new 11 series need more boot space and a clean install not an upgrade.

[doktornotor]

/tmp is a symlink to /var/tmp ramdisk.

[CryoFast]

1 - do you always update system or do a fresh install on 11 series? <- This question is because new 11 series need more boot space and a clean install not an upgrade.

I get clean install and restore config.

[tony1]

CryoFast, how big is the flashdrive?

another question, how much ram do you have?