[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian installer with RAID of 6TB



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

root@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

root@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


Reply to: