Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Jun 2015 15:41:43 +1000
From:      Paul Koch <paul.koch@akips.com>
To:        freebsd-stable@freebsd.org
Subject:   bootonce not set in backup partition table - virtualbox guest with SAS controller
Message-ID:  <20150622154143.21c68162@akips.com>

next in thread | raw e-mail | index | archive | help

We seem to have a problem where after setting bootonce on an alternate root
partition, the backup partition table does not match the primary after 
rebooting onto an alternate root.

Setup:
- 10.1-RELEASE-p12 host
- VirtualBox 4.3.28
- 10.1-RELEASE-p12 guest, SAS controller with 50G fixed sized disk.

This problem does not happen when we setup the guest with a 50G fixed disk
off a SATA controller.


We have an custom install setup where we create two 5G root partitions,
/ and /alt.  This allows us to install a new OS+packages onto the alt,
set bootonce and reboot using /alt.


After our initial install we have:

# diskinfo -v da0
da0
        512             # sectorsize
        53687091200     # mediasize in bytes (50G)
        104857600       # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        6527            # Cylinders according to firmware.
        255             # Heads according to firmware.
        63              # Sectors according to firmware.
                        # Disk ident.

# gpart show
=>       34  104857533  da0  GPT  (50G)
         34          6       - free -  (3.0K)
         40       1024    1  freebsd-boot  (512K)
       1064    8388608    2  freebsd-swap  (4.0G)
    8389672        984       - free -  (492K)
    8390656   10485760    3  freebsd-ufs  [bootme]  (5.0G)
   18876416   10485760    4  freebsd-ufs  (5.0G)
   29362176   75493376    5  freebsd-zfs  (36G)
  104855552       2015       - free -  (1.0M)


# gpart status
 Name  Status  Components
da0p1      OK  da0
da0p2      OK  da0
da0p3      OK  da0
da0p4      OK  da0
da0p5      OK  da0


MD5 of the primary and backup partition tables are identical.

# dd if=/dev/da0 bs=512 skip=2 count=32 2>/dev/null | md5
03fb4d3642e76f454c5649e96512bd6f

# dd if=/dev/da0 bs=512 skip=104857567 count=32 2>/dev/null | md5
03fb4d3642e76f454c5649e96512bd6f


We then do an upgrade where we install onto /alt and set the appropriate
bootonce flag using

 gpart set -a bootonce -i 4 da0


After it boots on the alternate root:

# diskinfo -v da0
da0
        512             # sectorsize
        53687091200     # mediasize in bytes (50G)
        104857600       # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        6527            # Cylinders according to firmware.
        255             # Heads according to firmware.
        63              # Sectors according to firmware.
                        # Disk ident.
# gpart show
=>       34  104857533  da0  GPT  (50G) [CORRUPT]
         34          6       - free -  (3.0K)
         40       1024    1  freebsd-boot  (512K)
       1064    8388608    2  freebsd-swap  (4.0G)
    8389672        984       - free -  (492K)
    8390656   10485760    3  freebsd-ufs  [bootme]  (5.0G)
   18876416   10485760    4  freebsd-ufs  [bootonce]  (5.0G)
   29362176   75493376    5  freebsd-zfs  (36G)
  104855552       2015       - free -  (1.0M)

# gpart status
 Name   Status  Components
da0p1  CORRUPT  da0
da0p2  CORRUPT  da0
da0p3  CORRUPT  da0
da0p4  CORRUPT  da0
da0p5  CORRUPT  da0


Dump of the primary GPT header

# dd if=/dev/da0 bs=512 skip=1 count=1 2>/dev/null | hexdump
0000000 4645 2049 4150 5452 0000 0001 005c 0000
0000010 11e9 ae86 0000 0000 0001 0000 0000 0000
0000020 ffff 063f 0000 0000 0022 0000 0000 0000
0000030 ffde 063f 0000 0000 378d 9abb 18ed 11e5
0000040 9e8d 0008 3f27 7893 0002 0000 0000 0000
0000050 0080 0000 0080 0000 b6fe fca6 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*

Dump of the backup GPT header

# dd if=/dev/da0 bs=512 skip=104857599 count=1 2>/dev/null | hexdump
0000000 4645 2049 4150 5452 0000 0001 005c 0000
0000010 2997 eaf5 0000 0000 ffff 063f 0000 0000
0000020 0001 0000 0000 0000 0022 0000 0000 0000
0000030 ffde 063f 0000 0000 378d 9abb 18ed 11e5
0000040 9e8d 0008 3f27 7893 ffdf 063f 0000 0000
0000050 0080 0000 0080 0000 d0ab 529c 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*


MD5 of the primary and backup partition tables are different.

# dd if=/dev/da0 bs=512 skip=2 count=32 2>/dev/null | md5
1e8cc33d84d2ae1ec7621a662ac8cca0

# dd if=/dev/da0 bs=512 skip=104857567 count=32 2>/dev/null | md5
f07e707260e734d4a9d5baeaa077bc58


Dump of the primary partition table

# dd if=/dev/da0 bs=512 skip=2 count=32 2>/dev/null | hexdump
0000000 6b9d 83bd 7f41 11dc 0bbe 1500 b860 0f4f
0000010 b409 9abc 18ed 11e5 9e8d 0008 3f27 7893
0000020 0028 0000 0000 0000 0427 0000 0000 0000
0000030 0000 0000 0000 0000 0067 0070 0074 0062
0000040 006f 006f 0074 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 0000 0000 0000 0000
*
0000080 7cb5 516e 6ecf 11d6 f88f 0200 092d 2b71
0000090 3b28 9abe 18ed 11e5 9e8d 0008 3f27 7893
00000a0 0428 0000 0000 0000 0427 0080 0000 0000
00000b0 0000 0000 0000 0000 0061 006b 0069 0070
00000c0 0073 002d 0073 0077 0061 0070 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
*
0000100 7cb6 516e 6ecf 11d6 f88f 0200 092d 2b71
0000110 c0b3 9abf 18ed 11e5 9e8d 0008 3f27 7893
0000120 0800 0080 0000 0000 07ff 0120 0000 0000
0000130 0000 0000 0000 0800 0061 006b 0069 0070
0000140 0073 002d 0072 006f 006f 0074 0030 0000
0000150 0000 0000 0000 0000 0000 0000 0000 0000
*
0000180 7cb6 516e 6ecf 11d6 f88f 0200 092d 2b71
0000190 66da 9ac1 18ed 11e5 9e8d 0008 3f27 7893
00001a0 0800 0120 0000 0000 07ff 01c0 0000 0000
00001b0 0000 0000 0000 0400 0061 006b 0069 0070
00001c0 0073 002d 0072 006f 006f 0074 0031 0000
00001d0 0000 0000 0000 0000 0000 0000 0000 0000
*
0000200 7cba 516e 6ecf 11d6 f88f 0200 092d 2b71
0000210 1d30 9ac3 18ed 11e5 9e8d 0008 3f27 7893
0000220 0800 01c0 0000 0000 f7ff 063f 0000 0000
0000230 0000 0000 0000 0000 0061 006b 0069 0070
0000240 0073 002d 0068 006f 006d 0065 0000 0000
0000250 0000 0000 0000 0000 0000 0000 0000 0000
*


Dump of the backup partition table

# dd if=/dev/da0 bs=512 skip=104857567 count=32 2>/dev/null | hexdump
0000000 6b9d 83bd 7f41 11dc 0bbe 1500 b860 0f4f
0000010 b409 9abc 18ed 11e5 9e8d 0008 3f27 7893
0000020 0028 0000 0000 0000 0427 0000 0000 0000
0000030 0000 0000 0000 0000 0067 0070 0074 0062
0000040 006f 006f 0074 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 0000 0000 0000 0000
*
0000080 7cb5 516e 6ecf 11d6 f88f 0200 092d 2b71
0000090 3b28 9abe 18ed 11e5 9e8d 0008 3f27 7893
00000a0 0428 0000 0000 0000 0427 0080 0000 0000
00000b0 0000 0000 0000 0000 0061 006b 0069 0070
00000c0 0073 002d 0073 0077 0061 0070 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
*
0000100 7cb6 516e 6ecf 11d6 f88f 0200 092d 2b71
0000110 c0b3 9abf 18ed 11e5 9e8d 0008 3f27 7893
0000120 0800 0080 0000 0000 07ff 0120 0000 0000
0000130 0000 0000 0000 0800 0061 006b 0069 0070
0000140 0073 002d 0072 006f 006f 0074 0030 0000
0000150 0000 0000 0000 0000 0000 0000 0000 0000
*
0000180 7cb6 516e 6ecf 11d6 f88f 0200 092d 2b71
0000190 66da 9ac1 18ed 11e5 9e8d 0008 3f27 7893
00001a0 0800 0120 0000 0000 07ff 01c0 0000 0000
00001b0 0000 0000 0000 0c00 0061 006b 0069 0070 <<< different
00001c0 0073 002d 0072 006f 006f 0074 0031 0000
00001d0 0000 0000 0000 0000 0000 0000 0000 0000
*
0000200 7cba 516e 6ecf 11d6 f88f 0200 092d 2b71
0000210 1d30 9ac3 18ed 11e5 9e8d 0008 3f27 7893
0000220 0800 01c0 0000 0000 f7ff 063f 0000 0000
0000230 0000 0000 0000 0000 0061 006b 0069 0070
0000240 0073 002d 0068 006f 006d 0065 0000 0000
0000250 0000 0000 0000 0000 0000 0000 0000 0000
*


The line at offset 00001b0 is out by one bit.  Looks like the bootonce
flag is only updated in the primary partition table and not the backup.

At this point our boot script tries to do

 gpart set   -a bootme -i 4 da0
 gpart unset -a bootme -i 3 da0
 gpart unset -a bootonce -i 4 da0

but we of course get 
 gpart: table 'da0' is corrupt: Operation not permitted

We currently have a workaround that does
 gpart recover da0
before doing the set/unset gpart commands.


Not sure what we are doing wrong because it all works fine if we configure
the vm guest using a SATA controller.

	Paul.
-- 
Paul Koch | Founder, CEO
AKIPS Network Monitor | akips.com
Brisbane, Australia



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150622154143.21c68162>