"Installing Tails to a pristine USB drive" often stalls with "Unmounting /dev/sda1" at 98%.
Still happens with 0.18~rc1, despite it has the commit fb3d08a5 from upstream liveusb-creator that we hoped would help.
#14 Updated by anonym over 4 years ago
- Assignee set to intrigeri
- QA Check set to Info Needed
Since I cannot reproduce this bug, could you try running
--pause-on-fail until the bug triggers, then take over the VM and make a tarball of
/var/log and all other debugging info you can think of and send it my way?
#26 Updated by intrigeri over 4 years ago
Reproduced, see attachment. Initial analysis: after copying and umounting, in
gui.py around line 260, we do:
if self.parent.opts.partition: self.rescan_devices() self.live.switch_back_to_full_drive() self.live.remove_hybrid_mbr()
self.live.detect_supported_drives, that itself defines
handle_reply and uses it as a callback. And then, in
handle_reply, this DBus call fails with the error message one can see on the screenshot:
data['parent'] = str(dbus.Interface(self._get_device(parent), 'org.freedesktop.DBus.Properties').Get(parent, 'DeviceFile'))
#27 Updated by intrigeri over 4 years ago
- Status changed from Confirmed to In Progress
- Target version changed from Tails_1.3.2 to Tails_1.3
- % Done changed from 0 to 10
- QA Check deleted (
- Feature Branch set to liveusb-creator:bugfix/6092-drop-racy-code
- Type of work changed from Research to Code
I have something that should hopefully fix it without breaking anything else. Let's see.
#29 Updated by intrigeri over 4 years ago
- % Done changed from 10 to 20
- Feature Branch changed from liveusb-creator:bugfix/6092-drop-racy-code to bugfix/6092-drop-racy-code
liveusb-creator .deb uploaded to bugfix-6092-drop-racy-code, merged into experimental. Now I'm going to run the test suite and see.
#32 Updated by alant over 4 years ago
- Assignee changed from alant to intrigeri
- QA Check changed from Ready for QA to Info Needed
I read the code, ticket and APT repository changes and I'm happy with them.
However, I wasn't able to reproduce the bug, so I only tested that this doesn't break the installer an obvious way. That part of the testsuite always fails for me.
Now I'm going to run the test suite and see.
I guess that marking the ticket as ready for QA means that the testsuite succeded for you? If it's the case, please feel free to merge.