Bug #11932
Tails Installer sometimes crashes in get_free_bytes() while installing the boot loader
0%
Description
This error does not prevent the ISO from being installed.
$ DEBUG=1 tails-installer-launcher
2016-11-16 15:45:07,781 [creator.py:1338 (get_extlinux_version)] WARNING: extlinux not found! Only FAT filesystems will be supported
2016-11-16 15:45:07,803 [creator.py:625 (detect_supported_drives)] WARNING: Skipping device '/org/freedesktop/UDisks2/block_devices/sda5' connected to '' interface
2016-11-16 15:45:07,804 [creator.py:625 (detect_supported_drives)] WARNING: Skipping device '/org/freedesktop/UDisks2/block_devices/sda' connected to '' interface
2016-11-16 15:45:07,804 [creator.py:625 (detect_supported_drives)] WARNING: Skipping device '/org/freedesktop/UDisks2/block_devices/sda2' connected to '' interface
2016-11-16 15:45:07,804 [creator.py:625 (detect_supported_drives)] WARNING: Skipping device '/org/freedesktop/UDisks2/block_devices/sda1' connected to '' interface
Could not guess underlying block device: Argument 1 does not allow None as a value
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/dist-packages/tails_installer/gui.py", line 141, in run
free = self.get_free_bytes()
File "/usr/lib/python2.7/dist-packages/tails_installer/creator.py", line 1068, in get_free_bytes
stat = os.statvfs(device)
OSError: [Errno 2] Datei oder Verzeichnis nicht gefunden: '/media/u/Tails'
I used tails-installer version 4.4.11.
Subtasks
History
#1 Updated by Anonymous 2016-11-16 15:20:37
Could not reproduce this a second time.
I used t-i on Debian Jessie.
#2 Updated by intrigeri 2016-11-16 15:59:51
- Category set to Installation
- Affected tool set to Installer
#3 Updated by Anonymous 2017-05-31 10:01:35
- Assignee set to anonym
Reassigning to the foundations team, please see what you want to do about that.
#4 Updated by intrigeri 2017-05-31 10:47:30
- Assignee deleted (
anonym) - QA Check set to Info Needed
u wrote:
> Reassigning to the foundations team, please see what you want to do about that.
I don’t think we can do anything about it without a complete debug log (the one on this ticket was apparently stripped and lots of info needed to understand the problem isn’t there). Since then you said you could not reproduce though. If that’s still the case, let’s close this ticket and reopen it once it can be made actionable. Fair enough?
#6 Updated by krogrumpkin 2017-11-25 21:48:51
I’ve just reproduced a very similar-look tails-installer bug on Mate 18.2. Copypasta from the xterm follows (deleted hostname in prompt):
$ tails-installer
2017-11-25 12:59:49,782 [creator.py:636 (detect_supported_drives)] WARNING: Skipping device '/org/freedesktop/UDisks2/block_devices/sr0' connected to '' interface
2017-11-25 12:59:49,782 [creator.py:636 (detect_supported_drives)] WARNING: Skipping device '/org/freedesktop/UDisks2/block_devices/sda' connected to '' interface
2017-11-25 12:59:49,803 [creator.py:636 (detect_supported_drives)] WARNING: Skipping device '/org/freedesktop/UDisks2/block_devices/sda1' connected to '' interface
/usr/lib/python2.7/dist-packages/tails_installer/gui.py:664: Warning: g_hash_table_contains: assertion 'hash_table != NULL' failed
reply = dialog.run()
/usr/bin/tails-installer:95: Warning: g_hash_table_contains: assertion 'hash_table != NULL' failed
Gtk.main()
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/dist-packages/tails_installer/gui.py", line 141, in run
free = self.get_free_bytes()
File "/usr/lib/python2.7/dist-packages/tails_installer/creator.py", line 1068, in get_free_bytes
stat = os.statvfs(device)
OSError: [Errno 2] No such file or directory: '/media/XXXXXX/Tails'
As this occurred, a password dialog popped up asking for my password to umount and mount the target stick. AFAICT, the installation succeeded, but I haven’t had a chance to test it yet. Grabbed the syslog, which has some noise from udisksd
and the kernel about this as well. I’ll add that after trying the boot.
#7 Updated by krogrumpkin 2017-11-26 01:17:48
The media produced after the error in https://labs.riseup.net/code/issues/11932#note-6 booted without incident.
#8 Updated by Anonymous 2017-11-27 13:13:57
thanks for the report. I think as the media produced works fine, let’s not bother for now.
#9 Updated by intrigeri 2017-12-24 09:35:48
- Subject changed from tails-installer throws error at end of installation in get_free_bytes() to Tails Installer sometimes crashes in get_free_bytes() while installing the boot loader
- Status changed from Rejected to Confirmed
- Assignee set to kurono
- Priority changed from Low to Normal
- QA Check deleted (
Info Needed)
I was concerned that a crash happening before the end of the installation could possibly produce a Tails device in a weird/mixed or broken state, so I’ve had a closer look.
In the run
method of TailsInstallerThread
we:
- start the progress thread: every 3 seconds it’ll run
get_free_bytes()
; on this bug we see that occasionally, one of these method calls fails because the target system partition has been unmounted already - copy the OS data to the target system partition
- run
self.live.install_bootloader()
which, among other things, unmounts the target system partition - stop the progress thread
That’s clearly racy: nothing prevents the target system partition from being unmounted before at least one call to get_free_bytes()
. I’m not surprised this occasionally happens.
Potential impact when this happens: self.live.install_bootloader()
can be aborted before it completes its work; Tails Installer may be aborted without running the code that comes after install_bootloader()
, e.g. self.live.reset_mbr()
. So the target device can be entirely unbootable in BIOS legacy mode, or be left with bits of syslinux in conflicting versions (between what’s in the FAT filesystem and what’s in the MBR) which can lead to boot failures in the best case, and unspecified behaviour in the worst case.
This sounds bad enough to be worth fixing.
For example we could freeze the progress bar after we finish copying the OS data and before we unmount the target system partition (at that point the progress bar has reached 100% already so it makes no sense to keep updating it), e.g. something like this untested patch:
--- a/tails_installer/gui.py
+++ b/tails_installer/gui.py
@@ -234,6 +234,8 @@ class TailsInstallerThread(threading.Thread):
self.live.create_persistent_overlay()
self.live.update_configs()
+ self.progress.stop()
+
self.live.install_bootloader()
# self.live.bootable_partition()
@@ -242,8 +244,6 @@ class TailsInstallerThread(threading.Thread):
if self.parent.opts.liveos_checksum:
self.live.calculate_liveos_checksum()
- self.progress.stop()
-
# Flush all filesystem buffers and unmount
self.live.flush_buffers()
self.live.unmount_device()
kurono, wanna give it a try?
#10 Updated by kurono 2018-01-15 18:21:19
- Target version set to Tails_3.8
#11 Updated by intrigeri 2018-06-26 16:27:54
- Target version changed from Tails_3.8 to Tails_3.9
#12 Updated by kurono 2018-07-13 15:58:59
- Assignee deleted (
kurono) - Target version deleted (
Tails_3.9)