summaryrefslogtreecommitdiff
path: root/doc/forum/imageBuiltFor_mount_points_not_automatically_created/comment_9_68b3d9ca04283c2400f5b23e486bb4b7._comment
blob: fd5b25e4420d5d8cc3d2f49b79a0cc06402f2b87 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
[[!comment format=mdwn
 username="joey"
 subject="""comment 1"""
 date="2017-12-21T19:44:45Z"
 content="""
Reproduced it with that information.

	ghci> calcPartedParamsSize guexPartTable
	(["mklabel","gpt","mkpart","primary","fat32","4194304B","16777215B","set","1","esp","on","mkpart","primary","ext2","16777216B","167772159B","mkpart","primary","ext4","167772160B","1660944383B"],1660944384)
	joey@darkstar:~>dd if=/dev/zero of=test bs=1M count=1584
	joey@darkstar:~>parted test
	(parted) p
	Model:  (file)
	Disk /home/joey/test: 1661MB
	Sector size (logical/physical): 512B/512B
	(parted) mklabel gpt
	(parted) mkpart primary fat32 4194304B 16777215B
	(parted) mkpart primary ext2 16777216B 167772159B
	(parted) mkpart primary ext4 167772160B 1660944383B
	Warning: You requested a partition from 168MB to 1661MB (sectors 327680..3244031).
	The closest location we can manage is 168MB to 1661MB (sectors 327680..3243998).

The problem only occurs with the gpt partition table. With "mklabel msdos",
the mkpart command succeeds. 

So, gpt must have an additional restriction
of some kind. I don't know what. The highest end position that parted
will accept for that partition is 1660927487B; slightly smaller partitions
are accepted. It's not a requirement that the position or size be divisible
by anything in particular. Perhaps gpt needs some amount of reserved space
at the end of the disk or something.

Before 4MiB alignment was added, here's what 
propellor did for the same PartTable, which worked.

	mkpart primary ext4 160MB 1649MB

It would be good for propellor to not need to know about all the minutia of
partition tables. Seems that the way it used to call parted gave it enough
wiggle room that it avoided this kind of problem.
	
To make parititions well aligned, propellor needs to precisely control where
they begin (since parted does not have a way to configure modern 
alignment requirments). Perhaps propellor could precisely specify where a
partition begins, but use the "MB" to leave wiggle room in where it ends
so parted can pick a suitable end point.

Let's see.. this works with the gpt example:

	(parted) mkpart primary fat32 4194304B 16.777215MB
	(parted) mkpart primary ext2 16777216B 167.772159MB
	(parted) mkpart primary ext4 167772160B 1660.944383MB

That lets parted end the last partition right at the ideal 1660927487B.
The previous two partitions end right where propellor expects.
(Hopefully parted never rounds a MB value *up*!)

Ok, I've convinced myself to make propellor use this wacky technique
of B for the start position and fractional MB for the end position!
I've implemented it, hopefully my analysis above is good to make
this work with all the different kinds of partition tables.
"""]]