ALT F 1.0 release upgrade notes

Kevin Roberts

unread,

Oct 14, 2017, 7:37:12 AM10/14/17

to Alt-F

I just finished updating to the Alt F 1.0 release firmware with no problems following the instructions provided. Smooth as it could be. Special reboot. Reboot. FlashIIt on my DNS323 B1, followed by the ipkg update via telnet.

Kernal flash took longer than 52s at 54 seconds and rootfs flash took 216 seconds just within the suggested parameter (217s).

A couple of significant and good developments for me after flashing.

The User Services page used to stall for sometimes as much as 30s before loading the minidlna status. It's now loading right away.

The Boot-Enabled setting for minidlna which had stopped working under the Alt F 1.0 snapshot is now working as expected.

After refreshing the ALT F package list there were a number of new packages, all updated smoothly.

Overall, couldn't have gone better for me and fixed all my current problems. Good job as always.

Steve Falces

unread,

Oct 23, 2017, 3:06:52 AM10/23/17

to Alt-F

netatalk not launching at boot adfter upgrade to v1.0

I love Alt-F. It has extended the usefulness of my good old NAS by years, it's fun to mess with, and I'm learning bits and pieces about linux along the way (please excuse my noobishness). Thanks to João and the community!

I updated my DNS-323/b1 from RC0.5 to v1.0 by following joão's instructions. All went well except for AFP (Apple Filing Protocol, netatalk). Under RC05, AFP launched on bootup, but under v1.0, it's not doing so.

I've marked netatalk and avahi_daemon to be launched at boot (Services>Network, checkboxes, Submit, Save settings).

I can see that despite this, they don't launch on boot up. I see this by the Alt-F web GUI and also by ps | grep netatalk (via ssh as root) and also by inspecting the contents of box's /var/log directory and noting the absence of any file named netatalk.log. The NAS does not appear in my Mac's Network list, and manually going there ( Finder>Go menu, Connect to server, afp://<nashostid> ) times out after a long wait. Other than that, I don't see any sign that AFP is failing to launch at boot (though I don't know where all to look); to me it looks like it's not being called.

After booting, I can then use the web GUI to launch netatlk (which also automatically launches avahi_daemon); or, I can use /etc/init.d/S51netatalk; either one succeeds in starting the AFP and avahi services. Again, testing with the GUI, ps, logfile and Mac client, each indicate that the service is running (though for the Mac test, there is a long (30s?) wait for the list of shares to appear, and the first connection takes a long time; subsequent listings and mountings are quick).

The box also has SMB "Boot enabled", and it's working. I have a Windows client that uses the shares provided by SMB. The shares are named uniquely (no AFP shares of the same name) and address locations that are not directly shared via AFP. The directory/share structure, it case it's germain:

/mnt
./sda2 <== served by SMB as "righty"

./share1 <== served by AFP as "share1"

./share2 <== (AFP, similar)

(so on)

The files S51netatalk and S50avahi_daemon are listed as -rwxr-xr-x 1 root root

I'd like to get AFP launching at boot time again; any help from the wonderful world of Alt-F to figure out just where mine "curves the wrong way"?

Thans - Steve

João Cardoso

unread,

Oct 23, 2017, 11:56:16 AM10/23/17

to Alt-F

On Monday, 23 October 2017 08:06:52 UTC+1, Steve Falces wrote:

netatalk not launching at boot adfter upgrade to v1.0

I love Alt-F. It has extended the usefulness of my good old NAS by years, it's fun to mess with, and I'm learning bits and pieces about linux along the way (please excuse my noobishness). Thanks to João and the community!

I updated my DNS-323/b1 from RC0.5 to v1.0 by following joão's instructions. All went well except for AFP (Apple Filing Protocol, netatalk). Under RC05, AFP launched on bootup, but under v1.0, it's not doing so.

I've marked netatalk and avahi_daemon to be launched at boot (Services>Network, checkboxes, Submit, Save settings).
I can see that despite this, they don't launch on boot up. I see this by the Alt-F web GUI and also by ps | grep netatalk (via ssh as root) and also by inspecting the contents of box's /var/log directory and noting the absence of any file named netatalk.log. The NAS does not appear in my Mac's Network list, and manually going there ( Finder>Go menu, Connect to server, afp://<nashostid> ) times out after a long wait. Other than that, I don't see any sign that AFP is failing to launch at boot (though I don't know where all to look); to me it looks like it's not being called.

I can't reproduce that... so I can't fix it. Maybe you can if you dig your box following directions.

Alt-F services are started in two steps:

1-Alt-F has some services built in the firmware, such as samba, ftp, nfs, etc, and they start if enabled as soon as the box boots, even with no disks attached.

2-When disks are recognized or plugged in and its filesystems are checked and mounted, when the first Alt-F folder is found on one of them the second "boot" step starts, and the enabled on-disk services are started.

If a service is already running, because it also exists in the firmware, it is restarted, so the previous version on the firmware stops and the new installed on disk can be started.

After this second step it is difficult to distinguish what comes from disk or from the firmware, as the folders and files existing under /Alt-F shadow the ones already existing. You shouldn't touch anything under /Alt-F without special precautions.

So, /Alt-F/etc/init.d/ only contains initscripts from disk-installed packages, and those are the ones that will be started if enabled:

[root@DNS-323]# ls -l /Alt-F/etc/init.d/
total 32
-rwxr-xr-x 1 root root 1968 Sep 22 17:36 S13modload
-rw-r--r-- 1 root root 1171 Mar 18 2015 S20dbus
-rw-r--r-- 1 root root 577 Nov 21 2016 S20hddtemp
-rw-r--r-- 1 root root 1432 Mar 18 2015 S50avahi_daemon
-rwxr-xr-x 1 root root 1489 Oct 23 14:31 S51netatalk
-rw-r--r-- 1 root root 1237 Oct 18 19:31 S62dropbear
-rwxr-xr-x 1 root root 1556 Oct 18 19:31 S62opensshd
-rw-r--r-- 1 root root 516 Oct 20 03:03 S81entware

But they appear also under /etc/init.d because of the shadowing process (better, folder unioning, handled by aufs.sh). That is the source of many confusion(*)

/var/log/hot_sh.log shows you what happens when a filesystem with an Alt-F folder is discovered:

[root@DNS-323]# cat /var/log/hot_aux.log

DATE=Mon Oct 23 14:40:11 WEST 2017
USER=root
HOME=/
OLDPWD=/
MDEV=sda2
TERM=vt102
SUBSYSTEM=sda
PATH=/sbin:/usr/sbin:/bin:/usr/bin
SHELL=/bin/sh
PWD=/dev
hot_aux: Start fscking sda2
hot_aux: Finish fscking sda2: fsck 1.41.14 (22-Dec-2010)
/dev/sda2: clean, 17958/19505152 files, 1397462/78011088 blocks
hot_aux: Users directory found in sda2
hot_aux: Public directory found in sda2
hot_aux: Alt-F directory found in sda2
hot_aux: Stopping modload: OK.
Starting modload: Fail:

hot_aux: Restarting netatalk:
Stopping netatalk: OK.
Starting dbus-uuidgen: OK.
Starting dbus-daemon: OK.
Starting avahi-daemon: OK.
Starting netatalk: OK.
hot_aux: Restarting sshd:
Stopping sshd: OK.
Starting sshd: OK.

And a /var/log/netatalk.log appears (not in your case).

Notice that avahi is a requirement for netatalk (and dbus a requirement for avahi), doesn't matter if they are enabled or not. When netatalk is stopped both will be stopped in the correct sequence and when netatalk is started they will be started in the correct sequence.

If dbus can't be started by whatever reason, then avahi will not be started, and netatalk can't be started.

You can see mostly all that happened using the 'logread' command right after a reboot, or, more comfortably, System->Utilities, Logs, System Log and looking near the end or searching for netatalk. Some services don't log to the system log, instead they use their own /var/log/<service>.log file.

Notice that the System Configuration "log" is generated at the end of the first boot step, and to regenerate it you need to hit the StartNow under Services->User. Before regenerating it, you will see no netatalk or avahi or dbus on it (look for the Services section -- 'rcall' from the command line), but after regenerating it you should see it:

root: netatalk running
root: avahi-daemon running
root: dbus-daemon running

(*) About aufs (another union file system)

there are three levels of folder unioning:

[root@DNS-323]# aufs.sh -l
aufs on / type aufs (rw,relatime,si=1a8e59c8)
/mnt/sda2/Alt-F=rw
/rootmnt/rw=rw
/rootmnt/ro=rr

this should be read from bottom up. At first, really-read-only, the original files from the firmware at /rootmnt/ro, so /rootmnt/ro/etc/init.d only contains the unmodified initscripts shipped with the firmware; if some of that files are modified, even its permissions, they will appear under /rootmnt/rw, which is read-write; modified files uses COW (Copy up On Writing); when finally a Alt-F folder appears on disk, the same thing happens (limitation -- only if the file or folder parents folder exists).

All these three folder structures are "amalgamated" together with complex rules to produce what you see under '/' and you should not directly manipulate them.

Ah, one more detail -- you will see in the System Log:

rcS: (14:40:07) loadsave_settings: loaded set_2017-10-23_14:33:00.tgz settings file.

That happens earlier on the boot, when no filesystem is still available. The settings archive contains a file with the name of initscripts that should be set to executable (executed on boot). As the Alt-F folder does not exists yet, it has no influence on it. initscripts files and its permissions for on-disk (Alt-F) installable packages are saved on disk, and should not appear under /rootmnt/ro or /rootmnt/rw.

If you have read so far, congratulations. I gave a full explanation because you gave a detailed report, thanks. You have now the basic knowledge to dig in your system, solve the issue and tell us what was happening wrong. Read also the "How to customise the firmware" wiki.

Steve Falces

unread,

Oct 23, 2017, 5:28:17 PM10/23/17

to Alt-F

Wow, João, that's a quick reply. I appreciate the passion.

Thanks for the explanation of the unioning, which I believe I now understand. If nothing else, I know that I might confuse myself if I alter the contents of /rootmnt.

I will start using the knowledge you've kindly offered; until then, here is some more detail, in case others wish to see how their own situation is similar/dissimilar.

On Monday, October 23, 2017 at 8:56:16 AM UTC-7, João Cardoso wrote:

So, /Alt-F/etc/init.d/ only contains initscripts from disk-installed packages, and those are the ones that will be started if enabled:

[root@DNS-323]# ls -l /Alt-F/etc/init.d/
total 32
-rwxr-xr-x 1 root root 1968 Sep 22 17:36 S13modload
-rw-r--r-- 1 root root 1171 Mar 18 2015 S20dbus
-rw-r--r-- 1 root root 577 Nov 21 2016 S20hddtemp
-rw-r--r-- 1 root root 1432 Mar 18 2015 S50avahi_daemon
-rwxr-xr-x 1 root root 1489 Oct 23 14:31 S51netatalk
-rw-r--r-- 1 root root 1237 Oct 18 19:31 S62dropbear
-rwxr-xr-x 1 root root 1556 Oct 18 19:31 S62opensshd
-rw-r--r-- 1 root root 516 Oct 20 03:03 S81entware

I confirm that my /Alt-F/etc/init.d ends up containing the three services under discussion (S20dbus, S50avahi_daemon and S51netatalk), each with perms identical to those listed above. More, below, about other files that I see in that location(*).

I also see that those three files must come from the disk - I conclude that because they don't exist in /rootmnt/ro/etc/init.d nor in /rootmnt/rw/etc.init.d, and they do exist on the "Package Folder" (Packages>Alt-F, Boot Enabled) location. By the way, that is a USB 'pen drive'; here, I tend to include details that may or may not be important, in case somebody more knowledgeable can use them.

My /var/log/hot_aux.log there has similar stuff in it (plus some non-similar, excerpt follows):

...

hot_aux: Start fscking sdc4
hot_aux: Finish fscking sdc4: fsck 1.41.14 (22-Dec-2010)
AFU: clean, 4200/32960 files, 87321/131835 blockshot_aux: Alt-F directory found in sdc4 (AFU is the label I put on the sdc4 filesystem)
hot_aux: Users directory found in AFR (AFR is the label I put on the sda4 filesystem, and it was once the ALT-F location before I moved it to AFU)
hot_aux: Public directory found in AFR
hot_aux: Restarting syslogd:
Stopping klogd: OK.
Stopping syslogd: OK.
Starting syslogd: OK.
Starting klogd: OK.
sh: /etc/init.d/S11urandom: unknown operand
hot_aux: /etc/init.d/S??urandom not found.

<eof>

(nothing about stopping/starting netatalk, avahi_daemon or dbus)

You can see the current state of any service just typing rc<service> [status|start|stop|restart|enable|disable|...], e.g. 'rcdbus status', or 'rcavahi status', or 'rcnetatalk' status.

in each of the three cases, the services are reported as "stopped".

You can see mostly all that happened using the 'logread' command right after a reboot, or, more comfortably, System->Utilities, Logs, System Log and looking near the end or searching for netatalk. Some services don't log to the system log, instead they use their own /var/log/<service>.log file.

Notice that the System Configuration "log" is generated at the end of the first boot step, and to regenerate it you need to hit the StartNow under Services->User. Before regenerating it, you will see no netatalk or avahi or dbus on it (look for the Services section -- 'rcall' from the command line), but after regenerating it you should see it:

root: netatalk running
root: avahi-daemon running
root: dbus-daemon running

Not surprisingly, each of those still appears in the log as "stopped" after Services>User, "StartNow" on "User" (which is also Boot Enabled).

(*) About aufs (another union file system)

there are three levels of folder unioning:

[root@DNS-323]# aufs.sh -l
aufs on / type aufs (rw,relatime,si=1a8e59c8)
/mnt/sda2/Alt-F=rw
/rootmnt/rw=rw
/rootmnt/ro=rr

[snip]

Ah, one more detail -- you will see in the System Log:
rcS: (14:40:07) loadsave_settings: loaded set_2017-10-23_14:33:00.tgz settings file.

My System Log does not have any similar entry, though in System > Settings, there are settings archives to choose from.

To be honest, I'm not sure just how to apply my new knowledge; I may try System>Settings, ClearSettings or FormatFlashSetings to see if the 'shotgun' approach works.

Whatever happens, I'll post a follow-up, though it may take some days.

João Cardoso

unread,

Oct 24, 2017, 12:36:19 PM10/24/17

to Alt-F

On Monday, 23 October 2017 22:28:17 UTC+1, Steve Falces wrote:

Wow, João, that's a quick reply. I appreciate the passion.

Thanks for the explanation of the unioning, which I believe I now understand. If nothing else, I know that I might confuse myself if I alter the contents of /rootmnt.

I will start using the knowledge you've kindly offered; until then, here is some more detail, in case others wish to see how their own situation is similar/dissimilar.

On Monday, October 23, 2017 at 8:56:16 AM UTC-7, João Cardoso wrote:
So, /Alt-F/etc/init.d/ only contains initscripts from disk-installed packages, and those are the ones that will be started if enabled:

[root@DNS-323]# ls -l /Alt-F/etc/init.d/
total 32
-rwxr-xr-x 1 root root 1968 Sep 22 17:36 S13modload
-rw-r--r-- 1 root root 1171 Mar 18 2015 S20dbus
-rw-r--r-- 1 root root 577 Nov 21 2016 S20hddtemp
-rw-r--r-- 1 root root 1432 Mar 18 2015 S50avahi_daemon
-rwxr-xr-x 1 root root 1489 Oct 23 14:31 S51netatalk
-rw-r--r-- 1 root root 1237 Oct 18 19:31 S62dropbear
-rwxr-xr-x 1 root root 1556 Oct 18 19:31 S62opensshd
-rw-r--r-- 1 root root 516 Oct 20 03:03 S81entware

I confirm that my /Alt-F/etc/init.d ends up containing the three services under discussion (S20dbus, S50avahi_daemon and S51netatalk), each with perms identical to those listed above. More, below, about other files that I see in that location(*).

You forget to include that. What are the exact contents ('ls -l' command) of your /Alt-F/etc/init.d folder?

There is something wrong, klog, syslog shouldn't be restarted, and there is an error in urandom that should not appear. Pherhaps it is that error that stops the process.

Try using the 'fixup clean' command to remove stray copies from the old fw that might exist under /Alt-F.

I believe that with your copy or move of the Alt-F folder something has been screwed. There might exist "settings" that point to the other location, not sure.

Under Packages->Alt-F have you deleted the non active Alt-F installation?

Steve Falces

unread,

Oct 24, 2017, 8:15:12 PM10/24/17

to Alt-F

Seems that 'fixup clean' did the trick! See below.

On Tuesday, October 24, 2017 at 9:36:19 AM UTC-7, João Cardoso wrote:

On Monday, 23 October 2017 22:28:17 UTC+1, Steve Falces wrote:
Wow, João, that's a quick reply. I appreciate the passion.

Thanks for the explanation of the unioning, which I believe I now understand. If nothing else, I know that I might confuse myself if I alter the contents of /rootmnt.

I will start using the knowledge you've kindly offered; until then, here is some more detail, in case others wish to see how their own situation is similar/dissimilar.

I confirm that my /Alt-F/etc/init.d ends up containing the three services under discussion (S20dbus, S50avahi_daemon and S51netatalk), each with perms identical to those listed above. More, below, about other files that I see in that location(*).

You forget to include that. What are the exact contents ('ls -l' command) of your /Alt-F/etc/init.d folder?

Oops, I did forget. Head is spinning from learning so rapidly :)

Here's the output:

[root@slurry]# ls -l /Alt-F/etc/init.d

total 84

-rwxr-xr-x 1 root root 758 Oct 20 21:31 S10syslog

-rwxr-xr-x 1 root root 897 Oct 20 21:31 S11urandom

-rw-r--r-- 1 root root 1171 Oct 20 21:31 S20dbus

-rw-r--r-- 1 root root 474 Oct 20 21:31 S26cron

-rw-r--r-- 1 root root 472 Oct 20 21:31 S27at

-rw-r--r-- 1 root root 738 Oct 20 21:31 S29mdadm

-rw-r--r-- 1 root root 1607 Oct 20 21:31 S30backup

-rw-r--r-- 1 root root 1115 Oct 20 21:31 S31cleanup

-rw-r--r-- 1 root root 1250 Oct 20 21:31 S31news

-rw-r--r-- 1 root root 499 Oct 20 21:31 S41http

-rwxr-xr-x 1 root root 2060 Oct 20 21:31 S41inetd

-rw-r--r-- 1 root root 1205 Oct 20 21:31 S42dnsmasq

-rw-r--r-- 1 root root 2064 Oct 20 21:31 S43ntp

-rw-r--r-- 1 root root 1432 Oct 23 10:50 S50avahi_daemon

-rwxr-xr-x 1 root root 1488 Oct 23 16:25 S51netatalk

-rw-r--r-- 1 root root 1538 Oct 1 2014 S52lighttpd

-rwxr-xr-x 1 root root 935 Jun 11 11:05 S61smb

-rw-r--r-- 1 root root 320 Oct 20 21:31 S63rsyncd

-rw-r--r-- 1 root root 1533 Oct 20 21:31 S63vsftpd

-rw-r--r-- 1 root root 663 Oct 20 21:31 S98ffp

-rwxr-xr-x 1 root root 2542 Oct 23 15:41 S99user

There is something wrong, klog, syslog shouldn't be restarted, and there is an error in urandom that should not appear. Pherhaps it is that error that stops the process.
Try using the 'fixup clean' command to remove stray copies from the old fw that might exist under /Alt-F.

Running 'fixup clean' seems to have resolved the boot-enabling of the netatalk service

And here's the list from /Alt-F/etc/init.d after running 'fixup clean':

[root@slurry]# ls -l /Alt-F/etc/init.d

total 12

-rwxr-xr-x 1 root root 897 Oct 20 21:31 S11urandom

-rw-r--r-- 1 root root 1171 Oct 20 21:31 S20dbus

-rw-r--r-- 1 root root 1205 Oct 20 21:31 S42dnsmasq

-rw-r--r-- 1 root root 1432 Oct 23 10:50 S50avahi_daemon

-rwxr-xr-x 1 root root 1488 Oct 24 16:52 S51netatalk

-rw-r--r-- 1 root root 1538 Oct 1 2014 S52lighttpd

-rwxr-xr-x 1 root root 935 Jun 11 11:05 S61smb

That's quite a bit of fixup cleaning. But, I should also admit, that is after copying the Alt-F package location to another file system, marking the new one as "boot-enabled", dis-enabling the old one, rebooting (noting the AUFS message when the web GUI returned after reboot), and then deleting the old location (managed by Packages>Alt-F). Perhaps somehow this accounts for the reduction of files present.

I believe that with your copy or move of the Alt-F folder something has been screwed. There might exist "settings" that point to the other location, not sure.
Under Packages->Alt-F have you deleted the non active Alt-F installation?

I had tried various combinations of single and multiple copies of Alt-F package locations (managed by Packages>Alt-F, Packages Installed On), always at least one Boot-enabled; all combinations seemed to give identical results. The results we've seen in this thread prior to this current post had only one location defined; of course, it was boot-enabled. As mentioned, it now seems to be working better.

Thanks, João! Not just for helping me out of my individual predicament, and not only for creating Alt-F, but for taking care of it and the community so much over the years!

João Cardoso

unread,

Oct 25, 2017, 11:24:24 AM10/25/17

to Alt-F

That's not all that got cleared, but not everything was cleared.

S11urandom is a stray file from previous fw, it was then named S10uramdom, so it was not cleared by 'fixup'. You can do that by executing

aufs.sh -n
rm /Alt-F/etc/init.d/S11urandom
aufs.sh -r

S42dnsmasq is also probably a stray file, as on the dns-321/323 the dnsmasq pkg was removed from 1.0 and was present on previous fw. Only you can tell. If you have not installed 'dnsmasq' by yourself, you can/should also remove it as in the code above.

S61smb is from samba, have you installed samba (not small) on disk? If you have, its legitimate, otherwise you can also remove it.

The same for S52lighttpd, it is legitime if you have installed the lighttpd package, otherwise it is not.

How to know if a package is installed on disk (and it removable) or in the firmware (not removable)? There are several ways of determining this.

In the easiest one you can look under Packages->Alt-F in the section of installed/preinstalled packages. If the Remove button is grayed out for a package, the pkg comes from the firmware, otherwise it is installed on disk (and is removable).

Sometimes a pkg that is shipped with the fw is upgraded, and can be updated on disk, shadowing the original files. E.g, if package foo with version 1.2.3 is on the fw, its Remove button will be grayed out, but if a foo with version 1.2.4 is released and you update it, the Remove button becomes active. If latter on you decide that 1.2.4 is buggy and want to revert back to 1.2.3, you can hit the Remove button, and the 1.2.3 version in the fw will "resurrect" and the Remove button becomes grayed out again.

But, I should also admit, that is after copying the Alt-F package location to another file system, marking the new one as "boot-enabled", dis-enabling the old one, rebooting (noting the AUFS message when the web GUI returned after reboot), and then deleting the old location (managed by Packages>Alt-F). Perhaps somehow this accounts for the reduction of files present.

I believe that with your copy or move of the Alt-F folder something has been screwed. There might exist "settings" that point to the other location, not sure.
Under Packages->Alt-F have you deleted the non active Alt-F installation?
I had tried various combinations of single and multiple copies of Alt-F package locations (managed by Packages>Alt-F, Packages Installed On), always at least one Boot-enabled; all combinations seemed to give identical results. The results we've seen in this thread prior to this current post had only one location defined; of course, it was boot-enabled. As mentioned, it now seems to be working better.

Thanks, João! Not just for helping me out of my individual predicament, and not only for creating Alt-F, but for taking care of it and the community so much over the years!

Thanks.

I fee responsible for something that I have done and is being used by other people. An oldish way of thinking, I know :-(

Reply all

Reply to author

Forward