Hi,
quidame@??? wrote (25 Mar 2013 12:00:11 GMT) :
> Right. The shortest way to test bilibop in Tails context is the following:
> 1. Boot on Tails 0.17.1 (with or without the fromiso=... variant), and set
> up a password for the user account
> 2. Get bilibop-common and bilibop-udev packages:
> - build them from the source (https://mentors.debian.net/packages/bilibop/)
> - download them (https://un.poivron.org/~quidame/debian/pool/main/b/bilibop/)
> - or see the attachments.
> and install them on the system, or extract and copy only the needed files:
> /lib/bilibop/common.sh
> /lib/bilibop/disk
> /lib/bilibop/test
> /lib/udev/rules.d/66-bilibop.rules
> 3. To finish:
> # invoke-rc.d udev restart
> # DISK=$(/lib/bilibop/disk)
> # udevadm trigger --sysname-match=${DISK##*/}*
These steps did work for me on Tails 0.17.2 installed on a USB stick
with the Tails USB installer, using bilibop-udev 0.4.10~quidame.
Yeah :)
However, shouldn't bilibop-udev.postinst run `invoke-rc.d udev
reload'? Just installing the package, despite the udevadm trigger in
this postinst maintainer script, was not enough to have the
permissions changed, and indeed the udev restart + trigger was needed.
Anyway, this is mostly irrelevant for Tails, since all we need is the
udev rule to do its job at boot time, and this postinst script fails
for us anyway, as reported in my previous email.
Actually, I'm starting to think this postinst should just not exist at
all: as currently implemented, it breaks support for the standard
Debian Live system (built with live-build) usecase, without bringing
support for the "install bilibop-udev at runtime" usecase as
apparently intended, so I fail to see what good this script makes.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
