Tails

#2 Updated by intrigeri 2018-10-16 16:00:40

segfault wrote:
> I assume that my libvirt uses legacy BIOS

It does by default. One easy way to tell is whether you see the syslinux background picture, which is only there in legacy BIOS mode and not in UEFI mode that has some kind of light gray background.

#3 Updated by segfault 2018-10-16 17:36:10

intrigeri wrote:
> segfault wrote:
> > I assume that my libvirt uses legacy BIOS
>
> It does by default. One easy way to tell is whether you see the syslinux background picture, which is only there in legacy BIOS mode and not in UEFI mode that has some kind of light gray background.

Ah, right. I don’t have the light gray background, so it’s legacy BIOS.

#4 Updated by segfault 2018-10-17 16:28:07

Successfully tested:

• USB Image with UEFI
• USB Image after first boot on {UEFI, Legacy BIOS}

#5 Updated by segfault 2018-10-24 10:12:26

Successfully tested with an image built from commit 76efb36745 (which should be identical to the most recent commit, ca786bc411, which I created by resetting to devel and cherry-picking my commits from 76efb36745):

• USB Image with {UEFI, legacy BIOS}
• USB Image after first boot on {UEFI, legacy BIOS}

#10 Updated by Anonymous 2018-12-17 14:40:03

> * ISO on DVD with Legacy BIOS (libvirt): Boots, but waits for the system partition to become available until the timeout (1 minute), because $FSUUID is unset. It should instead skip the partitioning immediately. I implemented a fix on Feature #15319.

Did you rested this with the fix applied?

> * ISO on USB with Legacy BIOS (libvirt): Same as above

Same question as above.

#11 Updated by Anonymous 2018-12-17 14:41:35

segfault wrote:
> Successfully tested with an image built from commit 76efb36745 (which should be identical to the most recent commit, ca786bc411, which I created by resetting to devel and cherry-picking my commits from 76efb36745):
>
> * USB Image with {UEFI, legacy BIOS}
> * USB Image after first boot on {UEFI, legacy BIOS}

Should this be retested with the current state of the image?

If not, it seems that if you can provide the DVD test results as requested in my previous comment, this ticket might be closed, yay!

#12 Updated by intrigeri 2018-12-17 16:25:56

> Should this be retested with the current state of the image?

Given the amount of changes since the last round of tests, I think so.
I would also explicitly block on Bug #15985 which will invalidate testing again.

#13 Updated by Anonymous 2018-12-27 09:50:44

Ok! @segfault: could you please run the tests again and report on success? Thanks!

#15 Updated by segfault 2018-12-28 16:53:07

I won’t be able to redo the tests in the next days.

#16 Updated by intrigeri 2019-01-02 06:23:30

> I won’t be able to redo the tests in the next days.

In the hope it’ll make our work here easier, as said on Feature #16199#note-20, today I’ll prepare a shorter lists of manual tests we need to do before we publish the beta. Once that’s done, hopefully someone can do the manual tests so we can release a beta ASAP. segfault, it would be super helpful if you could give us your ETA for this, so we know whether someone else needs to take this over and make time for it :)

#18 Updated by intrigeri 2019-01-02 11:35:34

intrigeri wrote:
> Flagged tests that are already exercised on test/16003-growing-system-partition. Triggered build+tests, will report results here.

Test suite passes so indeed, we can skip the tests I’ve struck through.

#19 Updated by Anonymous 2019-01-02 16:14:47

intrigeri wrote:
> > I won’t be able to redo the tests in the next days.
>
> In the hope it’ll make our work here easier, as said on Feature #16199#note-20, today I’ll prepare a shorter lists of manual tests we need to do before we publish the beta. Once that’s done, hopefully someone can do the manual tests so we can release a beta ASAP. segfault, it would be super helpful if you could give us your ETA for this, so we know whether someone else needs to take this over and make time for it :)

Thank you for creating this list.

It looks like segfault says he’s not available for testing. I’m not available today, but I’d be happy to talk about what to test tomorrow over XMPP, which will make my life easier than ping pong on Redmine :)

#20 Updated by intrigeri 2019-01-02 17:42:15

> I’d be happy to talk about what to test tomorrow over XMPP, which will make my life easier than ping pong on Redmine :)

I won’t be available much tomorrow (nor until the 8th, inclusive) but let’s try!

#21 Updated by Anonymous 2019-01-03 16:20:24

segfault and me will do some testing tomorrow morning.

#22 Updated by Anonymous 2019-01-04 11:35:10

Trying to boot the live IMG in virt-manager, not adding any default options it is impossible to boot:

- device pretends that my device is too small too boot Tails.

The ISO image boots fine with the same settings.

#23 Updated by Anonymous 2019-01-04 11:36:23

@segfault: can you please look into this and test the other options as outlined in the description of this ticket? Thanks!

#24 Updated by intrigeri 2019-01-04 13:08:07

u wrote:
> Trying to boot the live IMG in virt-manager, not adding any default options it is impossible to boot:
>
> - device pretends that my device is too small too boot Tails.

If you passed the downloaded IMG file as-is to libvirt, that’s equivalent to giving libvirt a USB stick that’s exactly the size of that IMG file, which is indeed too small. You need to grow that file (e.g. with truncate) first to 8+GB.

Also, note that you need to make that virtual USB stick “removable” in virt-manager.

#25 Updated by Anonymous 2019-01-04 14:12:34

intrigeri wrote:
> u wrote:
> > Trying to boot the live IMG in virt-manager, not adding any default options it is impossible to boot:
> >
> > - device pretends that my device is too small too boot Tails.
>
> If you passed the downloaded IMG file as-is to libvirt, that’s equivalent to giving libvirt a USB stick that’s exactly the size of that IMG file, which is indeed too small. You need to grow that file (e.g. with truncate) first to 8+GB.

Urgh.

> Also, note that you need to make that virtual USB stick “removable” in virt-manager.

#26 Updated by Anonymous 2019-01-04 14:13:59

USB Image on USB with UEFI

I’ve tested the latest.img booting on a Mac Mini with EFI (bare metal that is): booting works but again, initramfs tells me that it cannot find a medium containing a live system. I’ve used a 16GB big TOSHIBA USB stick.
Also the boot took a long time.

#27 Updated by Anonymous 2019-01-04 14:46:33

USB image on legacy boot:

tested on my laptop: I see the Grub menu and then the boot is stuck. Error message too fast to read: something about the kernel.

ISO on legacy:

worked fine

So until now no success whatsoever in booting the USB image.

#28 Updated by Anonymous 2019-01-04 14:48:43

FYI i’ve used images from this build: https://nightly.tails.boum.org/build_Tails_ISO_feature-15292-usb-image/

#29 Updated by intrigeri 2019-01-04 14:49:43

u wrote:
> USB Image on USB with UEFI
>
> I’ve tested the latest.img booting on a Mac Mini with EFI (bare metal that is): booting works but again, initramfs tells me that it cannot find a medium containing a live system. I’ve used a 16GB big TOSHIBA USB stick.

Can you start Tails 3.x, installed with Tails Installer, from that exact same USB stick on the same computer?

#30 Updated by Anonymous 2019-01-04 15:04:43

I finally managed to boot using USB on legacy bare metal and this image: //nightly.tails.boum.org/build_Tails_ISO_feature-15292-usb-image/lastSuccessful/archive/latest.img

Also works on USB EFI on mac! (But bluetooth being disabled I cannot use my keyboard.)

It’s unclear to me why the previously installed image did not boot.

The working image is tails-amd64-feature_15292-usb-image-3.12-20190103T1349Z-30967bfff6+devel@d93cb9e609.img

#31 Updated by Anonymous 2019-01-04 15:05:17

So all tests seem to pass, except for the one i cannot make:
ISO on DVD with UEFI.