Found a dos partition table in /dev/nvme1n1
we have a setup at Amazon where we use the 16.04 LTS AMI.
Today we planned to change to the newer 18.04 LTS AMI.
We do this by updating the Cloudformation template with the latest AMI-ID.
But when running the Cloudformation template we get this error at the backup volume setup,
2019-02-21 09:25:17,234 P8657 [INFO] Set up backup volume
2019-02-21 09:25:17,234 P8657 [INFO] mke2fs 1.44.1 (24-Mar-2018)
2019-02-21 09:25:17,234 P8657 [INFO] Found a dos partition table in
/dev/nvme1n1 2019-02-21 09:25:17,234 P8657 [INFO] Proceed anyway?
(y,N) 2019-02-21 09:25:17,235 P8657 [INFO]
------------------------------------------------------------ 2019-02-21 09:25:17,235 P8657 [ERROR] Exited with error code 1
Doing the same thing with the latest 16.04 LTS AMI is working without any problems. The first thing that I saw was that the mke2fs versions are different, mke2fs 1.42.13 for 16.04 and mke2fs 1.44.1 for 18.04.
Are there any big differences for the way those versions handles the filesystems? The volumes are already created, we just want them attached again.
Here is some output from the 16.04 LTS installation.
fdisk output:
Disk /dev/nvme1n1: 1 TiB, 1099511627776 bytes, 2147483648 sectors
Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical):
512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512
bytes
Disk /dev/nvme0n1: 32 GiB, 34359738368 bytes, 67108864 sectors Units:
sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512
bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos Disk identifier: 0x30c871d7
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 * 2048 67108830 67106783 32G 83 Linux
Disk /dev/nvme2n1: 1000 GiB, 1073741824000 bytes, 2097152000 sectors
Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical):
512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512
bytes
parted output:
Model: NVMe Device (nvme) Disk /dev/nvme0n1: 34.4GB Sector size
(logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags 1
1049kB 34.4GB 34.4GB primary ext4 boot
Model: NVMe Device (nvme) Disk /dev/nvme1n1: 1100GB Sector size
(logical/physical): 512B/512B Partition Table: loop Disk Flags:
Number Start End Size File system Flags 1 0.00B
1100GB 1100GB ext4
Model: NVMe Device (nvme) Disk /dev/nvme2n1: 1074GB Sector size
(logical/physical): 512B/512B Partition Table: loop Disk Flags:
Number Start End Size File system Flags 1 0.00B
1074GB 1074GB ext4
fstab output:
LABEL=cloudimg-rootfs / ext4 defaults,discard 0 0
/dev/nvme1n1 /backup auto noatime 0 0
/dev/nvme2n1 /data auto noatime 0 0
16.04 18.04 mount hard-drive
asked Feb 21 at 11:37
Peter O NilssonPeter O Nilsson
12
add a comment |
we have a setup at Amazon where we use the 16.04 LTS AMI.
Today we planned to change to the newer 18.04 LTS AMI.
We do this by updating the Cloudformation template with the latest AMI-ID.
But when running the Cloudformation template we get this error at the backup volume setup,
2019-02-21 09:25:17,234 P8657 [INFO] Set up backup volume
2019-02-21 09:25:17,234 P8657 [INFO] mke2fs 1.44.1 (24-Mar-2018)
2019-02-21 09:25:17,234 P8657 [INFO] Found a dos partition table in
/dev/nvme1n1 2019-02-21 09:25:17,234 P8657 [INFO] Proceed anyway?
(y,N) 2019-02-21 09:25:17,235 P8657 [INFO]
------------------------------------------------------------ 2019-02-21 09:25:17,235 P8657 [ERROR] Exited with error code 1
Doing the same thing with the latest 16.04 LTS AMI is working without any problems. The first thing that I saw was that the mke2fs versions are different, mke2fs 1.42.13 for 16.04 and mke2fs 1.44.1 for 18.04.
Are there any big differences for the way those versions handles the filesystems? The volumes are already created, we just want them attached again.
Here is some output from the 16.04 LTS installation.
fdisk output:
Disk /dev/nvme1n1: 1 TiB, 1099511627776 bytes, 2147483648 sectors
Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical):
512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512
bytes
Disk /dev/nvme0n1: 32 GiB, 34359738368 bytes, 67108864 sectors Units:
sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512
bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos Disk identifier: 0x30c871d7
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 * 2048 67108830 67106783 32G 83 Linux
Disk /dev/nvme2n1: 1000 GiB, 1073741824000 bytes, 2097152000 sectors
Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical):
512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512
bytes
parted output:
Model: NVMe Device (nvme) Disk /dev/nvme0n1: 34.4GB Sector size
(logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags 1
1049kB 34.4GB 34.4GB primary ext4 boot
Model: NVMe Device (nvme) Disk /dev/nvme1n1: 1100GB Sector size
(logical/physical): 512B/512B Partition Table: loop Disk Flags:
Number Start End Size File system Flags 1 0.00B
1100GB 1100GB ext4
Model: NVMe Device (nvme) Disk /dev/nvme2n1: 1074GB Sector size
(logical/physical): 512B/512B Partition Table: loop Disk Flags:
Number Start End Size File system Flags 1 0.00B
1074GB 1074GB ext4
fstab output:
LABEL=cloudimg-rootfs / ext4 defaults,discard 0 0
/dev/nvme1n1 /backup auto noatime 0 0
/dev/nvme2n1 /data auto noatime 0 0
16.04 18.04 mount hard-drive
asked Feb 21 at 11:37
Peter O NilssonPeter O Nilsson
12
1
Drive is gpt only if you install in UEFI mode, partition using gpt or drive is over 2TiB. Gparted otherwise defaults to MBR and you have to choose gpt before starting to partition drive. If you have good backups and willing to reinstall boot loader(s) you can convert. Converting to or from GPT rodsbooks.com/gdisk/mbr2gpt.html
– oldfred
Feb 21 at 14:04
The installation is working when we use the 16.04 AMI, but not when we use the 18.04 AMI. We use the same CloudFormation template when we do the installation, we only change which AMI-ID to use. The volumes are already created and remains the same, they are just attached to the new installation.
– Peter O Nilsson
Feb 22 at 8:24
After the setup had failed I tried to run the failing part manually. ` $ sudo mkfs -t ext4 /dev/nvme1n1 mke2fs 1.44.1 (24-Mar-2018) Found a dos partition table in /dev/nvme1n1 Proceed anyway? (y,N) y /dev/nvme1n1 is apparently in use by the system; will not make a filesystem here! `
– Peter O Nilsson
Feb 22 at 13:10
The volume size is 1 TB, but I have tried with smaller ones with the same result. This problems only happens with the Ubuntu 18.04 AMI. I have also deleted the whole CloudFormation installation and started the installation from scratch wit ´h the 18.04 AMI. The result is the same as when I just did an update with the AMI of the running CloudFormation.
– Peter O Nilsson
Feb 22 at 13:16
It seems like that it attching the root device to nvme1n1 instead for the nvme0n1. That's the reason why it reports that there is dos partition table in nvme1n1. This only happens with the 18.04 AMI. ``` Model: Amazon Elastic Block Store (nvme) Disk /dev/nvme1n1: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 34.4GB 34.4GB primary ext4 boot ```
– Peter O Nilsson
Feb 22 at 13:53
add a comment |
we have a setup at Amazon where we use the 16.04 LTS AMI.
Today we planned to change to the newer 18.04 LTS AMI.
We do this by updating the Cloudformation template with the latest AMI-ID.
But when running the Cloudformation template we get this error at the backup volume setup,
2019-02-21 09:25:17,234 P8657 [INFO] Set up backup volume
2019-02-21 09:25:17,234 P8657 [INFO] mke2fs 1.44.1 (24-Mar-2018)
2019-02-21 09:25:17,234 P8657 [INFO] Found a dos partition table in
/dev/nvme1n1 2019-02-21 09:25:17,234 P8657 [INFO] Proceed anyway?
(y,N) 2019-02-21 09:25:17,235 P8657 [INFO]
------------------------------------------------------------ 2019-02-21 09:25:17,235 P8657 [ERROR] Exited with error code 1
Doing the same thing with the latest 16.04 LTS AMI is working without any problems. The first thing that I saw was that the mke2fs versions are different, mke2fs 1.42.13 for 16.04 and mke2fs 1.44.1 for 18.04.
Are there any big differences for the way those versions handles the filesystems? The volumes are already created, we just want them attached again.
Here is some output from the 16.04 LTS installation.
fdisk output:
Disk /dev/nvme1n1: 1 TiB, 1099511627776 bytes, 2147483648 sectors
Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical):
512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512
bytes
Disk /dev/nvme0n1: 32 GiB, 34359738368 bytes, 67108864 sectors Units:
sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512
bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos Disk identifier: 0x30c871d7
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 * 2048 67108830 67106783 32G 83 Linux
Disk /dev/nvme2n1: 1000 GiB, 1073741824000 bytes, 2097152000 sectors
Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical):
512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512
bytes
parted output:
Model: NVMe Device (nvme) Disk /dev/nvme0n1: 34.4GB Sector size
(logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags 1
1049kB 34.4GB 34.4GB primary ext4 boot
Model: NVMe Device (nvme) Disk /dev/nvme1n1: 1100GB Sector size
(logical/physical): 512B/512B Partition Table: loop Disk Flags:
Number Start End Size File system Flags 1 0.00B
1100GB 1100GB ext4
Model: NVMe Device (nvme) Disk /dev/nvme2n1: 1074GB Sector size
(logical/physical): 512B/512B Partition Table: loop Disk Flags:
Number Start End Size File system Flags 1 0.00B
1074GB 1074GB ext4
fstab output:
LABEL=cloudimg-rootfs / ext4 defaults,discard 0 0
/dev/nvme1n1 /backup auto noatime 0 0
/dev/nvme2n1 /data auto noatime 0 0
16.04 18.04 mount hard-drive
asked Feb 21 at 11:37
Peter O NilssonPeter O Nilsson
12
we have a setup at Amazon where we use the 16.04 LTS AMI.
Today we planned to change to the newer 18.04 LTS AMI.
We do this by updating the Cloudformation template with the latest AMI-ID.
But when running the Cloudformation template we get this error at the backup volume setup,
2019-02-21 09:25:17,234 P8657 [INFO] Set up backup volume
2019-02-21 09:25:17,234 P8657 [INFO] mke2fs 1.44.1 (24-Mar-2018)
2019-02-21 09:25:17,234 P8657 [INFO] Found a dos partition table in
/dev/nvme1n1 2019-02-21 09:25:17,234 P8657 [INFO] Proceed anyway?
(y,N) 2019-02-21 09:25:17,235 P8657 [INFO]
------------------------------------------------------------ 2019-02-21 09:25:17,235 P8657 [ERROR] Exited with error code 1
Doing the same thing with the latest 16.04 LTS AMI is working without any problems. The first thing that I saw was that the mke2fs versions are different, mke2fs 1.42.13 for 16.04 and mke2fs 1.44.1 for 18.04.
Are there any big differences for the way those versions handles the filesystems? The volumes are already created, we just want them attached again.
Here is some output from the 16.04 LTS installation.
fdisk output:
Disk /dev/nvme1n1: 1 TiB, 1099511627776 bytes, 2147483648 sectors
Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical):
512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512
bytes
Disk /dev/nvme0n1: 32 GiB, 34359738368 bytes, 67108864 sectors Units:
sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512
bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos Disk identifier: 0x30c871d7
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 * 2048 67108830 67106783 32G 83 Linux
Disk /dev/nvme2n1: 1000 GiB, 1073741824000 bytes, 2097152000 sectors
Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical):
512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512
bytes
parted output:
Model: NVMe Device (nvme) Disk /dev/nvme0n1: 34.4GB Sector size
(logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags 1
1049kB 34.4GB 34.4GB primary ext4 boot
Model: NVMe Device (nvme) Disk /dev/nvme1n1: 1100GB Sector size
(logical/physical): 512B/512B Partition Table: loop Disk Flags:
Number Start End Size File system Flags 1 0.00B
1100GB 1100GB ext4
Model: NVMe Device (nvme) Disk /dev/nvme2n1: 1074GB Sector size
(logical/physical): 512B/512B Partition Table: loop Disk Flags:
Number Start End Size File system Flags 1 0.00B
1074GB 1074GB ext4
fstab output:
LABEL=cloudimg-rootfs / ext4 defaults,discard 0 0
/dev/nvme1n1 /backup auto noatime 0 0
/dev/nvme2n1 /data auto noatime 0 0
16.04 18.04 mount hard-drive
16.04 18.04 mount hard-drive
asked Feb 21 at 11:37
Peter O NilssonPeter O Nilsson
12
asked Feb 21 at 11:37
Peter O NilssonPeter O Nilsson
12
asked Feb 21 at 11:37
Peter O NilssonPeter O Nilsson
12
asked Feb 21 at 11:37
Peter O NilssonPeter O Nilsson
12
asked Feb 21 at 11:37
Peter O NilssonPeter O Nilsson
12
12
1
Drive is gpt only if you install in UEFI mode, partition using gpt or drive is over 2TiB. Gparted otherwise defaults to MBR and you have to choose gpt before starting to partition drive. If you have good backups and willing to reinstall boot loader(s) you can convert. Converting to or from GPT rodsbooks.com/gdisk/mbr2gpt.html
– oldfred
Feb 21 at 14:04
The installation is working when we use the 16.04 AMI, but not when we use the 18.04 AMI. We use the same CloudFormation template when we do the installation, we only change which AMI-ID to use. The volumes are already created and remains the same, they are just attached to the new installation.
– Peter O Nilsson
Feb 22 at 8:24
After the setup had failed I tried to run the failing part manually. ` $ sudo mkfs -t ext4 /dev/nvme1n1 mke2fs 1.44.1 (24-Mar-2018) Found a dos partition table in /dev/nvme1n1 Proceed anyway? (y,N) y /dev/nvme1n1 is apparently in use by the system; will not make a filesystem here! `
– Peter O Nilsson
Feb 22 at 13:10
The volume size is 1 TB, but I have tried with smaller ones with the same result. This problems only happens with the Ubuntu 18.04 AMI. I have also deleted the whole CloudFormation installation and started the installation from scratch wit ´h the 18.04 AMI. The result is the same as when I just did an update with the AMI of the running CloudFormation.
– Peter O Nilsson
Feb 22 at 13:16
It seems like that it attching the root device to nvme1n1 instead for the nvme0n1. That's the reason why it reports that there is dos partition table in nvme1n1. This only happens with the 18.04 AMI. ``` Model: Amazon Elastic Block Store (nvme) Disk /dev/nvme1n1: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 34.4GB 34.4GB primary ext4 boot ```
– Peter O Nilsson
Feb 22 at 13:53
add a comment |
1
Drive is gpt only if you install in UEFI mode, partition using gpt or drive is over 2TiB. Gparted otherwise defaults to MBR and you have to choose gpt before starting to partition drive. If you have good backups and willing to reinstall boot loader(s) you can convert. Converting to or from GPT rodsbooks.com/gdisk/mbr2gpt.html
– oldfred
Feb 21 at 14:04
The installation is working when we use the 16.04 AMI, but not when we use the 18.04 AMI. We use the same CloudFormation template when we do the installation, we only change which AMI-ID to use. The volumes are already created and remains the same, they are just attached to the new installation.
– Peter O Nilsson
Feb 22 at 8:24
After the setup had failed I tried to run the failing part manually. ` $ sudo mkfs -t ext4 /dev/nvme1n1 mke2fs 1.44.1 (24-Mar-2018) Found a dos partition table in /dev/nvme1n1 Proceed anyway? (y,N) y /dev/nvme1n1 is apparently in use by the system; will not make a filesystem here! `
– Peter O Nilsson
Feb 22 at 13:10
The volume size is 1 TB, but I have tried with smaller ones with the same result. This problems only happens with the Ubuntu 18.04 AMI. I have also deleted the whole CloudFormation installation and started the installation from scratch wit ´h the 18.04 AMI. The result is the same as when I just did an update with the AMI of the running CloudFormation.
– Peter O Nilsson
Feb 22 at 13:16
It seems like that it attching the root device to nvme1n1 instead for the nvme0n1. That's the reason why it reports that there is dos partition table in nvme1n1. This only happens with the 18.04 AMI. ``` Model: Amazon Elastic Block Store (nvme) Disk /dev/nvme1n1: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 34.4GB 34.4GB primary ext4 boot ```
– Peter O Nilsson
Feb 22 at 13:53
1
1
Drive is gpt only if you install in UEFI mode, partition using gpt or drive is over 2TiB. Gparted otherwise defaults to MBR and you have to choose gpt before starting to partition drive. If you have good backups and willing to reinstall boot loader(s) you can convert. Converting to or from GPT rodsbooks.com/gdisk/mbr2gpt.html
– oldfred
Feb 21 at 14:04
Drive is gpt only if you install in UEFI mode, partition using gpt or drive is over 2TiB. Gparted otherwise defaults to MBR and you have to choose gpt before starting to partition drive. If you have good backups and willing to reinstall boot loader(s) you can convert. Converting to or from GPT rodsbooks.com/gdisk/mbr2gpt.html
– oldfred
Feb 21 at 14:04
The installation is working when we use the 16.04 AMI, but not when we use the 18.04 AMI. We use the same CloudFormation template when we do the installation, we only change which AMI-ID to use. The volumes are already created and remains the same, they are just attached to the new installation.
– Peter O Nilsson
Feb 22 at 8:24
The installation is working when we use the 16.04 AMI, but not when we use the 18.04 AMI. We use the same CloudFormation template when we do the installation, we only change which AMI-ID to use. The volumes are already created and remains the same, they are just attached to the new installation.
– Peter O Nilsson
Feb 22 at 8:24
After the setup had failed I tried to run the failing part manually. ` $ sudo mkfs -t ext4 /dev/nvme1n1 mke2fs 1.44.1 (24-Mar-2018) Found a dos partition table in /dev/nvme1n1 Proceed anyway? (y,N) y /dev/nvme1n1 is apparently in use by the system; will not make a filesystem here! `
– Peter O Nilsson
Feb 22 at 13:10
After the setup had failed I tried to run the failing part manually. ` $ sudo mkfs -t ext4 /dev/nvme1n1 mke2fs 1.44.1 (24-Mar-2018) Found a dos partition table in /dev/nvme1n1 Proceed anyway? (y,N) y /dev/nvme1n1 is apparently in use by the system; will not make a filesystem here! `
– Peter O Nilsson
Feb 22 at 13:10
The volume size is 1 TB, but I have tried with smaller ones with the same result. This problems only happens with the Ubuntu 18.04 AMI. I have also deleted the whole CloudFormation installation and started the installation from scratch wit ´h the 18.04 AMI. The result is the same as when I just did an update with the AMI of the running CloudFormation.
– Peter O Nilsson
Feb 22 at 13:16
The volume size is 1 TB, but I have tried with smaller ones with the same result. This problems only happens with the Ubuntu 18.04 AMI. I have also deleted the whole CloudFormation installation and started the installation from scratch wit ´h the 18.04 AMI. The result is the same as when I just did an update with the AMI of the running CloudFormation.
– Peter O Nilsson
Feb 22 at 13:16
It seems like that it attching the root device to nvme1n1 instead for the nvme0n1. That's the reason why it reports that there is dos partition table in nvme1n1. This only happens with the 18.04 AMI. ``` Model: Amazon Elastic Block Store (nvme) Disk /dev/nvme1n1: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 34.4GB 34.4GB primary ext4 boot ```
– Peter O Nilsson
Feb 22 at 13:53
It seems like that it attching the root device to nvme1n1 instead for the nvme0n1. That's the reason why it reports that there is dos partition table in nvme1n1. This only happens with the 18.04 AMI. ``` Model: Amazon Elastic Block Store (nvme) Disk /dev/nvme1n1: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 34.4GB 34.4GB primary ext4 boot ```
– Peter O Nilsson
Feb 22 at 13:53
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1120100%2ffound-a-dos-partition-table-in-dev-nvme1n1%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1120100%2ffound-a-dos-partition-table-in-dev-nvme1n1%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Drive is gpt only if you install in UEFI mode, partition using gpt or drive is over 2TiB. Gparted otherwise defaults to MBR and you have to choose gpt before starting to partition drive. If you have good backups and willing to reinstall boot loader(s) you can convert. Converting to or from GPT rodsbooks.com/gdisk/mbr2gpt.html
– oldfred
Feb 21 at 14:04
The installation is working when we use the 16.04 AMI, but not when we use the 18.04 AMI. We use the same CloudFormation template when we do the installation, we only change which AMI-ID to use. The volumes are already created and remains the same, they are just attached to the new installation.
– Peter O Nilsson
Feb 22 at 8:24
After the setup had failed I tried to run the failing part manually. ` $ sudo mkfs -t ext4 /dev/nvme1n1 mke2fs 1.44.1 (24-Mar-2018) Found a dos partition table in /dev/nvme1n1 Proceed anyway? (y,N) y /dev/nvme1n1 is apparently in use by the system; will not make a filesystem here! `
– Peter O Nilsson
Feb 22 at 13:10
The volume size is 1 TB, but I have tried with smaller ones with the same result. This problems only happens with the Ubuntu 18.04 AMI. I have also deleted the whole CloudFormation installation and started the installation from scratch wit ´h the 18.04 AMI. The result is the same as when I just did an update with the AMI of the running CloudFormation.
– Peter O Nilsson
Feb 22 at 13:16
It seems like that it attching the root device to nvme1n1 instead for the nvme0n1. That's the reason why it reports that there is dos partition table in nvme1n1. This only happens with the 18.04 AMI. ``` Model: Amazon Elastic Block Store (nvme) Disk /dev/nvme1n1: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 34.4GB 34.4GB primary ext4 boot ```
– Peter O Nilsson
Feb 22 at 13:53