Your message dated Fri, 22 Jun 2012 23:06:07 +0200
with message-id <[email protected]>
and subject line already fixed
has caused the Debian Bug report #661730,
regarding fai-setup-storage: bios_grub {size}->{range} appears incorrect
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
661730: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661730
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: fai-setup-storage
Version: 3.4.8
Severity: normal
Tags: patch
hello -
when trying to use a gpt-bios disklabel on a 3tb drive a 0-100%
allocation uses much less than the whole disk. i'm running fai
3.4.8; i also upgraded (just) the fai-setup-storage pkg in the live
nfsroot to 4.0~beta3 +experimental7 (setup-storage 1.3+exp) but saw
the same result.
excerpt from disk_config:
disk_config sda disklabel:gpt-bios align-at:4K
primary - 0-100% - -
excerpt from the format.log:
Executing: parted -s /dev/sda mklabel gpt
Executing: parted -s /dev/sda mkpart primary "" 1069056B 1901081333759B
Executing: parted -s /dev/sda mkpart primary "" 17408B 1065983B
it identifies the disk and its size correctly (3000592961535B per
`setup-storage -d`).
when i started poking around Sizes.pm, it looks like the values in
$FAI::partition_pointer->{size}->{range} for the bios_grub partition are
run through the make_range function twice. the first time is in
compute_partition_sizes where the range of "1-1" is converted from bytes
to megabytes. the second time is in do_partition_real. so the range
that goes in this second time is (1 * 1024 * 1024) and the min_size
variable that comes out is (1 * 1024 * 1024 * 1024 * 1024) =
1099511627776B. and 3000592961535B - 1099511627776B = 1901081333759B,
which is what i was seeing above.
a workaround appears to be the attaached one-line patch to keep the
range in megabytes.
i didn't notice any adverse effects and the installation completed as
expected.
thank you!
andy
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages fai-setup-storage depends on:
ii liblinux-lvm-perl 0.16-1
ii libparse-recdescent-perl 1.967006+dfsg-1
ii parted 2.3-8
ii perl 5.12.4-6
Versions of packages fai-setup-storage recommends:
ii lvm2 2.02.88-1
ii mdadm 3.2.3-2
Versions of packages fai-setup-storage suggests:
pn cryptsetup 2:1.3.0-3
pn dmsetup 2:1.02.67-1
pn dosfstools 3.0.12-1
pn jfsutils <none>
pn ntfs-3g [ntfsprogs] 1:2011.4.12AR.7-1
pn reiserfsprogs <none>
pn xfsprogs <none>
-- no debconf information
--- ./Sizes.pm.orig 2012-02-23 18:37:03.388348728 -0800
+++ ./Sizes.pm 2012-02-23 18:36:49.028344316 -0800
@@ -651,7 +651,7 @@
(&FAI::phys_dev($FAI::partition_pointer_dev_name))[2];
my ($s, $e) = &FAI::make_range("1-1", $current_disk->{size} . "B");
# enter the range into the hash
- $FAI::partition_pointer->{size}->{range} = "$s-$s";
+ $FAI::partition_pointer->{size}->{range} = "1-1";
# retain the free space at the beginning and fix the position
$FAI::partition_pointer->{start_byte} = $next_start;
$FAI::partition_pointer->{end_byte} = $next_start + $s - 1;
--- End Message ---
--- Begin Message ---
This bug was already fixed in FAI 4.0
--
regards Thomas
--- End Message ---
