Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
Hi again, quidame wrote (10 Jun 2013 16:05:08 GMT) : Hmm... I think it is not the best way: 1. bilibop-rules provides other features that are absolutely not Tails (Debian Live) related: helper scripts to manage grub device.map, or to modify LVM config, or to make /etc/udev/rules.d/70-persistent*.rules unpersistent... this is why bilibop-udev exists OK, totally makes sense. 2. the only one relevant file in bilibop-udev is 66-bilibop.rules; so it is possible to modify it again (+2 lines), or even not install bilibop-udev (but only bilibop-common), and add a specific rules file in the amnesia git repository (I think in config/chroot_local-includes/etc/udev/rules.d/). Additionally, you could merge it with the existing 99-hide-TailsData.rules. In that case, this could give: [...] What do you think about that ? Great, I do like it! It allows us to externalize the bulk of the work to bilibop (which is great), while at the same time giving us fine-grained control on what exactly we want it to do. If needed I can help to write what you need. I'll give it a try ASAP, and will get back to you if I need help. Thanks for the offer :) Another possibility could be to kill bilibop-udev and replace it by bilibop-live, with live-specific additional stuff (but this is not done). This sounds useful, but I suggest we start with the solution described above; then if we're happy with it, we can consider generalizing it, and making it available to all Debian Live users. But well, if you feel confident enough to work on a bilibop-live package on the short term, I certainly don't meant to discourage you. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
Hi, quid...@poivron.org wrote (13 May 2013 00:57:02 GMT) : Could you try the new version (0.4.11~quidame), please ? Thanks a lot for your prompt response! I've tried it, and it works fine for me (and makes the boot device has safe access rights test pass), so I've merged our feature/bilibop branch into the experimental one. I'd like to fix this bug for 0.18.1 or 0.19. So, the question now is: do we want to use bilibop to fix this serious bug, or develop and maintain a in-house solution? A. bilibop pros: - already works in a way that I'd be happy to ship in our next stable release - we don't have tomaintain it: quidame does - it supports more hardware / boot media / installation modes than we'll ever do ourselves cons: - we (well, I) have to sponsor it in Debian - quite a lot of code for something that may look simple B. home-made solution pros: - less code cons: - the code is not finished (yet) - we have to maintain it ourselves - only supports the hardware / boot media / installation modes that we explicitly add support for I do prefer to go with plan A. What do others think? quidame, would you be happy to commit to make bilibop-udev support the Tails usecase on the long term? (that is, Debian stable + live-build + live-boot, GPT, DVD or USB / sd-card, etc.) If it works as you expect and you plan to ship it with the next release of Tails, you should probably try to base some of your custom scripts on the bilibop shell library (just play with /lib/bilibop/disk and see). Tips: - if the symlink /dev/bilibop exists, it means the system is running from a writable media (USB, MMC and the like, but not DVD); - if you don't like 'bilibop' but prefer 'Tails' or 'bootdev', just set up BILIBOP_COMMON_BASENAME to the value of your choice in /etc/bilibop/bilibop.conf Nice goodies, thanks! This will be useful for the incremental updates feature too. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
Hi, On 13/05/2013 17:42, intrigeri wrote: Hi, quid...@poivron.org wrote (13 May 2013 00:57:02 GMT) : Could you try the new version (0.4.11~quidame), please ? Thanks a lot for your prompt response! I've tried it, and it works fine for me (and makes the boot device has safe access rights test pass), so I've merged our feature/bilibop branch into the experimental one. I'd like to fix this bug for 0.18.1 or 0.19. So, the question now is: do we want to use bilibop to fix this serious bug, or develop and maintain a in-house solution? A. bilibop pros: - already works in a way that I'd be happy to ship in our next stable release - we don't have tomaintain it: quidame does - it supports more hardware / boot media / installation modes than we'll ever do ourselves cons: - we (well, I) have to sponsor it in Debian - quite a lot of code for something that may look simple Maybe the last con is the price of the last pro... B. home-made solution pros: - less code cons: - the code is not finished (yet) - we have to maintain it ourselves - only supports the hardware / boot media / installation modes that we explicitly add support for I do prefer to go with plan A. What do others think? quidame, would you be happy to commit to make bilibop-udev support the Tails usecase on the long term? (that is, Debian stable + live-build + live-boot, GPT, DVD or USB / sd-card, etc.) Yeah, why not ? In itself, bilibop-udev is a poor thing, and is not intended to do anything when running from optical media; but if needed it can, of course, as long as bilibop-common has support for that; and really, this shell library doesn't care of GPT or MBR partition tables, DVD or USB boot media, and so on; it is written to find the physical boot device in a wide range of situations, that's all. After what, other bilibop packages perform more or less specific actions to protect the content of this device from root or user mistakes. bilibop-udev can protect the whole disk and its partitions from a basic user mistake when she plays with dd or shred. I don't plan to modify its core design. But improvements and options based on Tails specifications could be added. It is even possible to build a specific 'bilibop-live' package with best integration with live-build and live-boot, detection of the boot media type (optical, HDD, flash memory), etc. This would let bilibop-udev as minimal as possible (and usable on non-live systems running from external media). So, yes, I would be happy. I don't know what you mean when you say 'on the long term', but the first draft of the bilibop project was written five years ago, and I think I will use it in a daily basis for the rest of my life. Is it enough ?-) If it works as you expect and you plan to ship it with the next release of Tails, you should probably try to base some of your custom scripts on the bilibop shell library (just play with /lib/bilibop/disk and see). Tips: - if the symlink /dev/bilibop exists, it means the system is running from a writable media (USB, MMC and the like, but not DVD); - if you don't like 'bilibop' but prefer 'Tails' or 'bootdev', just set up BILIBOP_COMMON_BASENAME to the value of your choice in /etc/bilibop/bilibop.conf Nice goodies, thanks! This will be useful for the incremental updates feature too. Cheers, quidame signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
Hi, (No need to Cc me, I do read the list. Do you?) quidame wrote (13 May 2013 22:00:06 GMT) : On 13/05/2013 17:42, intrigeri wrote: quidame, would you be happy to commit to make bilibop-udev support the Tails usecase on the long term? (that is, Debian stable + live-build + live-boot, GPT, DVD or USB / sd-card, etc.) Yeah, why not ? [...] So, yes, I would be happy. I don't know what you mean when you say 'on the long term', but the first draft of the bilibop project was written five years ago, and I think I will use it in a daily basis for the rest of my life. Is it enough ?-) I'm convinced. It will take a collective decision before we go this way, though. Then, if we decide to go this way, I'm happy to sponsor the upload of bilibop to Debian. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
Hi, quidame wrote (13 May 2013 22:54:53 GMT) : (No need to Cc me, I do read the list. Do you?) No, I'm not subscribed. Maybe I should :) :) Please don't feel compelled to do so, I'm sure we can as well Cc' you when stuff in this area requires your attention. But well, if you feel like it, you're certainly most welcome! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
Hi quidame, quid...@poivron.org wrote (25 Mar 2013 12:00:11 GMT) : 2. Get bilibop-common and bilibop-udev packages: I've tried to build an ISO with bilibop-udev installed. Unfortunately, bilibop-udev.postinst fails for me because it seems to require /proc/mounts to be mounted: Setting up bilibop-udev (0.4.10~quidame) ... df: Warning: cannot read table of mounted file systems: No such file or directory grep: /proc/mounts: No such file or directory dpkg: error processing bilibop-udev (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: bilibop-udev ... which is not the case in the chroot that live-build uses to build our ISO. Given we don't care at all about the work that this postinst does (triggering udev rules on the current boot disk) in the context of Tails, what do you think could be a fine way to make this step be skipped or non-fatal in our usecase? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
Hi,
quid...@poivron.org 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
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
Hi,
Le 2013-05-12 18:19, intrigeri a écrit :
Hi,
quid...@poivron.org 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.
hmm... yes. Thanks for your detailed report. This postinst script is
not
absolutely irrelevant, as it works for Debian non-live systems
installed
on USB stick or external HDD. But you're right, it seems it is badly
implemented for other usecases. So I will rewrite it now. I think a new
version of the packages will be publicly available in some hours.
Cheers,
quidame
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
Hi, Le 2013-05-12 17:03, intrigeri a écrit : Hi quidame, quid...@poivron.org wrote (25 Mar 2013 12:00:11 GMT) : 2. Get bilibop-common and bilibop-udev packages: I've tried to build an ISO with bilibop-udev installed. Unfortunately, bilibop-udev.postinst fails for me because it seems to require /proc/mounts to be mounted: Setting up bilibop-udev (0.4.10~quidame) ... df: Warning: cannot read table of mounted file systems: No such file or directory grep: /proc/mounts: No such file or directory dpkg: error processing bilibop-udev (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: bilibop-udev ... which is not the case in the chroot that live-build uses to build our ISO. Given we don't care at all about the work that this postinst does (triggering udev rules on the current boot disk) in the context of Tails, what do you think could be a fine way to make this step be skipped or non-fatal in our usecase? I have added some basic checks to skip trigger uevents in the case the package is installed in a chrooted environment, or if udev daemon is not running (then the boot disk is even not searched). Could you try the new version (0.4.11~quidame), please ? If it works as you expect and you plan to ship it with the next release of Tails, you should probably try to base some of your custom scripts on the bilibop shell library (just play with /lib/bilibop/disk and see). Tips: - if the symlink /dev/bilibop exists, it means the system is running from a writable media (USB, MMC and the like, but not DVD); - if you don't like 'bilibop' but prefer 'Tails' or 'bootdev', just set up BILIBOP_COMMON_BASENAME to the value of your choice in /etc/bilibop/bilibop.conf Have a nice day quidame ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
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
___
tails-dev mailing list
Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
hi, anonym wrote (20 Mar 2013 14:16:31 GMT) : Re-opened ticket: https://tails.boum.org/bugs/writable_system_disk:_belongs_to_floppy_group/ FTR, in line with our current practice of not using the limited bugs/* anymore, I've closed that one again, and moved the relevant content to the ticket (todo/make_system_disk_read-only) that we already had, and that I reopened. Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
Hi, anonym wrote (20 Mar 2013 14:16:31 GMT) : Any way, the focus should be on getting the new fix to work. As I'm overcommitted with other obligations I won't have time to look into the exact workings of t-p-s vs udisks/sgdisk permissions vs group privileges etc. very soon to learn what exactly is going on. Please, maintainer of t-p-s, could you have a look? I hope the above clues make it clear enough. I'm working on removing the need for running sgdisk in t-p-s. If this works out well, then t-p-s will be doing all its disk management operations via udisks, and then it should not a be blocker anymore to set stricter permissions on the boot medium. I'll try to get this ready in time for the 0.17.2 freeze, so hopefully we can also have some version of bugfix/writable_boot_media merged in time too. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
Hi, 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! , | /usr/local/lib/tails-shell-library/boot.sh ` First, I'm very happy someone eventually tackles this. I expect this will be useful for other bits of code. However, I'm a bit confused, as it looks to me like this library is either duplicating, or re-implementing from scratch, some code that we have had in /usr/local/sbin/udev-watchdog-wrapper for a while... that takes into account corner cases such as fromiso. Perhaps they should be merged or something? +# Note dependency on working udev Well, this is not true of functions called by udev-boot-dev-helper, is it? If I'm correct, given we have in here functions that depend on udev working, and other functions that absolutely should not rely or udev nor call udevadm, I suggest they are split into two different files, to avoid confusion and programming mistakes. , | /etc/udev/rules.d/99-boot-dev-ownership.rules ` I'd rather see this file called 99-boot-dev-ownership.rules, for consistency with 91-permissions.rules, and also because at some point we might want to do other permissions trickery than ownership on these devices (ACL, Unix permissions, etc.), and I'd rather split the rules according to the high-level goal rather than according to the low-level tool being used to achieve it. +# Fix for Debian bug #645466. Minor nitpicking: referencing external sources is great for details lovers, but IMHO it should not replace telling the basics of what this file is supposed to do. Not a blocker, anyway. , | /usr/local/sbin/udev-boot-dev-helper ` s/an udev rule/a udev rule/ +# Turns out we cannot use function using `udevadm` in this library for +# this script since it's used in an udev rule; at that time the udev +# database isn't finished and any queries in it cannot be trusted. +. /usr/local/lib/tails-shell-library/boot.sh Then perhaps add a note, on top of every such library function that's being used, to make it clear it should *never* use udevadm? (If you don't go with the split into two files way.) +# XXX: This code is pretty crude thanks to not having udev to query +# for the parent device. In Wheezy with its newer blkid we'll be able +# to determine the parent device more reliably, if we care. Good news this can be improved later. Would you please move this note to todo/Wheezy (and perhaps point to there from a code comment if you wish)? It's been a while (if ever) that I've seen someone tackle a FIXME or XXX that's in our code. Let's not spread our TODO list to places nobody looks at :) grep -q ^/dev/sd[a-z]$ Single quotes would be safer here. Also, in such calls to grep, generally you want `-qs'. Same for the next one. To end with, once polished a bit, I think this should be tested (if not done yet): * on DVD * on a SD card with a USB controller Bonus points if this is tested too: * with fromiso (yeah, well, we don't support this officially) * on mmc_block SD cards whose name is along the lines of /dev/mmcblk0 (these are not supported yet by our installer etc.) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Help needed with branch bugfix/writable_boot_media
intrigeri wrote (23 Mar 2013 14:23:05 GMT) : I'm working on removing the need for running sgdisk in t-p-s. Done, see dedicated thread. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
