Bug #10504
boot_device method in features/step_definitions/usb.rb is broken
100%
Description
It happens to see this kind of failures in Jenkins:
features/usb_install.feature:2
Error trace:
We are running from device /dev/sda, but for usb drive 'isohybrid' we expected to run from either device /dev/sda1 (when installed via the USB installer) or /dev/sda1 (when installed from an isohybrid).
It seems to happen when isohybrids are used. If so config/chroot_local_includes/lib/live/config/998-permissions may also be broken. It reappeared on some new builds.
Subtasks
Related issues
Related to Tails - |
Resolved | 2016-02-05 | 2016-03-05 |
History
#1 Updated by bertagaz 2015-11-18 05:57:13
- Status changed from Confirmed to In Progress
- Assignee changed from bertagaz to anonym
- % Done changed from 0 to 10
I think this ticket was assigned to me because I had to collect more data about this bug. Here are some.
It happened 5 times in the Jenkins know history (so since last release mostly), in:
https://jenkins.tails.boum.org/view/Tails_ISO_tests/job/test_Tails_ISO_devel/14/console
https://jenkins.tails.boum.org/view/Tails_ISO_tests/job/test_Tails_ISO_feature-5926-freezable-apt-repository/12/console
https://jenkins.tails.boum.org/view/Tails_ISO_tests/job/test_Tails_ISO_feature-8577-tor-messenger/3/console
https://jenkins.tails.boum.org/view/Tails_ISO_tests/job/test_Tails_ISO_feature-jessie/26/console
https://jenkins.tails.boum.org/view/Tails_ISO_tests/job/test_Tails_ISO_testing/30/console
So it does not seems there’s a clear pattern here, but maybe the debug files for this test jobs will give more insight?
Assigning to anonym to lead/dispatch the rest of the research.
#2 Updated by intrigeri 2015-12-05 14:05:11
- Target version changed from Tails_1.8 to Tails_2.0
#3 Updated by intrigeri 2016-01-04 13:23:12
- Deliverable for set to 270
#4 Updated by intrigeri 2016-01-06 13:56:47
- Target version changed from Tails_2.0 to Tails_2.2
#5 Updated by anonym 2016-01-06 14:09:03
- Target version changed from Tails_2.2 to Tails_2.0
#6 Updated by anonym 2016-01-24 11:40:37
- Assignee changed from anonym to bertagaz
- QA Check set to Info Needed
I have done extensive local testing without being able to reproduce this. And unfortunately the Jenkins runs linked to in Bug #10504#note-1 are not available still. And after having a look at what’s currently available I failed to find this particular error.
Have you seen any more of it, bert?
#7 Updated by bertagaz 2016-01-27 10:49:47
- Target version changed from Tails_2.0 to Tails_2.2
#8 Updated by intrigeri 2016-02-05 14:41:55
I’ve not seen it recently.
#9 Updated by anonym 2016-02-20 13:10:07
- related to
Bug #11083: Deal with February 2016 false positive scenarios added
#10 Updated by anonym 2016-02-20 13:11:15
bert, can you look into this while doing your False Positives shift (Bug #11083)?
#11 Updated by anonym 2016-02-20 13:11:40
- Priority changed from Normal to Elevated
#12 Updated by bertagaz 2016-03-10 18:51:06
- Target version changed from Tails_2.2 to Tails_2.3
#13 Updated by bertagaz 2016-04-15 08:04:39
- Target version changed from Tails_2.3 to Tails_2.4
#14 Updated by intrigeri 2016-04-29 02:18:56
- Assignee changed from bertagaz to anonym
I’ve just seen it locally: “We are running from device /dev/sda, but for usb drive ‘isohybrid’ we expected to run from either device /dev/sda1 (when installed via the USB installer) or /dev/sda4 (when installed from an isohybrid).” What info do you need next time I see it happen? Any debugging output we should add to the test suite code to help understand what’s happening?
#15 Updated by anonym 2016-05-08 03:59:26
- Assignee changed from anonym to intrigeri
intrigeri wrote:
> I’ve just seen it locally: “We are running from device /dev/sda, but for usb drive ‘isohybrid’ we expected to run from either device /dev/sda1 (when installed via the USB installer) or /dev/sda4 (when installed from an isohybrid).” What info do you need next time I see it happen? Any debugging output we should add to the test suite code to help understand what’s happening?
I propose we don’t waste time on this and simply allow isohybrids to run from either /dev/sda or /dev/sda4? That is still distinct from /dev/sda1 for non-isohybrids, which I guess is ok.
#16 Updated by intrigeri 2016-05-09 01:45:20
- Assignee changed from intrigeri to anonym
- QA Check deleted (
Info Needed)
Agreed! I like how you manage to be pragmatic in some situations when I would tend to waste our time :)
#17 Updated by anonym 2016-06-08 01:35:00
- Target version changed from Tails_2.4 to Tails_2.5
#18 Updated by anonym 2016-06-16 08:06:15
- Feature Branch set to test/10504-allow-more-boot_devices
anonym wrote:
> I propose we don’t waste time on this and simply allow isohybrids to run from either /dev/sda or /dev/sda4? That is still distinct from /dev/sda1 for non-isohybrids, which I guess is ok.
Implemented in the feature branch.
The @fragile
tags added due to Bug #10720 prevents Jenkins from actually testing this fix, so I’ve merged bugfix/10720-installer-freezes-on-jenkins
into the feature branch, which removes those tags (and adds another vcpu? ok…). Let’s see what Jenkins thinks.
From the description:
> […] config/chroot_local_includes/lib/live/config/998-permissions may also be broken.
Indeed. Looking at the code, I wonder what will happen if we have an isohybrid that thinks it is booting from /dev/sda
and not /dev/sda4
. We will try to fix the ownership of the “parent” device of /dev/sda
, which I have no idea what our code will result in. Also, if there is a /dev/sda4
in this case, its ownership will not be changed, so it would have bad ownership, supposedly.
However, looking at the Git history, this workaround was added in 2012, when the Debian bug was still open, but it was fixed in 2014 in systemd 204-9, so we have the fix. From Debian’s changelog:
* Drop our Debian specific 60-persistent-storage{,-tape}.rules and use the
upstream rules. They are compatible and do a superset of the
functionality. (Closes: #645466)
I tested it by booting Tails 2.4 from USB with “break=bottom” on the kernel cmdline, and at the breakpoint I removed the workaround from the live-config hook, and then proceeded the boot. Ownership was still good! So I guess we can remove this workaround => Feature #11534.
PS. Now the script containing the workaround is called: config/chroot_local-includes/lib/live/config/9980-permissions
#19 Updated by intrigeri 2016-07-09 06:21:38
anonym, is this ready for QA? I could not understand what’s left to do here.
#20 Updated by anonym 2016-07-18 06:44:55
- Target version changed from Tails_2.5 to Tails_2.6
#21 Updated by intrigeri 2016-07-18 06:47:35
- Deliverable for changed from 270 to SponsorS_Internal
#22 Updated by intrigeri 2016-07-22 02:14:56
- Assignee changed from anonym to intrigeri
Code review passes. I’m running lots of tests on bugfix/10720-installer-freezes-on-jenkins these days, and have just seen this bug there, so I’ve merged test/10504-allow-more-boot_devices into that branch, in order to get more (and up-to-date) results.
#23 Updated by intrigeri 2016-07-29 06:40:18
- Status changed from In Progress to Fix committed
- Assignee deleted (
intrigeri) - Target version changed from Tails_2.6 to Tails_2.5
- % Done changed from 10 to 100
- QA Check set to Pass
- Deliverable for changed from SponsorS_Internal to 270
#24 Updated by intrigeri 2016-08-02 09:29:48
- Status changed from Fix committed to Resolved