Hi,
anonym wrote (09 Mar 2012 14:41:04 GMT) :
> 1. Boot a fresh Tails USB install.
> 2. Don't set sudo password.
> 3. Start tails-persistence-setup, set a passphrase and press create.
> 4. Error!
> 5. Reboot.
> 6. Set a sudo password.
> 7. Start tails-persistence-setup, enter password, press create.
> 8. Success!
> I haven't been able to reproduce step 4.
I admit I don't understand what could be inhibiting the UDisks daemon
at this time.
I think you've hit yet another USB stick that's gotten very weird
after playing with isohybrid / GPT / etc. ; this class of problems
should be dealt with by liveusb-creator 3.11.4-8.
The UDisks Inhibit() method documentation tends to indicate some kind
of credential thing might be playing tricks, though. I'll look
a bit deeper.
> I have found another (weird)
> way to kinda reliably reproduce it the error, though:
> 1. Boot a fresh Tails USB install.
> 2. Run tails-persistence-setup, set a password and press create. It
> should work.
> 3. Reboot.
> 4. Set a sudo password (needed by GParted below).
> 5. Use GParted: Remove the TailsData partition, format empty space as
> "unallocated" with no label. Apply the changes.
> 6. Use GParted: Delete the new partition. Apply the changes.
> 7. Run tails-persistence-setup, set a passphrase and press create.
> 8. Error!
I've no experience with mixing both, but I would be surprised if
GParted did play well with UDisks.
In that case, my rough guess would be that UDisks detected things were
being changed under it, and inhibited itself for some time.
> After doing the above steps cloning doesn't work either. Here's the log:
> Warning! All data [...]
> Press 'Next' [...]
> Unmounting /dev/sdc
> Daemon is inhibited
> LiveUSB creation failed!
> Daemon is inhibited
This tends to confirm GParted does things in a way that breaks UDisks.
> Even though the above steps certainly isn't something we want to
> support I hope it all can help you identify the original source of
> the error. (As a side effect it seems like the above steps (1-8)
> make Tails on the USB drive unbootable.)
"Missing OS", right?
I would not be surprised if GParted played badly with the GPT
attributes. E.g. to display the attributes of /dev/sdc1, run:
$ sgdisk /dev/sdc --attributes=1:show
Thank you for testing things again!
>> Given these disadvantages, and the limited benefit (better supporting
>> 2 GB media), I'm not in favour of adding such widgets at all.
> I just fear that we're setting the requirements for Tails too high,
> effectively alienating poor people, and unnecessarily preventing
> fully adequate devices from being usable with Tails.
I hear this fear, I agree this would be a shame to do what you fear,
and I don't think anyone is proposing to do any such thing.
I want to point out this part of the discussion started from your
initial report that installing Tails with liveusb-creator onto a 1.88
GiB stick would leave "only 424 MiB for TailsData". In my
understanding, this may be considered as wasting space, but seriously,
this does not prevent the stick from being usable with Tails.
Please remember that our current, pre-USB-installer, instructions to
install Tails on this very same USB stick would leave no room at all
for persistence; this has been true since the beginning of Tails.
What is currently being proposed for Tails 0.11 is *way better* for
2GB USB stick owners than anything we have shipped until now.
So I say let's release this, and if we want to discuss further
possible improvements, let's please make it clear we're discussing
further possible improvements (that can surely wait for after 0.11),
and not "alienating vs. not-alienating".
As currently implemented, liveusb-creator is worse for 1GB USB sticks,
though; however, not only we know we'll break the 1GB limit not that
far away from now, but the old isohybrid "cat>" install way will still
work in the meantime, so 1GB USB stick still can be used (without
persistence) for a while.
>> And anyway, I don't think anyone wants to add any additional
>> feature to our liveusb-creator codebase; remember we want to rebase
>> our work on top of another codebase at some point.
> IMHO, if this is an issue for us when adding a feature we want, then
> we may want to reconsider our whole approach, possibly by
> maintaining a fork (gasp! :)).
I think you're either missing some information, or you misunderstood
what I meant with "we want to rebase our work on top of another
codebase at some point". Let me clarify.
We have been "maintaining" a fork of the liveusb-creator codebase
since July 2011. Nobody, among this "we", wants to go further on
this road.
Quoting
https://tails.boum.org/todo/usb_install_and_upgrade/#index3h1,
the current plan is to:
1. release something useful based on the work we've already done on
the basis of Fedora liveusb-creator
2. probably start (again...) from Ubuntu's usb-creator, that has
a much saner codebase;
So, adding features to our current liveusb-creator codebase is:
1. a pain to do
2. half-wasted work that will need to be half-redone
I hope it helped clarify things :)
> Here's some more, unrelated suggestions:
> * In the liveusb-creator, please add the name of the USB drives'
> models to the list of USB devices one can install Tails to.
> tails-persistence-setup currently lists the name, but IMHO it's
> more important for the installer to do so since that's were the
> real risk of selecting the wrong device is.
Much agreed, this is in the TODO already:
https://tails.boum.org/todo/usb_install_and_upgrade/todo/
I don't plan to implement this in time for 0.11, though:
liveusb-creator currently only lists USB devices, and excludes both
the running one and the source one (IIRC) from the list, so the risk
of selecting the wrong device is quite limited, with the added
size information.
> * When persistence has been successfully setup, prompt the user with
> an OK-pop-up containing the success message (and OK -> exit
> application) instead of changing the window to contain the success
> message and asking users to close it themselves. That seems more
> streamlined to me.
GNOME GUI's currently evolve towards using much less modal dialog
windows, and I think it's a really good move (no idea about what other
environments do). Keeping one's attention focused on the same single
window all along a wizard-like process seems easier to me than finding
the last window that popped-up in front of my other windows.
Maybe I should add that the whole tails-persistence-setup "setup
wizard" aspect will be clearer once the "configure which bits are
persistence" step is fully implemented and follows the "bootstrap"
one, in the same way, in the same window. So I'd like to postpone
discussing this further until you've seen the whole thing, OK?
> Otherwise, at least add a close/exit button.
GNOME GUI's currently evolve towards removing close / quit buttons, on
the basis that it's a duplicate of the one provided by the window
manager, and an entirely useless one as long as the application
gracefully supports being closed this way. I buy these arguments,
I like less cluttered GUI's, that's why this step has no
close/exit button.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Then we'll come from the shadows.
