Make parted start next partition after previous one - automatically?
I've inherited a shell script that pipes a list of 'random' characters to fdisk
. What it is doing is partitioning a disk as follows:
Set up the blank disk, partition table etc
Create first partition size A
Create second partition, size Y, immediately after the first one.
Create third partition, size X, immediately after the second one.
And to add to the 'fun', A, Y, and X are calculated and may change depending on the size of the available new disk.
Fdisk will prompt for starting position based on the existing positions and the 'code' just 'hits return' and accepts this.
This code is extremely opaque and I would like to replace it with calls to 'parted --script...
' instead of fdisk
but I can't see that parted has a way to say 'start immediately after the last partition'. It looks like I would have to keep calculating the start position myself.
Am I correct and if so does anyone have a sensible solution for this?
linux fdisk parted
bumped to the homepage by Community♦ 2 hours ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
I've inherited a shell script that pipes a list of 'random' characters to fdisk
. What it is doing is partitioning a disk as follows:
Set up the blank disk, partition table etc
Create first partition size A
Create second partition, size Y, immediately after the first one.
Create third partition, size X, immediately after the second one.
And to add to the 'fun', A, Y, and X are calculated and may change depending on the size of the available new disk.
Fdisk will prompt for starting position based on the existing positions and the 'code' just 'hits return' and accepts this.
This code is extremely opaque and I would like to replace it with calls to 'parted --script...
' instead of fdisk
but I can't see that parted has a way to say 'start immediately after the last partition'. It looks like I would have to keep calculating the start position myself.
Am I correct and if so does anyone have a sensible solution for this?
linux fdisk parted
bumped to the homepage by Community♦ 2 hours ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
I've inherited a shell script that pipes a list of 'random' characters to fdisk
. What it is doing is partitioning a disk as follows:
Set up the blank disk, partition table etc
Create first partition size A
Create second partition, size Y, immediately after the first one.
Create third partition, size X, immediately after the second one.
And to add to the 'fun', A, Y, and X are calculated and may change depending on the size of the available new disk.
Fdisk will prompt for starting position based on the existing positions and the 'code' just 'hits return' and accepts this.
This code is extremely opaque and I would like to replace it with calls to 'parted --script...
' instead of fdisk
but I can't see that parted has a way to say 'start immediately after the last partition'. It looks like I would have to keep calculating the start position myself.
Am I correct and if so does anyone have a sensible solution for this?
linux fdisk parted
I've inherited a shell script that pipes a list of 'random' characters to fdisk
. What it is doing is partitioning a disk as follows:
Set up the blank disk, partition table etc
Create first partition size A
Create second partition, size Y, immediately after the first one.
Create third partition, size X, immediately after the second one.
And to add to the 'fun', A, Y, and X are calculated and may change depending on the size of the available new disk.
Fdisk will prompt for starting position based on the existing positions and the 'code' just 'hits return' and accepts this.
This code is extremely opaque and I would like to replace it with calls to 'parted --script...
' instead of fdisk
but I can't see that parted has a way to say 'start immediately after the last partition'. It looks like I would have to keep calculating the start position myself.
Am I correct and if so does anyone have a sensible solution for this?
linux fdisk parted
linux fdisk parted
edited Feb 19 '18 at 10:43
alpha
1,232317
1,232317
asked Feb 19 '18 at 10:14
Paul D SmithPaul D Smith
214
214
bumped to the homepage by Community♦ 2 hours ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 2 hours ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
You don't have to write an exact duplicate of everything done by a bad script. Rewriting is an opportunity to fix the logic as well as the code. Start by deciphering what the original code does and then turn it into something sane.
The answer to your direct question is "No. You'll need to provide start and end yourself'. Fortunately, that's not terribly difficult.
parted
's mkpart
command takes a start
and and end
argument (units defaults to megabytes). You just need to specify them when you create the partitions. e.g. using a disk image file:
$ cat partition.sh
#!/bin/sh
truncate -s 1G disk.img # create a 1G disk image file
parted -s disk.img mklabel msdos # create the partition table
# make some partitions
parted -s disk.img mkpart primary 1 100
parted -s disk.img mkpart primary 101 200
parted -s disk.img mkpart primary 201 800
parted -s disk.img mkpart primary 801 1000
parted -s disk.img print
Alternatively, running parted
only once:
#!bin/sh
truncate -s 1G disk.img # create a 1G disk image file
parted -s disk.img mklabel msdos
mkpart primary 1 100
mkpart primary 101 200
mkpart primary 201 800
mkpart primary 801 1000
print
$ ./partition.sh
Model: (file)
Disk /home/cas/stack-exchange/2018-01-03/pauldsmith/disk.img: 1074MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 99.6MB 98.6MB primary
2 101MB 200MB 99.6MB primary
3 201MB 800MB 599MB primary
4 801MB 1000MB 199MB primary
The hard part is to calculate the exact start and end values for your partitions so that they are properly aligned for the sector size. The first partition is easy - 1MB aligns with both 512 byte and 4K sectors. Any partition starting at an exact multiple of 1MB will also be aligned correctly (all of the partitions created in the example above are correctly aligned).
You can use shell variables for any of the partition start and end values, which allows you to use shell arithmetic to calculate them (but remember that shell arithmetic is integer only - use bc
or dc
if you need to do floating-point or percentage calculations).
BTW, you can check alignment with parted
's align-check
command. e.g.
$ parted disk.img align-check optimal 1
WARNING: You are not superuser. Watch out for permissions.
1 aligned
If align-check
is used with parted
's -s
script mode option, it doesn't produce any output. Instead, it exits with status 1 if not aligned. Otherwise it continues with the remainder of the script.
parted
doesn't have any if/then capability, so if you want to automate alignment-checking as well as partition creation, use the first version of the script above so that you can insert a check-align
command in between each mkpart
and respond appropriately if the exit code is non-zero.
BTW, as well asparted
, bothsfdisk
(for msdos partition tables) andsgdisk
(for gpt partition tables) are designed for use in scripts. They also require you to specify the start and end of each partition.
– cas
Feb 20 '18 at 4:29
Thanks - that's about where I'd got to although I have a script which can now add a partition and then figure out where the last one ended by querying parted. Probably simpler just to calculate up front as you suggest providing I can confirm that the boot sector has a fixed and known size.
– Paul D Smith
Feb 20 '18 at 12:56
First-stage bootloaders typically use only a few sectors at most after the partition table - the rule of thumb for years has been "don't touch the first 63 sectors". So, for 512-byte sector disks, almost everyone made partition 1 start at >= sector 64. Since 4K sector disks started appearing, the standard has been to start partition 1 at 1MB. It's not uncommon these days to give grub its own small typeEF02
partition between sector 64 and the first 1MB, and/or a smallish typeEF00
partition immediately after that or at 1MB for the EFI system partition - a few hundred MB or a GB or so.
– cas
Feb 20 '18 at 13:12
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f425141%2fmake-parted-start-next-partition-after-previous-one-automatically%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You don't have to write an exact duplicate of everything done by a bad script. Rewriting is an opportunity to fix the logic as well as the code. Start by deciphering what the original code does and then turn it into something sane.
The answer to your direct question is "No. You'll need to provide start and end yourself'. Fortunately, that's not terribly difficult.
parted
's mkpart
command takes a start
and and end
argument (units defaults to megabytes). You just need to specify them when you create the partitions. e.g. using a disk image file:
$ cat partition.sh
#!/bin/sh
truncate -s 1G disk.img # create a 1G disk image file
parted -s disk.img mklabel msdos # create the partition table
# make some partitions
parted -s disk.img mkpart primary 1 100
parted -s disk.img mkpart primary 101 200
parted -s disk.img mkpart primary 201 800
parted -s disk.img mkpart primary 801 1000
parted -s disk.img print
Alternatively, running parted
only once:
#!bin/sh
truncate -s 1G disk.img # create a 1G disk image file
parted -s disk.img mklabel msdos
mkpart primary 1 100
mkpart primary 101 200
mkpart primary 201 800
mkpart primary 801 1000
print
$ ./partition.sh
Model: (file)
Disk /home/cas/stack-exchange/2018-01-03/pauldsmith/disk.img: 1074MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 99.6MB 98.6MB primary
2 101MB 200MB 99.6MB primary
3 201MB 800MB 599MB primary
4 801MB 1000MB 199MB primary
The hard part is to calculate the exact start and end values for your partitions so that they are properly aligned for the sector size. The first partition is easy - 1MB aligns with both 512 byte and 4K sectors. Any partition starting at an exact multiple of 1MB will also be aligned correctly (all of the partitions created in the example above are correctly aligned).
You can use shell variables for any of the partition start and end values, which allows you to use shell arithmetic to calculate them (but remember that shell arithmetic is integer only - use bc
or dc
if you need to do floating-point or percentage calculations).
BTW, you can check alignment with parted
's align-check
command. e.g.
$ parted disk.img align-check optimal 1
WARNING: You are not superuser. Watch out for permissions.
1 aligned
If align-check
is used with parted
's -s
script mode option, it doesn't produce any output. Instead, it exits with status 1 if not aligned. Otherwise it continues with the remainder of the script.
parted
doesn't have any if/then capability, so if you want to automate alignment-checking as well as partition creation, use the first version of the script above so that you can insert a check-align
command in between each mkpart
and respond appropriately if the exit code is non-zero.
BTW, as well asparted
, bothsfdisk
(for msdos partition tables) andsgdisk
(for gpt partition tables) are designed for use in scripts. They also require you to specify the start and end of each partition.
– cas
Feb 20 '18 at 4:29
Thanks - that's about where I'd got to although I have a script which can now add a partition and then figure out where the last one ended by querying parted. Probably simpler just to calculate up front as you suggest providing I can confirm that the boot sector has a fixed and known size.
– Paul D Smith
Feb 20 '18 at 12:56
First-stage bootloaders typically use only a few sectors at most after the partition table - the rule of thumb for years has been "don't touch the first 63 sectors". So, for 512-byte sector disks, almost everyone made partition 1 start at >= sector 64. Since 4K sector disks started appearing, the standard has been to start partition 1 at 1MB. It's not uncommon these days to give grub its own small typeEF02
partition between sector 64 and the first 1MB, and/or a smallish typeEF00
partition immediately after that or at 1MB for the EFI system partition - a few hundred MB or a GB or so.
– cas
Feb 20 '18 at 13:12
add a comment |
You don't have to write an exact duplicate of everything done by a bad script. Rewriting is an opportunity to fix the logic as well as the code. Start by deciphering what the original code does and then turn it into something sane.
The answer to your direct question is "No. You'll need to provide start and end yourself'. Fortunately, that's not terribly difficult.
parted
's mkpart
command takes a start
and and end
argument (units defaults to megabytes). You just need to specify them when you create the partitions. e.g. using a disk image file:
$ cat partition.sh
#!/bin/sh
truncate -s 1G disk.img # create a 1G disk image file
parted -s disk.img mklabel msdos # create the partition table
# make some partitions
parted -s disk.img mkpart primary 1 100
parted -s disk.img mkpart primary 101 200
parted -s disk.img mkpart primary 201 800
parted -s disk.img mkpart primary 801 1000
parted -s disk.img print
Alternatively, running parted
only once:
#!bin/sh
truncate -s 1G disk.img # create a 1G disk image file
parted -s disk.img mklabel msdos
mkpart primary 1 100
mkpart primary 101 200
mkpart primary 201 800
mkpart primary 801 1000
print
$ ./partition.sh
Model: (file)
Disk /home/cas/stack-exchange/2018-01-03/pauldsmith/disk.img: 1074MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 99.6MB 98.6MB primary
2 101MB 200MB 99.6MB primary
3 201MB 800MB 599MB primary
4 801MB 1000MB 199MB primary
The hard part is to calculate the exact start and end values for your partitions so that they are properly aligned for the sector size. The first partition is easy - 1MB aligns with both 512 byte and 4K sectors. Any partition starting at an exact multiple of 1MB will also be aligned correctly (all of the partitions created in the example above are correctly aligned).
You can use shell variables for any of the partition start and end values, which allows you to use shell arithmetic to calculate them (but remember that shell arithmetic is integer only - use bc
or dc
if you need to do floating-point or percentage calculations).
BTW, you can check alignment with parted
's align-check
command. e.g.
$ parted disk.img align-check optimal 1
WARNING: You are not superuser. Watch out for permissions.
1 aligned
If align-check
is used with parted
's -s
script mode option, it doesn't produce any output. Instead, it exits with status 1 if not aligned. Otherwise it continues with the remainder of the script.
parted
doesn't have any if/then capability, so if you want to automate alignment-checking as well as partition creation, use the first version of the script above so that you can insert a check-align
command in between each mkpart
and respond appropriately if the exit code is non-zero.
BTW, as well asparted
, bothsfdisk
(for msdos partition tables) andsgdisk
(for gpt partition tables) are designed for use in scripts. They also require you to specify the start and end of each partition.
– cas
Feb 20 '18 at 4:29
Thanks - that's about where I'd got to although I have a script which can now add a partition and then figure out where the last one ended by querying parted. Probably simpler just to calculate up front as you suggest providing I can confirm that the boot sector has a fixed and known size.
– Paul D Smith
Feb 20 '18 at 12:56
First-stage bootloaders typically use only a few sectors at most after the partition table - the rule of thumb for years has been "don't touch the first 63 sectors". So, for 512-byte sector disks, almost everyone made partition 1 start at >= sector 64. Since 4K sector disks started appearing, the standard has been to start partition 1 at 1MB. It's not uncommon these days to give grub its own small typeEF02
partition between sector 64 and the first 1MB, and/or a smallish typeEF00
partition immediately after that or at 1MB for the EFI system partition - a few hundred MB or a GB or so.
– cas
Feb 20 '18 at 13:12
add a comment |
You don't have to write an exact duplicate of everything done by a bad script. Rewriting is an opportunity to fix the logic as well as the code. Start by deciphering what the original code does and then turn it into something sane.
The answer to your direct question is "No. You'll need to provide start and end yourself'. Fortunately, that's not terribly difficult.
parted
's mkpart
command takes a start
and and end
argument (units defaults to megabytes). You just need to specify them when you create the partitions. e.g. using a disk image file:
$ cat partition.sh
#!/bin/sh
truncate -s 1G disk.img # create a 1G disk image file
parted -s disk.img mklabel msdos # create the partition table
# make some partitions
parted -s disk.img mkpart primary 1 100
parted -s disk.img mkpart primary 101 200
parted -s disk.img mkpart primary 201 800
parted -s disk.img mkpart primary 801 1000
parted -s disk.img print
Alternatively, running parted
only once:
#!bin/sh
truncate -s 1G disk.img # create a 1G disk image file
parted -s disk.img mklabel msdos
mkpart primary 1 100
mkpart primary 101 200
mkpart primary 201 800
mkpart primary 801 1000
print
$ ./partition.sh
Model: (file)
Disk /home/cas/stack-exchange/2018-01-03/pauldsmith/disk.img: 1074MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 99.6MB 98.6MB primary
2 101MB 200MB 99.6MB primary
3 201MB 800MB 599MB primary
4 801MB 1000MB 199MB primary
The hard part is to calculate the exact start and end values for your partitions so that they are properly aligned for the sector size. The first partition is easy - 1MB aligns with both 512 byte and 4K sectors. Any partition starting at an exact multiple of 1MB will also be aligned correctly (all of the partitions created in the example above are correctly aligned).
You can use shell variables for any of the partition start and end values, which allows you to use shell arithmetic to calculate them (but remember that shell arithmetic is integer only - use bc
or dc
if you need to do floating-point or percentage calculations).
BTW, you can check alignment with parted
's align-check
command. e.g.
$ parted disk.img align-check optimal 1
WARNING: You are not superuser. Watch out for permissions.
1 aligned
If align-check
is used with parted
's -s
script mode option, it doesn't produce any output. Instead, it exits with status 1 if not aligned. Otherwise it continues with the remainder of the script.
parted
doesn't have any if/then capability, so if you want to automate alignment-checking as well as partition creation, use the first version of the script above so that you can insert a check-align
command in between each mkpart
and respond appropriately if the exit code is non-zero.
You don't have to write an exact duplicate of everything done by a bad script. Rewriting is an opportunity to fix the logic as well as the code. Start by deciphering what the original code does and then turn it into something sane.
The answer to your direct question is "No. You'll need to provide start and end yourself'. Fortunately, that's not terribly difficult.
parted
's mkpart
command takes a start
and and end
argument (units defaults to megabytes). You just need to specify them when you create the partitions. e.g. using a disk image file:
$ cat partition.sh
#!/bin/sh
truncate -s 1G disk.img # create a 1G disk image file
parted -s disk.img mklabel msdos # create the partition table
# make some partitions
parted -s disk.img mkpart primary 1 100
parted -s disk.img mkpart primary 101 200
parted -s disk.img mkpart primary 201 800
parted -s disk.img mkpart primary 801 1000
parted -s disk.img print
Alternatively, running parted
only once:
#!bin/sh
truncate -s 1G disk.img # create a 1G disk image file
parted -s disk.img mklabel msdos
mkpart primary 1 100
mkpart primary 101 200
mkpart primary 201 800
mkpart primary 801 1000
print
$ ./partition.sh
Model: (file)
Disk /home/cas/stack-exchange/2018-01-03/pauldsmith/disk.img: 1074MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 99.6MB 98.6MB primary
2 101MB 200MB 99.6MB primary
3 201MB 800MB 599MB primary
4 801MB 1000MB 199MB primary
The hard part is to calculate the exact start and end values for your partitions so that they are properly aligned for the sector size. The first partition is easy - 1MB aligns with both 512 byte and 4K sectors. Any partition starting at an exact multiple of 1MB will also be aligned correctly (all of the partitions created in the example above are correctly aligned).
You can use shell variables for any of the partition start and end values, which allows you to use shell arithmetic to calculate them (but remember that shell arithmetic is integer only - use bc
or dc
if you need to do floating-point or percentage calculations).
BTW, you can check alignment with parted
's align-check
command. e.g.
$ parted disk.img align-check optimal 1
WARNING: You are not superuser. Watch out for permissions.
1 aligned
If align-check
is used with parted
's -s
script mode option, it doesn't produce any output. Instead, it exits with status 1 if not aligned. Otherwise it continues with the remainder of the script.
parted
doesn't have any if/then capability, so if you want to automate alignment-checking as well as partition creation, use the first version of the script above so that you can insert a check-align
command in between each mkpart
and respond appropriately if the exit code is non-zero.
answered Feb 20 '18 at 4:22
cascas
38.7k452100
38.7k452100
BTW, as well asparted
, bothsfdisk
(for msdos partition tables) andsgdisk
(for gpt partition tables) are designed for use in scripts. They also require you to specify the start and end of each partition.
– cas
Feb 20 '18 at 4:29
Thanks - that's about where I'd got to although I have a script which can now add a partition and then figure out where the last one ended by querying parted. Probably simpler just to calculate up front as you suggest providing I can confirm that the boot sector has a fixed and known size.
– Paul D Smith
Feb 20 '18 at 12:56
First-stage bootloaders typically use only a few sectors at most after the partition table - the rule of thumb for years has been "don't touch the first 63 sectors". So, for 512-byte sector disks, almost everyone made partition 1 start at >= sector 64. Since 4K sector disks started appearing, the standard has been to start partition 1 at 1MB. It's not uncommon these days to give grub its own small typeEF02
partition between sector 64 and the first 1MB, and/or a smallish typeEF00
partition immediately after that or at 1MB for the EFI system partition - a few hundred MB or a GB or so.
– cas
Feb 20 '18 at 13:12
add a comment |
BTW, as well asparted
, bothsfdisk
(for msdos partition tables) andsgdisk
(for gpt partition tables) are designed for use in scripts. They also require you to specify the start and end of each partition.
– cas
Feb 20 '18 at 4:29
Thanks - that's about where I'd got to although I have a script which can now add a partition and then figure out where the last one ended by querying parted. Probably simpler just to calculate up front as you suggest providing I can confirm that the boot sector has a fixed and known size.
– Paul D Smith
Feb 20 '18 at 12:56
First-stage bootloaders typically use only a few sectors at most after the partition table - the rule of thumb for years has been "don't touch the first 63 sectors". So, for 512-byte sector disks, almost everyone made partition 1 start at >= sector 64. Since 4K sector disks started appearing, the standard has been to start partition 1 at 1MB. It's not uncommon these days to give grub its own small typeEF02
partition between sector 64 and the first 1MB, and/or a smallish typeEF00
partition immediately after that or at 1MB for the EFI system partition - a few hundred MB or a GB or so.
– cas
Feb 20 '18 at 13:12
BTW, as well as
parted
, both sfdisk
(for msdos partition tables) and sgdisk
(for gpt partition tables) are designed for use in scripts. They also require you to specify the start and end of each partition.– cas
Feb 20 '18 at 4:29
BTW, as well as
parted
, both sfdisk
(for msdos partition tables) and sgdisk
(for gpt partition tables) are designed for use in scripts. They also require you to specify the start and end of each partition.– cas
Feb 20 '18 at 4:29
Thanks - that's about where I'd got to although I have a script which can now add a partition and then figure out where the last one ended by querying parted. Probably simpler just to calculate up front as you suggest providing I can confirm that the boot sector has a fixed and known size.
– Paul D Smith
Feb 20 '18 at 12:56
Thanks - that's about where I'd got to although I have a script which can now add a partition and then figure out where the last one ended by querying parted. Probably simpler just to calculate up front as you suggest providing I can confirm that the boot sector has a fixed and known size.
– Paul D Smith
Feb 20 '18 at 12:56
First-stage bootloaders typically use only a few sectors at most after the partition table - the rule of thumb for years has been "don't touch the first 63 sectors". So, for 512-byte sector disks, almost everyone made partition 1 start at >= sector 64. Since 4K sector disks started appearing, the standard has been to start partition 1 at 1MB. It's not uncommon these days to give grub its own small type
EF02
partition between sector 64 and the first 1MB, and/or a smallish type EF00
partition immediately after that or at 1MB for the EFI system partition - a few hundred MB or a GB or so.– cas
Feb 20 '18 at 13:12
First-stage bootloaders typically use only a few sectors at most after the partition table - the rule of thumb for years has been "don't touch the first 63 sectors". So, for 512-byte sector disks, almost everyone made partition 1 start at >= sector 64. Since 4K sector disks started appearing, the standard has been to start partition 1 at 1MB. It's not uncommon these days to give grub its own small type
EF02
partition between sector 64 and the first 1MB, and/or a smallish type EF00
partition immediately after that or at 1MB for the EFI system partition - a few hundred MB or a GB or so.– cas
Feb 20 '18 at 13:12
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2funix.stackexchange.com%2fquestions%2f425141%2fmake-parted-start-next-partition-after-previous-one-automatically%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