Hi all,
Le 2013-03-24 09:52, intrigeri a écrit :
> Hi fellow Tails developers, hi quidame!
>
> intrigeri wrote (23 Mar 2013 18:02:08 GMT) :
>> anonym wrote (20 Mar 2013 14:16:31 GMT) :
>>> New commits in bugfix/writable_boot_media:
>>> ae530a1 New fix for
>>> bugs/writable_system_disk:_belongs_to_floppy_group
>>> 05c8cf6 Add a shell library for determining stuff about the boot
>>> device.
>
>> Fixing t-p-s and the reasons behind its need for calling sgdisk is
>> on
>> it's way, but let's go parallel and do a first review pass on this
>> bugfix/writable_boot_media branch.
>
>> First, I do like the general solution you've implemented, and the
>> fact
>> it can be used to improve other, unrelated areas of Tails. Thanks!
>
> ... also, I forgot to mention that on the long run, we might want to
> offload some of this work and maintenance to bilibop [1]; a while
> ago,
> I've been discussing its usefulness for Tails with the upstream
> author
> (Cc'd) on the ITP [2], and reviewing their packaging on the RFS [3].
>
> In the end, IIRC I was quite happy with the packaging, but I did not
> sponsor the upload because I still was not sure we wanted to use it
> in
> Tails: on the one hand, it's generally great to replace custom code
> with some generic code maintained by others than us, who seem to be
> experts in the specific area this code is about; also, bilibop would
> presumably work on "exotic" installations of Tails that our custom
> code does not bother support; on the other hand, the fancy
> über-genericity of bilibop may seem slightly overkill for our needs.
>
> Unfortunately I lost track of what is missing to use bilibop in
> Tails.
>
> quidame: would you be interested in testing your latest bilibop
> packaging in Tails 0.17.1 and report back how it goes? (As of now,
> I think we're only interested in the "chgrp disk" feature.)
>
> anonym: do you want to have a look at bilibop when you're freed from
> your various commitments? I'd like someone else's opinion on
> this matter.
>
> [1] https://un.poivron.org/~quidame/bilibop_project/
> [2] http://bugs.debian.org/675467
> [3] http://bugs.debian.org/675532
>
> Cheers,
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##*/}*
That's all.
If you want to install bilibop packages with apt-get or the like, you
may see
https://un.poivon.org/~quidame/download/config/etc/apt/sources.list.d/quidame.list
for details. But I think these packages would be more trusted if they
were official.
For info, bilibop-udev is a new package (since 0.4.0); its only one
goal is to
provide the rule GROUP:="disk" for the drive hosting the running
system, and all
its partitions (at least for ms-dos and gpt partition tables). Nothing
else. It is
especially designed for LiveUSB systems, and is a subset of
bilibop-rules, which is
more complicated. I say LiveUSB, but it works also from SD or MMC flash
memory cards,
or firewire HDD. But the core is the bilibop-common shell functions :)
I have read the files affected by the last commit (ae530a1) in the
branch
bugfix/writable_boot_media:
-
config/chroot_local-includes/etc/udev/rules.d/99-boot-dev-ownership.rules
- config/chroot_local-includes/usr/local/sbin/udev-boot-dev-helper
-> no support for Firewire, SD-cards and the like
-> no support for fromiso=... boot method
I have read the last version (6c7c29db in the branch
bugfix/memory_wipe_on_removal_broken_with_fromiso):
- config/chroot_local-includes/usr/local/sbin/udev-watchdog-wrapper
-> I don't use fromiso=/dev/sdnX/tails.iso because it's not stable; I
prefer to
use
fromiso=/dev/disk/by-uuid/01234567-89ab-cdef-0123-456789abcdef/tails.iso,
and
some other people prefer to use .../by-label/...; these formats are not
taken
into account in the script (just add a readlink -f somewhere to do the
trick).
More generally, I think these two bugs/issues are about the same: what
is
the underlying device ? So, they should not be solved separately (and
another one
about fromiso=... boot method: the creation of a LUKS container from
the dedicated
GUI doesn't work - sorry, I say that, but I don't have tested since
Tails 0.14).
But it seems we are agree on this point.
Now, if you don't trust enough my poor packages to ship them into your
distro,
feel free to use their contents as you see fit; as you know, they are
licenced
under GPL-3.0+
cheers,
quidame
