I could be misunderstanding the problem here, I think we've had trouble
with the 32/63 thing in other respects too, such as getting corrupted
disk images when someone uses something other than parted (or uses
parted but doesn't change the sector size) to resize the partitions.
Would it be worth
I could be misunderstanding the problem here, I think we've had trouble
with the 32/63 thing in other respects too, such as getting corrupted
disk images when someone uses something other than parted (or uses
parted but doesn't change the sector size) to resize the partitions.
Would it be worth
Actually the first partition's start value of 63s is hardcoded into the
script.
Therefore it's easy to change:
Edit /usr/share/pyshared/VMBuilder/disk.py
In line 299, change
partition_start = 63s
to
partition_start = 2048s
--
You received this bug notification because you are a member of
Actually the first partition's start value of 63s is hardcoded into the
script.
Therefore it's easy to change:
Edit /usr/share/pyshared/VMBuilder/disk.py
In line 299, change
partition_start = 63s
to
partition_start = 2048s
--
You received this bug notification because you are a member of
Hi! Two years later this bug continues. What is finally the right
solution. Pendrives partitioned with parted are impossible to use to
install on it linux distributions. GRUB2 don't find free space enough
because grub2 tries to be installed on the first track, but the first
track have only 32
Hi! Two years later this bug continues. What is finally the right
solution. Pendrives partitioned with parted are impossible to use to
install on it linux distributions. GRUB2 don't find free space enough
because grub2 tries to be installed on the first track, but the first
track have only 32
Hm, I don't agree. I think the problem is in libparted/arch/linux.c
init_file():
dev-bios_geom.sectors = 32;
vs _device_probe_geometry() which defaults to what the LBA reports or:
dev-bios_geom.sectors = 63;
So, when vmbuilder uses parted to build the disk, parted treats the
The bios geometry just shouldn't matter. Sure, it is odd that it uses a
different geometry for an image file than a disk, but whether the
nonsensical geometry specifies 63 or 32 or 3 sectors per track,
partitions are supposed to have a 1mb alignment these days. This is
what you get if you
Hm, I don't agree. I think the problem is in libparted/arch/linux.c
init_file():
dev-bios_geom.sectors = 32;
vs _device_probe_geometry() which defaults to what the LBA reports or:
dev-bios_geom.sectors = 63;
So, when vmbuilder uses parted to build the disk, parted treats the
The bios geometry just shouldn't matter. Sure, it is odd that it uses a
different geometry for an image file than a disk, but whether the
nonsensical geometry specifies 63 or 32 or 3 sectors per track,
partitions are supposed to have a 1mb alignment these days. This is
what you get if you
Ok, I think I see the problem in parted. I assume that vmbuilder uses
the output of parted's print free command to decide where to start the
new partition, and that shows the free space starts at 16.4kb.
Specifying that as the start position for the new partition would result
in the too small
Ok, I think I see the problem in parted. I assume that vmbuilder uses
the output of parted's print free command to decide where to start the
new partition, and that shows the free space starts at 16.4kb.
Specifying that as the start position for the new partition would result
in the too small
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: parted (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to vm-builder in Ubuntu.
Parted defaults to leaving the first 1 MB of the disk empty these days,
regardless of the cylinder size. I just tested it by creating a 1 gb
file and having parted mklabel msdos, then mkpart using 0% and 100% as
the start and end positions, and the partition starts at sector 2048
even though the
The problem is that parted treats local files (as used by vmbuilder)
differently from actual disk files, and changes the sector size
accordingly (without an option to change it). As a result, the partition
start locations are too small for grub2 to install. I had originally
reproduced this by
Parted defaults to leaving the first 1 MB of the disk empty these days,
regardless of the cylinder size. I just tested it by creating a 1 gb
file and having parted mklabel msdos, then mkpart using 0% and 100% as
the start and end positions, and the partition starts at sector 2048
even though the
The problem is that parted treats local files (as used by vmbuilder)
differently from actual disk files, and changes the sector size
accordingly (without an option to change it). As a result, the partition
start locations are too small for grub2 to install. I had originally
reproduced this by
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: parted (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/556167
Title:
** Also affects: parted (Ubuntu)
Importance: Undecided
Status: New
--
vmbuilder uses parted to create disk images, which leads to broken sector
counts (cannot use grub2 on disk images created by vmbuilder/parted)
https://bugs.launchpad.net/bugs/556167
You received this bug
Incorrect but functional hack attached...
** Patch added: embedding-area-hack.patch
http://launchpadlibrarian.net/43294626/embedding-area-hack.patch
--
vmbuilder uses parted to create disk images, which leads to broken sector
counts (cannot use grub2 on disk images created by
Incorrect but functional hack attached...
** Patch added: embedding-area-hack.patch
http://launchpadlibrarian.net/43294626/embedding-area-hack.patch
--
vmbuilder uses parted to create disk images, which leads to broken sector
counts (cannot use grub2 on disk images created by
** Also affects: parted (Ubuntu)
Importance: Undecided
Status: New
--
vmbuilder uses parted to create disk images, which leads to broken sector
counts (cannot use grub2 on disk images created by vmbuilder/parted)
https://bugs.launchpad.net/bugs/556167
You received this bug
I get this also.
** Changed in: vm-builder (Ubuntu)
Status: New = Confirmed
** Changed in: vm-builder (Ubuntu)
Importance: Undecided = Medium
--
vmbuilder uses parted to create disk images, which leads to broken sector
counts (cannot use grub2 on disk images created by
I get this also.
** Changed in: vm-builder (Ubuntu)
Status: New = Confirmed
** Changed in: vm-builder (Ubuntu)
Importance: Undecided = Medium
--
vmbuilder uses parted to create disk images, which leads to broken sector
counts (cannot use grub2 on disk images created by
24 matches
Mail list logo
