Fixes for switching to Jessie as base OS for test hosts

flash-kernel will run from various kernel postinst hooks and overwrite our own boot scripts. While this might be tollerable for the initial installation we don't want to risk it occuring after we have created our own boot.scr to boot xen.

The vmlinuz and initrd.img symlinks appear to have moved to /boot when installing Jessie on armhf systems compared to Wheezy.

root is not a "guest lv", so using target_guest_lv_name is misleading.

target_guest_lv_name also fails to properly handle the guest vg name correctly, which di_vg_name does.

Ian Campbell writes ("[PATCH OSSTEST 3/6] Debian: uboot: Use di_vg_name() and lv_dev_mapper() for root="):

Quoted 4 lines

root is not a "guest lv", so using target_guest_lv_name is misleading.

target_guest_lv_name also fails to properly handle the guest vg name correctly, which di_vg_name does.

WDYM `the guest vg name' ? If it's not a guest lv then is it a guest vg ?

Sorry if I am simply confused.

Quoted 4 lines

Ian Campbell writes ("[PATCH OSSTEST 3/6] Debian: uboot: Use di_vg_name() and lv_dev_mapper() for root="):

Quoted 2 lines

root is not a "guest lv", so using target_guest_lv_name is misleading.

Quoted 5 lines

Quoted 2 lines

target_guest_lv_name also fails to properly handle the guest vg name correctly, which di_vg_name does.

WDYM `the guest vg name' ? If it's not a guest lv then is it a guest vg ?

Sorry, I think I meant "the d-i vg name". Specifically the default VG name created by D-I changed in Jessie to append "-vg" to the hostname.

i.e. under Squeeze and Wheezy a machine foo would end up with /dev/foo/root while under Jessie it becomes /dev/foo-vg/root.

prepareguest has already assigned this so we should use it instead of replicating (perhaps wrongly since target_guest_lv_name and target_choose_vg can behave differently if multiple vgs are present).

prepareguest has already assigned this so we should use it instead of replicating (perhaps wrongly since target_guest_lv_name and target_choose_vg can behave differently if multiple vgs are present).

Signed-off-by Ian Campbell <[email protected]>

Cc Roger Pau Monné <[email protected]>

El 29/09/15 a les 11.44, Ian Campbell ha escrit:

Quoted 6 lines

prepareguest has already assigned this so we should use it instead of replicating (perhaps wrongly since target_guest_lv_name and target_choose_vg can behave differently if multiple vgs are present).

Signed-off-by Ian Campbell <[email protected]>

Cc Roger Pau Monné <[email protected]>

I'm not officially the maintainer of this, but for the record:

Acked-by Roger Pau Monné <[email protected]>

prepareguest has already assigned this so we should use it instead of replicating (perhaps wrongly since target_guest_lv_name and target_choose_vg can behave differently if multiple vgs are present).

Signed-off-by Ian Campbell <[email protected]>

Cc Roger Pau Monné <[email protected]>

---
 ts-freebsd-install | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

ts-freebsd-install +2 -3

index 98dad24..d1f4bd3 100755
@@ -49,7 +49,7 @@ sub prep () {
 
     target_put_guest_image($ho, $gho);
 
-    my $rootpartition_dev = target_guest_lv_name($ho, $gho->{Name}) . "-
-disk3";
+    my $root_part_nr = 3;
 
     target_cmd_root($ho, "umount $gho->{Lvdev} ||:");

@@ -64,7 +64,7 @@ sub prep () {
 
             kpartx -a $gho->{Lvdev}
             mkdir -p $mnt
-            mount -t ufs -o ufstype=ufs2,rw $rootpartition_dev $mnt
+            mount -t ufs -o ufstype=ufs2,rw $gho->{Lvdev}${root_part_nr}

$mnt
END

     target_cmd_root($ho, <<END, 15);

Quoted 3 lines · Ian Campbell

prepareguest has already assigned this so we should use it instead of replicating (perhaps wrongly since target_guest_lv_name and target_choose_vg can behave differently if multiple vgs are present).

This is wrong in practice because
kpartx -a /dev/some-vg/some-device
produces /dev/mapper/some--vg-some--device1 etc but not /dev/some-vg/some -device1.

The right fix probably involves lv_dev_mapper($gho-{Vg}, "$gho->{Lv}3") instead.

I'm in two minds about having guest_find_lv use lv_dev_mapper to populate $gho->{Lvdev} in the first place as an alternative fix though.

Quoted 32 lines

Signed-off-by Ian Campbell <[email protected]>

Cc Roger Pau Monné <[email protected]>

---
 ts-freebsd-install | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

ts-freebsd-install +0 -1

index 98dad24..d1f4bd3 100755
@@ -49,7 +49,7 @@ sub prep () {
 
     target_put_guest_image($ho, $gho);
 
-    my $rootpartition_dev = target_guest_lv_name($ho, $gho->{Name}) .

"-

ts-freebsd-install +2 -3

-disk3";
+    my $root_part_nr = 3;
 
     target_cmd_root($ho, "umount $gho->{Lvdev} ||:");

@@ -64,7 +64,7 @@ sub prep () {
 
             kpartx -a $gho->{Lvdev}
             mkdir -p $mnt
-            mount -t ufs -o ufstype=ufs2,rw $rootpartition_dev $mnt
+            mount -t ufs -o ufstype=ufs2,rw $gho
->{Lvdev}${root_part_nr}

$mnt
END

Quoted 1 line

     target_cmd_root($ho, <<END, 15);

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Quoted 3 lines · Ian Campbell

prepareguest has already assigned this so we should use it instead of replicating (perhaps wrongly since target_guest_lv_name and target_choose_vg can behave differently if multiple vgs are present).

This is wrong in practice because
kpartx -a /dev/some-vg/some-device
produces /dev/mapper/some--vg-some--device1 etc but not /dev/some-vg/some -device1.

The right fix probably involves lv_dev_mapper($gho-{Vg}, "$gho->{Lv}3") instead.

I'm in two minds about having guest_find_lv use lv_dev_mapper to populate $gho->{Lvdev} in the first place as an alternative fix though.

Quoted 2 lines

I'm in two minds about having guest_find_lv use lv_dev_mapper to populate $gho->{Lvdev} in the first place as an alternative fix though.

I decided I liked this route more. It's as yet untested other than "perl -c", but I have inserted the patch below before this one.

commit 9ba9a4f1d3fb7f01a1c76e9bff9f4b23187d855b

Author: Ian Campbell <[email protected]>
Date:   Fri Oct 2 10:31:13 2015 +0100

TestSupport: Use lv_dev_mapper in guest_find_lv

Signed-off-by Ian Campbell <[email protected]>

mg-debian-installer-update-all has been run on the production instance and TftpDiVersion is also updated to match.

The resulting binaries have also been copied to the Cambridge instance, so update Cambridge config too.

* Switch to apt-cacher-ng on the cache host, since a bug in Jessie's apt apparently interacts badly with apt-cacher's handling of Ranges in http requests[0]. I've deployed apt-cacher-ng on an alternative port on the production cache and tested that it works with Jessie and Wheezy.

From b9558e5202b6ade9dc91f0ebf5eac2ff94a57ba4 Mon Sep 17 00:00:00 2001

Quoted 4 lines

* Switch to apt-cacher-ng on the cache host, since a bug in Jessie's apt apparently interacts badly with apt-cacher's handling of Ranges in http requests[0]. I've deployed apt-cacher-ng on an alternative port on the production cache and tested that it works with Jessie and Wheezy.

I was assuming we'd want to switch out apt-cacher for apt-cacher-ng on port cache:3142. Instead you suggested just changing the config to use the alternative port 3143.

* Switch to apt-cacher-ng on the cache host, since a bug in Jessie's apt apparently interacts badly with apt-cacher's handling of Ranges in http requests[0]. I've deployed apt-cacher-ng on an alternative port on the production cache and tested that it works with Jessie and Wheezy.

* A firmware upgrade on the Arndale boards, since the new version of gcc seems to trigger an SoC errata when building the kernel.

The reason I care about upgrading to Jessie is that this adds the arm64 architecture which we hope to eventually have hardware for.