vmtest says yes
--
https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/384133
Your team curtin developers is subscribed to branch curtin:master.
--
Mailing list: https://launchpad.net/~curtin-dev
Post to : curtin-dev@lists.launchpad.net
Unsubscribe :
Kicking off a few vmtests
--
https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/384133
Your team curtin developers is subscribed to branch curtin:master.
--
Mailing list: https://launchpad.net/~curtin-dev
Post to : curtin-dev@lists.launchpad.net
Unsubscribe :
@Chad
Yes, each partition entry has a type.
--
https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/384133
Your team curtin developers is subscribed to branch curtin:master.
--
Mailing list: https://launchpad.net/~curtin-dev
Post to : curtin-dev@lists.launchpad.net
Unsubscribe :
Diff comments:
> diff --git a/curtin/commands/block_meta.py b/curtin/commands/block_meta.py
> index f2bb8da..ff0f2e9 100644
> --- a/curtin/commands/block_meta.py
> +++ b/curtin/commands/block_meta.py
> @@ -760,7 +760,9 @@ def verify_ptable_flag(devpath, expected_flag,
> sfdisk_info=None):
>
Nice one Ryan, this looks good. one minor question/suggestion about whether we
can always expect a 'type' key from block.get_partition_sfdisk_info and how we
should handle it.
Otherwise +1
Diff comments:
> diff --git a/curtin/commands/block_meta.py b/curtin/commands/block_meta.py
> index
Review: Approve
--
https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/384133
Your team curtin developers is subscribed to branch curtin:master.
--
Mailing list: https://launchpad.net/~curtin-dev
Post to : curtin-dev@lists.launchpad.net
Unsubscribe :
Review: Approve
To the best of knowledge, I could not find any issue with the code
--
https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/384133
Your team curtin developers is subscribed to branch curtin:master.
--
Mailing list: https://launchpad.net/~curtin-dev
Post to :
Review: Approve continuous-integration
PASSED: Continuous integration, rev:669b5cf73d4cf15e1bccfb9913f15125fbb4b9c1
https://jenkins.ubuntu.com/server/job/curtin-ci/119/
Executed test runs:
SUCCESS:
https://jenkins.ubuntu.com/server/job/curtin-ci/nodes=metal-amd64/119/
SUCCESS:
Review: Needs Fixing continuous-integration
FAILED: Continuous integration, rev:7e0fb61b9b9ab35b02ff485ebfe963b1ee77ff01
https://jenkins.ubuntu.com/server/job/curtin-ci/118/
Executed test runs:
FAILURE:
https://jenkins.ubuntu.com/server/job/curtin-ci/nodes=metal-amd64/118/
FAILURE:
Review: Needs Fixing
Marking Needs Fixing so we don't land until I fix.
--
https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/384133
Your team curtin developers is subscribed to branch curtin:master.
--
Mailing list: https://launchpad.net/~curtin-dev
Post to :
Good catch, and actually I need to remove the 0x80 from the MBR table, as it's
a flag, not a table type. I'll add a unittest covering this scenario.
--
https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/384133
Your team curtin developers is requested to review the proposed merge of
I don't know if this is a possible scenario, but is it possible to have a boot
type partition that is not marked as bootable ?
For example, suppose we have this type of configuration:
sfdisk_info_dos = {
"label": "dos",
"id": "0xb0dbdde1",
"device":
Review: Approve continuous-integration
PASSED: Continuous integration, rev:92d0d6b367d8c1d97051cda34c929e7d71a0295f
https://jenkins.ubuntu.com/server/job/curtin-ci/111/
Executed test runs:
SUCCESS:
https://jenkins.ubuntu.com/server/job/curtin-ci/nodes=metal-amd64/111/
SUCCESS:
13 matches
Mail list logo
