> > OK , thank you very much for the explanation. Since I don't use > > raspberry Pi among my targets, do you think I can safely run a custom > > parted with a revert of 61dd3d4c5eb782eb43caa95342e63727db3f8281 ?
> That's probably fine, as long as you know what you are doing ;) Ok I'll go this way, thanks. > > OK I understand, since you close the present bug, do you know where I > > can have your conclusion when you'll have time to look at it ? > > > > Thanks again for the quick answer by the way. > I'm *hoping* to get a new parted release ready sometime soon, but I'm > not yet sure when. I have a few other things to review and I'll take a > look at this at the same time to make sure it's not a bug. Fine, I'll keep a look to the parted release then ;) By the way, I come up with a patch (joined) which is a mix of revert 61dd3d4c5eb782eb43caa95342e63727db3f8281 and taken into account 52360db2f5397b7842d2ed90bf946c5e8fa91750 (which mention some kind of regression too): Have a nice day On Thu, 26 Jan 2023 at 19:50, Brian C. Lane <b...@redhat.com> wrote: > > On Thu, Jan 26, 2023 at 05:39:24PM +0100, Frédéric Martinsons wrote: > > > This change was introduced by commit > > > 61dd3d4c5eb782eb43caa95342e63727db3f8281, it was needed to fix problems > > > growing partitions when using SD cards on the Raspberry Pi. > > > > OK , thank you very much for the explanation. Since I don't use > > raspberry Pi among my targets, do you think I can safely run a custom > > parted with a revert of 61dd3d4c5eb782eb43caa95342e63727db3f8281 ? > > That's probably fine, as long as you know what you are doing ;) > > > > > > Well, nothing should be actually using the CHS values these days. So > > > it's possible that's a bug that doesn't matter in practice, but I'll > > > have to look into that. > > > > OK I understand, since you close the present bug, do you know where I > > can have your conclusion when you'll have time to look at it ? > > > > Thanks again for the quick answer by the way. > > I'm *hoping* to get a new parted release ready sometime soon, but I'm > not yet sure when. I have a few other things to review and I'll take a > look at this at the same time to make sure it's not a bug. > > Brian > > -- > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart >
From 00851f9b5c049d18a6d49d69ec2d5d13544f5616 Mon Sep 17 00:00:00 2001 From: Frederic Martinsons <frederic.martins...@gmail.com> Date: Fri, 27 Jan 2023 06:38:15 +0100 Subject: [PATCH] Get back the old way of getting device geometry info This is a mix between a revert of 61dd3d4c5eb782eb43caa95342e63727db3f8281 and an adaptation for 52360db2f5397b7842d2ed90bf946c5e8fa91750 See more info at https://lists.gnu.org/archive/html/bug-parted/2023-01/msg00002.html Signed-off-by: Frederic Martinsons <frederic.martins...@gmail.com> --- libparted/arch/linux.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/libparted/arch/linux.c b/libparted/arch/linux.c index 09ec781..e337aae 100644 --- a/libparted/arch/linux.c +++ b/libparted/arch/linux.c @@ -868,7 +868,6 @@ _device_probe_geometry (PedDevice* dev) struct stat dev_stat; struct hd_geometry geometry; int geometry_is_valid = 0; - int sector_size = 0; if (!_device_stat (dev, &dev_stat)) return 0; @@ -888,16 +887,7 @@ _device_probe_geometry (PedDevice* dev) geometry_is_valid = !ioctl (arch_specific->fd, HDIO_GETGEO, &geometry) && geometry.sectors && geometry.heads; -#if defined __s390__ || defined __s390x__ if (geometry_is_valid) { -#else - if (!ioctl (arch_specific->fd, BLKSSZGET, §or_size)) { - /* get the sector count first */ - dev->bios_geom.sectors = 1 + (sector_size / PED_SECTOR_SIZE_DEFAULT); - dev->bios_geom.heads = 255; - } else if (geometry_is_valid) { - /* if BLKSSZGET failed, use deprecated HDIO_GETGEO result */ -#endif dev->bios_geom.sectors = geometry.sectors; dev->bios_geom.heads = geometry.heads; } else { -- 2.34.1
