hotplug ** DISCONTINUED **

[johnbock]

But one question: how is freetz_hotplug.patch applied?
something like: patch -p1 < freetz_hotplug.patch

execute

patch -p0 <freetz_hotplug.patch

in the freetz project directory. And please read #7 thoroughly.

 

[johnbock]

Attached is the version 0.5.2 of the hotplug replacement:

changes include:
automatic fsck for ext2 file systems (ext3 support has been temporarily removed)
new directory structure
drop-in support for file systems (example implementations for ext2, vfat)
rudimentary support for services (start, stop and drop-in)
support for UUID and LABEL (requires bb 1.10.1 w/ volumeid)

This is still an experimental release, use at your own risk... But I've been using it for about a week now

 

[poruid]

Would it be possible to call the original AVM hotplug entry point for events that are not (yet) handled by the new hotplug chain?
As it seems that the AVM hotplug handling is not really re-entrant (it uses a guard, a kind of lock, and sleeps) the new hotplug chain would, when it calls the AVM hotplug handler, probably need to stall (or queue) events until the AVM hotplug routine returns.

BTW: does anyone know what eventadd does?

 

[cuma]

eventadd adds an event to the "Ereignisse". try

eventadd 1 "Hellau"

 

[johnbock]

the new hotplug chain would, when it calls the AVM hotplug handler, probably need to stall (or queue) events until the AVM hotplug routine returns.

The hotplug replacement will (does) not use the avm chains. However, the hotplug replacement will provide hooks for the avm chains. This is required to allow the avm web pages to seem to work as usual

BTW, to test the hotplug block modules one can reset the HD doing the following:

1. determine the attached disk device: i.e. sda, sdb
2. ensure the partitions are neither mounted nor swapped
3. perform the following to determine the scsi host, channel, id and lun

   $ echo /sys/block/sda/device/scsi_disk:* | sed 's/[^:]*://;s/:/ /g'
     0 0 0 0
   # | | | +-- lun     \
   # | | +---- id       > not sure of the order...
   # | +------ channel /
   # +-------- host

4. detach the disk

   $ echo >/sys/block/sda/device/delete

5. reattach the disk

   $ echo 0 0 0 >/sys/class/scsi_host/host0/scan

All actions performed by the hotplug replacement are protocolled (local0.(debug|info|error)) to syslog. Normally, I redirect syslogd to another linux machine (server) where the protocol is either permently saved for later analysis or monitored near-time

 

[poruid]

In the 0.5.2 patch the selectability of the new hotplug chain depends on FREETZ_TYPE_FON_WLAN_7270. I've a 7170, is there any reason to assume the patch would not work with the 7170, is there anything very specific for the 7270?

 

[johnbock]

In the 0.5.2 patch the selectability of the new hotplug chain depends on FREETZ_TYPE_FON_WLAN_7270. I've a 7170, is there any reason to assume the patch would not work with the 7170, is there anything very specific for the 7270?

I don't have a 7170 and I have no idea of the underlying architecture, that's why I didn't initially enable support for the device. If your technically inept you could try your luck.

I don't think anything horrible will happen to the box. But, if I were you I wouldn't connect any partitions containing important data. However, I cannot be held responsible if anything goes wrong or if you kill/brick your device(s)

 

[poruid]

I've tried my luck, but ..

My FB uses usbroot; the rootfs is pivotted to /dev/sda1:/freetz-devel-2192M/ (a subdirectory of the partition).
Because your patch removes (comments out) the /dev/sd* entries in the device.table I cannot (manually) mount /dev/sda1 where I write usbroot filesystem below a subdirectory when a new firmware has been compiled.
Altough the FB boots fine from the usbroot, there is possibillity to (manually) mount /dev/sda1 what would allow me to write outside the directory that is mounted on /.

Any suggestions?

 

[johnbock]

Because your patch removes (comments out) the /dev/sd* entries in the device.table I cannot (manually) mount /dev/sda1 where I write usbroot filesystem below a subdirectory when a new firmware has been compiled.

As soon as the usbcore (7270 uses usbcore and musb_hdrc) is loaded the hotplug events are generated and the partition should automatically create the device nodes and subsequently mount the partition.
Are you sure hotplug is active at boot? If you are not currently using this hotplug core then do a 'make hotplug-uninstall' and a subsequent make: that will reverse all changes to the two device tables (root/.. & tools/...).

If you wish to mount the partition somewhere else as /var/media/ftp/uStor[0-9][0-9] then put it in /etc/fstab. If only that partition of the specific HD should be so mounted then put the UUID (blkid <partition>) of the partition in fstab. The hotplug core will then mount that specific partition to the stated mountpoint without intervention. I'm not sure, but I think in that version one can tell hotplug to create the nodes but not automatically mount the partition: take a look at 'man fstab'.

HTH

 

[Silent-Tears]

Please have a look at his signature. He doesn't use the 7270, he has "only" the 7170 and hast none of your usb-modules.

 

[johnbock]

Please have a look at his signature. He doesn't use the 7270, he has "only" the 7170 and hast none of your usb-modules.

Doesn't the 7170 use the module usbcore? The 7270, at least, loads the required hardware usb modules in rc.S and rc.usbhost (which is called from rc.S). Once the hardware specific usb drivers are loaded the events should be generated. The program /sbin/hotplug just redistributes the events.

 

[olistudent]

usbroot loads the modules for itself and disables hotplug!

Greets Oliver

 

[johnbock]

usbroot loads the modules for itself and disables hotplug!

Greets Oliver

Gotta put that on my list

 

[johnbock]

hotplug 0.6.0a - full disk support

Now knowing a little more of the 7270 and freetz I'm releasing this version of the hotplug replacement. Although alpha is still in the version name the logic of the memory key and hard disk recognition and mounting is complete.

Because of my ignorance of the 7170 and other boxes featuring an usb interface I have again limited the support to the 7270. Although, the different boxes have specific low level drivers, the controlling logic should be similar enough in order for this implementation (possibly with minor changes) to work.

Things this version does NOT support:

• This version brings no working hooks into freetz. There is however, a mechanism to hook services into mount hotplug events. The mechanism is also available while detaching devices using avm's web usb front-end.
• ntfs-3g is included, but because of several trouble reports of filesystems excluded by the original avm, has been turned off. If you absolutely require support for this filesystem type and are aware of these problems, see the files make/hotplug/files/root/bin/mount.ntfs-3g and make/hotplug/files/root/lib/hotplug/mount/ntfs-3g.mount.
• Hardware other than memory keys, hard disks and Stick 'N Surf AVM Wlan Sticks.
• No events are reported to the avm web front-end.

Now for the good stuff: what exactly is supported in this version

• Should support all memory keys, hard disks and AVM Stick 'N Surf Wlan Sticks. Minis should also work correctly but don't have one to test.
• Device nodes are generated and cannot be avoided or turned off.
• Currently, mount hooks are provided for the filesystems vfat, ext2, ext3, ntfs-3g (disabled).
• Automatic filesystem recognition, checking (ext2, ext3) and subsequent mount to either a generated or configured mountpoint.
• Generated mountpoints are found under /var/media/ftp and are named uStor<block group name a-i><partition number 0-9> as they are under the default freetz mountpoint convention.
• Configured mountpoints are found in /etc/fstab. The devices may be identified by UUID, LABEL or device node path.
• The configured mountpoints may exist anywhere in the filesystem. Non-existent mountpoints will when possible be created. I put my existent mountpoints in /data (non-volatile and rw).
• All mounts (even swaps) are exported to the avm web usb front-end. For the curious in the file /var/media/devmap.
• The full path of the mount is displayed. Exception here is a swap is displayed as the 'nicename' in freetz followed by a '/swap'.
• All mounts (even swaps) may be collectively umounted or swapped-off using the avm web usb front-end.
• Executable scripts or links in '.freetz/service' will be executed with a single argument 'start' in the hotplug mount event chain. The naming convention of these is 'S[0-9][0-9].*' I generally use 'S[0-9][0-9]<service>.sh'.
• Executable scripts or links in '.freetz/service' will be executed with a single argument 'stop' in the avm collective umount front-end function. This also acts as chain lead for all subsequent hotplug events. The naming convention of these is 'K[0-9][0-9].*'. I genernally use 'K[0-9][0-9]<service>.sh'.
• All events are reported to syslogd.
• All partitions are umount/unswapped prior to upgrading the firmware and at system reboot.

Prerequisites:

• freetz-1.1
• syslogd, though not required is recommended.
• e2fsprogs will be automatically selected by choosing the hotplug package in the 'testing' menu.
• busybox 1.10.2

Installation and Build:
The three patches have been diff'ed against freetz-1.1. And may be applied in the freetz svn project directory with

$ bzip2 -cd <patch> | patch -p0

The hotplug package must be unpacked in the freetz svn project directory with

$ tar jxvf <tar file>

After the patches have been applied and the tar package correctly unpacked

make menuconfig

must be executed to select the hotplug package. The menu points 'Package Selection->Testing->hotplug' must all be selected before exiting and saving the new configuration.
To ensure proper compilation the following must be executed prior to building the new image:

$ make busybox-dirclean
$ make e2fsprogs-dirclean
$ make hotplug-dirclean
$ make hotplug-uninstall
$ make

Enhancement for Additional Filesystem Types:
A development hook for mounts is included in the file make/hotplug/files/root/lib/mount/unrecognized. This may be exploited by copying the file to /var/tmp and subsequently binding the file to the original

$ cp /lib/hotplug/mount/unrecognized /var/tmp/<newfs>.mount
$ mount -o bind /var/tmp/<newfs>.mount /lib/hotplug/mount/unrecognized

The implementation may be completed by enhancing the file internal case statement with the filesystem type as determined by blkid <path to dev node containing the new filesystem>.

#!/bin/false
# vim: se ft=sh:

# this is actually a development hook

# cp /lib/hotplug/mount/unrecognized /var/tmp/newfs.mount
# mount -o bind /var/tmp/newfs.mount /lib/hotplug/mount/unrecognized

case "$FSTYPE" in
	*)
		log_error "unrecognized filesystem type '$FSTYPE' on '$NODEPATH'"
		;;
esac

Filesystem support for luks and a linux-raid may be developed in this manner



Wishing you lots of fun and if I can help, just ask...

 

[xsapling]

kann man das Nachfolgende bitte einmal in deutsch bekommen?

Enhancement for Additional Filesystem Types:
A development hook for mounts is included in the file make/hotplug/files/root/lib/mount/unrecognized. This may be exploited by copying the file to /var/tmp and subsequently binding the file to the original

$ cp /lib/hotplug/mount/unrecognized /var/tmp/<newfs>.mount
$ mount -o bind /var/tmp/<newfs>.mount /lib/hotplug/mount/unrecognized

The implementation may be completed by enhancing the file internal case statement with the filesystem type as determined by blkid <path to dev node containing the new filesystem>.

#!/bin/false
# vim: se ft=sh:
 
# this is actually a development hook
 
# cp /lib/hotplug/mount/unrecognized /var/tmp/newfs.mount
# mount -o bind /var/tmp/newfs.mount /lib/hotplug/mount/unrecognized
 
case "$FSTYPE" in
    *)
        log_error "unrecognized filesystem type '$FSTYPE' on '$NODEPATH'"
        ;;
esac

Filesystem support for luks and a linux-raid may be developed in this manner



Wishing you lots of fun and if I can help, just ask...

 

[xsapling]

ich erhalte folgende Meldung bei Anwendung des nachfolgenden Codes:

bzip2 -cd hotplug-busybox-Config.8mb_26.patch.bz2 | patch -p0
patching file make/busybox/Config.8mb_26
Hunk #1 FAILED at 484.
1 out of 1 hunk FAILED -- saving rejects to file make/busybox/Config.8mb_26.rej

Revision: 2288

Alle anderen Patches liefen durch ...

 

[johnbock]

ich erhalte folgende Meldung bei Anwendung des nachfolgenden Codes:

bzip2 -cd hotplug-busybox-Config.8mb_26.patch.bz2 | patch -p0
patching file make/busybox/Config.8mb_26
Hunk #1 FAILED at 484.
1 out of 1 hunk FAILED -- saving rejects to file make/busybox/Config.8mb_26.rej

Revision: 2288

Alle anderen Patches liefen durch ...

I can only guess at what has happened, but did you check out freetz-1.1? As I have mentioned above, all patches were diff'ed against freetz-1.1. If you are currently building against the freetz-1.1 branch please post the compressed reject file.

 

[Eliot007]

@xsapling: please use busybox 1.10.2 from freetz-1.1 because the config-file is different to the one from busybox 1.9.2 in rev. 2288.
I did this and then it works for me

 

[xsapling]

könnt ihr bitte nochmal gucken, ob es jetzt aber eine wirkliche Unverträglichkeit mit dem hotplug gibt. Denn nun erhalte ich:

fff@fff-laptop:~/freetz-11$ bzip2 -cd hotplug-patch.bz2 | patch -p0 
patching file make/Config.in
Hunk #1 FAILED at 81.
1 out of 1 hunk FAILED -- saving rejects to file make/Config.in.rej

Zur Abwechslung läuft

bzip2 -cd hotplug-busybox-Config.8mb_26.patch.bz2 | patch -p0

nun durch.

 

[Silent-Tears]

Pfleg die Sachen von Hand ein, denn in der Config in hat sich was geändert, so dass der Patch nciht merh funktioniert. Oder warte es ab