Michael Shuler wrote:
On 03/03/2010 05:11 PM, Christopher Moules wrote:
On 03/03/2010 08:46 AM, Chris Moules wrote:
I have been installing from the Debian Lenny amd64 DVD (5.0.4) and
Debian Squeeze (1st March 2010).
I just installed squeeze via PXE from the current netboot image
(20100211) - same controller and disk setup.
parted /dev/sda
GNU Parted 1.8.8.git-dirty
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Warning: Not all of the space available to /dev/sda appears to be
used, you can fix the GPT to use all of the space (an extra
3906207744 blocks) or continue
with the current setting?
Fix/Ignore? Fix
Model: AMCC 9650SE-8LP DISK (scsi)
Disk /dev/sda: 6000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17.4kB 256MB 256MB ext2 boot boot
2 256MB 4000GB 4000GB lvm
r...@debian:~# parted /dev/sda print
Model: AMCC 9650SE-8LP DISK (scsi)
Disk /dev/sda: 6000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17.4kB 256MB 256MB ext3
2 256MB 6000GB 6000GB lvm
r...@debian:~# parted -v
parted (GNU parted) 1.8.8.git-dirty
This was with manual partitioning selected. This result came before even
selecting a filesystem. I had ~6TB of space on the disk, selected "Free
Space" and chose 100% of this for the new partition. partman
auto-selected 'ext3' as filesystem type which I changed to 'device for
LVM' and chose 'done'. This then listed the second partition as ~4TB and
left 2TB as 'Free Space'. Any attempt to use these final 2TB produced an
error (I do not have the exact text).
I ran through the same steps with no errors - it did what I asked.
I do not believe that this has the slightest to do with a filesystem as
this was not at that point. Also the failure to use the remaining 2TB
space seems to indicate this. Finally the output from parted (in initial
post - above) shows the warning and the option to 'fix' the GPT created
by the partman installer partitioner.
Yeah, doesn't seem like filesystem.
You might wish to add DEBCONF_DEBUG=5 to the installer boot args and dig
around the installer logs. I pushed the debug syslog and partman logs
from the install I just did, in case you or anyone wants to compare :)
http://www.pbandjelly.org/tmp/squeeze_amd64_d-i_lvm_debug_syslog.txt
http://www.pbandjelly.org/tmp/squeeze_amd64_d-i_lvm_debug_partman.txt
Hope that helps a bit.
OK, I have done a reinstall this morning and managed to resolve the issue.
Before running the Debian Lenny installer, I booted to a rescue console and
did a "dd if=/dev/zero of=/dev/sda bs=1MB count=250" to erase the first part
of the disk. After this, everything seemed to run OK. I was able to use the
full 6TB.
The cause of the initial problem:
I have previously been testing the array in a RAID 10. This is then 4TB of
space. I believe that the previous GPT partition table was read and some
constraints of this were used.
One question remains, which is 'is there a bug'? If the system is picking up
'old' configuration data that does not fit to the current environment is this
correct? Should the system propose to generate a new partition table? Even
with the above 'dd' after I created the same 256MB boot partition and setup a
new LVM partition, the LVM manager picked up the 'existing' LVM config on disk
even though there was a new partition table etc.
I can see the advantages of the system automatically using existing data that it
finds, however I am not able to perform a 'clean' setup if partman finds
anything
on the disk that matches some previous configuration.
I guess that there is no 4TB bug and that this was simply to do with a re-usage
of
the old GPT that was limited to 4TB.
Thanks for your input and time.
Regards
Chris
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b8f84b5.2060...@gms.lu
