hi,
alan@??? wrote (21 Mar 2012 16:47:27 GMT) :
> Using an USB stick containing an isohybrid created with
> "isohybrid --entry 4 --type 0x1c" and copied with "cat".
Thanks for this report!
> 1) Booting with live-amd64 in french and try to install Tails.
> Select "Programme d'installation de Tails" from "Tails" menu.
> 3rd boutton label is cut, unclear and doesn't start with a captial
> letter: "à jour depuis une ima"
Known issue, fixed in Git since then.
> After selecting "Cloner & installer" and selecting the boot device,
> a warning is displayed it the log window:
[...]
> I find it unclear that the programm is waiting for an answer.
Yeah, you already reported that, and I tend to agree, but...
every other tester I've thrown liveusb-creator at without any
explanation at all had no problem with this, and clicked forward as
many times as necessary, more or less reading the warnings in the
meantime depending on their technical level.
> I think it should either display a dialog or change the look of the
> "log" window to something with bigger text and a "question" icon.
Given the successful real-world UX testing reported above,
and given we want to drop that GUI entirely at some point,
I'm not in favour of doing any such kind of rework of the
liveusb-creator GUI right now.
If anyone else disagrees,
and thinks it would be a great use of their time,
patches (that don't break other stuff) are welcome.
> When I click on "Suivant" the program closes:
> [creator:1160] extlinux not found! Only FAT filesystems will be supported
> *** glibc detected *** /usr/bin/python: malloc(): memory corruption:
> 0x0951d720 ***
> ======= Backtrace: =========
> /lib/libc.so.6(+0x6b19a)[0xf746219a]
> /lib/libc.so.6(+0x6dfb7)[0xf7464fb7]
> /lib/libc.so.6(__libc_malloc+0x5c)[0xf7466bfc]
> vie/usr/bin/python(PyString_FromStringAndSize+0x9c)[0x809da2c]
> I think this issue is related with booting with amd64 kernel.
Ouch.
Looks very much like the issues I myself experienced on a Debian
testing/sid amd64 system. I thought the problem was due to
testing/sid, but your report makes me reconsider: maybe there's
a serious Qt and/or pyqt and/or d-bus and/or udisks bug somewhere,
that's acting against us both on Squeeze and current testing/sid.
Added to the todo list. Will need to investigate that one seriously.
> 2) Booting with live (i386) in english and try to install Tails.
> Select "Tails", "Clone & install", "Next":
> Unmounting /dev/sdc
> Formatting /dev/sdc1 as FAT32
> Verifying filesystem...
> Setting /dev/sdc1 label to Tails
> Extracting live image to USB device...
> LiveUSB creation failed!
> Find log of this reproduced with the -v option below [1]
> Clicking "Next" anyway.
> The resulting USB stick has the wiki on Tails partition (or part of
> it)
> Traceback (most recent call last):
> File "/usr/lib/python2.6/dist-packages/liveusb/gui.py", line 557, in status
> self.textEdit.append(text)
> TypeError: QTextEdit.append(QString): argument 1 has unexpected type 'list'
> [gui:282]
> [('/live/image/doc/amnesia/wiki/bugs/http:__47____47__dl.amnesia.boum.org__47__tails__47__stable__47___is_empty._No_way_to_download_through_HTTPS.html',
/live/image/doc/ should *not* exist on your image: we've stopped
shipping the docs in the ISO filesystem for a while, for the very
reason to avoid that class of bugs.
Therefore, it looks like your build environment is somewhat tainted by
leftovers. Please clean it up and retry. Also, please take any action
needed to avoid this from happening again in the future: such bugs are
a pain to debug.
> 5) Persistence setup
[...]
> However, when launching the persistent storage configuration a 2nd
> time, the window is smaller, and the nice UI to select which file to
> keep is less usable. It woul be better to have the window the same
> size ad the 1st time.
Yeah, already in the post-0.11 todo list.
That window is resizable, and its content should be resized
accordingly, though.
> 6) Activate persistence
[...]
> UI note: I think that using in Tails-greeter the same type of
> buttons than the one used by the program to configure which bits are
> persistent would be better than the current set of Yes/No
> toggle buttons.
Do you mean e.g. one big button that would read "Enable persistence"
when toggled off, and "Disable persistence" when toggled on?
During the initial GUI brainstorming and experiments we did with
tchou, we tried that, and the current state was only expressed by
1. the current "toggled" state, which is not enough in itself to be
really clear; 2. in negative, by the action text; in the end, it was
much less clear to understand than the current (a bit heavyweight,
I concede) UI. That's why we settled upon the current UI.
Search "switch"
http://dribbble.com/ and you'll see many ideas I would
find much better than what we currently have. Problem is: a custom gtk
widget must be developed. Could be fun :)
> 7) Reboot and activete persistence RO
> Reboot on amd64 kernel, activate the persistence read-only.
> I do *not* see my GnuPG key.
> 9) Reboot and activete persistence RO
> Same as 7 in Live 686-pae kernel, same results
Additional info gathered on IRC: ~/.gnupg/secring.gpg is 0 bytes.
I can reproduce this bug. That's obviously a release blocker.
Then kernel log tells me that happened to the persistent filesystem:
EXT3-fs (dm-0): recovery required on readonly filesystem
EXT3-fs (dm-0): write access will be enabled during recovery
kjournald starting. Commit interval 5 seconds
EXT3-fs (dm-0): recovery complete
EXT3-fs (dm-0): mounted filesystem with ordered data mode
anonym, any idea?
Could it be that the two seconds between the first and the last lines
of this log explain why aufs has an obsolete view of the filesystem?
Added this bug, with others, to the "backend" section of the
persistence todo list:
https://tails.boum.org/todo/persistence/#index8h3
> I see my files in Persistent and *I can edit them*, which
> is confusing.
OK. I think our documentation team should document this.
I've asked them to.
> I find a bit confusing to have an drive icon labeled ".gnupg" on the
> desktop. I also have a drive icon labeled "Persistent".
Agreed, added to the TODO. There is probably some way to tell GNOME to
ignore this kind of mounts, or to do these aufs mounts in a way they
would be disregarded by GNOME. Any idea, anyone?
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| The impossible just takes a bit longer.
