| Summary: | diskdrake skips 2048k between each partition in KVM guest | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | AL13N <alien> |
| Component: | RPM Packages | Assignee: | Thierry Vignaud <thierry.vignaud> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | davidwhodgins, stormi-mageia |
| Version: | 2 | Keywords: | Triaged |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | drakxtools-14.21-1.mga2.src.rpm | CVE: | |
| Status comment: | |||
|
Description
AL13N
2012-05-25 11:18:23 CEST
Please attach the output of sfdisk -l -uS -x /dev/vda >sfdisk.txt Also, are you using diskdrake in normal or expert mode? CC:
(none) =>
davidwhodgins normal
[root@builder ~]# sfdisk -l -uS -x /dev/vda
Disk /dev/vda: 83220 cylinders, 16 heads, 63 sectors/track
sfdisk: Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System
/dev/vda1 * 2048 236879 234832 83 Linux
/dev/vda2 239589 83885759 83646171 5 Extended
/dev/vda3 0 - 0 0 Empty
/dev/vda4 0 - 0 0 Empty
/dev/vda5 239616 8743391 8503776 82 Linux swap / Solaris
- 8744960 83885759 75140800 5 Extended
- 239589 239588 0 0 Empty
- 239589 239588 0 0 Empty
/dev/vda6 8747008 83885759 75138752 83 Linux
- 8744960 8744959 0 0 Empty
- 8744960 8744959 0 0 Empty
- 8744960 8744959 0 0 Empty
The program diskdrake, like gparted and most partitioning tools have been changed to align partitions on 1 MB boundaries, by default, to avoid partition alignment problems on devices like advanced format, ssd and flash drives, so there should be gaps, as 2048 sectors are reserved for the mbr+bootloader at the start of the drive, and each extended partition will reserve 2048 sectors for the partition table for that part of the extended partition table chain. However, even given that, the numbers do not look correct to me. As diskdrake is being run in normal mode, all of the sector start and number of sectors should be multiples of 2048. The vda1 partition starts at 1 MB into the drive, as expected. The vda1 partition has a size of 114.6640625 MB. The vda2 partition (the partition table associated with vda5) starts at 116.986816406 MB The vda5 partition starts at 117 MB. The extended partition table associated with vda6 starts at 4,270 MB. The vda6 partition starts at 4,271 MB. So all of the actual filesystem partitions are correctly aligned on 1 MB boundaries, I'm surprised that the first partition is not an even number of megabytes, and the extended partition is not aligned on a MB boundary. I don't consider this a bug, as all filesystem partitions are being correctly aligned on 2048 sector boundaries, but I would like to have the maintainer explain why diskdrake is setting the size of the first partition and the start of the extended partition such that they are not multiples of 2048 sectors. Source RPM:
diskdrake =>
drakxtools-14.21-1.mga2.src.rpm i know it's been changed, but i think this was because of 1k sized sectors and cylinder boundaries. besides which, the other partitions are more than 1M in between. (3710 sectors and 4000+ sectors) normally, the first partition starts (exceptionally) at 63 sectors (head 1 instead of head 0). in any case, diskdrake shows clickable spaces before each partition, which is definately a bug. also the partitions should be filled to end on the same boundary after all. so, i see definately some bugs, in whatever way you look at it. Assigning to maintainer. Is that bug also true in Mageia 3 and Cauldron? Keywords:
(none) =>
Triaged This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad Status:
NEW =>
RESOLVED |