LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   4TB drives and GPT (http://www.linuxquestions.org/questions/slackware-14/4tb-drives-and-gpt-4175412537/)

fskmh 06-20-2012 03:30 PM

4TB drives and GPT
 
I was just checking out this nice piece of kit and it appears that partitions > 2.2TB require a GUID partition table (GPT). It also seems that GPT fdisk (gdisk) would then be the logical tool to create such a partition table. Not sure if GPT is required for bootable and data-only partitions, but it looks like it is.

Can anyone who has direct experience with this confirm/dispute?

qlue 06-21-2012 05:01 AM

From Wikipedia;
"Some distribution tools, such as fdisk, don't work with GPT. New tools such as gdisk, GNU Parted, Syslinux, grub .96+ patches and grub2 have been GPT-enabled."
This is not an issue really. (or rather, it's a solved legacy issue)

fskmh 06-21-2012 06:58 AM

Thanks for your reply. I was, however, asking for someone with *direct experience* to provide clarification. Also, since this is a Slackware-specific subforum, there is the implied context of tools that are available to manage GPT in this distro, not some arbitrary Wikipedia realm of the theoretically possible.

Mark Pettit 06-21-2012 07:13 AM

I have created a file system on a 16 x 2 TB disk system. I setup a raid 10 across 14 disks with 2 being hot spares. That was done using the (proprietary) features of the raid card. I was then presented with what looked like a single (approx) 14 TB drive. I HAD to use parted/gparted to create the file system. fdisk would not cut it. I've not heard of gdisk. BTW - the performance was incredible - the card had some sort of 6 gigabit interface, and I could read or write at 600 Megabytes per second. Really cool :-)

syg00 06-21-2012 07:53 AM

For some non-SA input ...

The important (for MBR vs. gpt) point is the size of the partitions. If you keep them all less than 2 TB (give-or-take), MBR is fine. However, gpt is the way of the future.
But from a Slack perspective I have no idea if lilo supports gpt. There are issues with the blocklist as it can't write to the initial sectors on the disk on gpt (it's a non-writeable dummy MBR look-alike). Grub2 has been written to accommodate this, but it requires some setup be done correctly. But as for lilo, who knows.

AlleyTrotter 06-21-2012 09:23 AM

gdisk
 
I can tell you, yes gdisk, which is the GUID equivalent of fdisk is included by default in slackware 13.37.
I used a gdisk partition on my second drive, but not on the boot drive. gdisk would not allow a fdos partition as the first partition on the first drive ( the boot drive). I use lilo to boot.
not much but maybe it is useful to you.
john

fskmh 06-21-2012 10:00 AM

Thanks guys. I'm going to have to RAID some 2TB drives together like Mark did so I can play with this.

ruario 06-21-2012 10:19 AM

Quote:

Originally Posted by syg00 (Post 4708509)
But from a Slack perspective I have no idea if lilo supports gpt. There are issues with the blocklist as it can't write to the initial sectors on the disk on gpt (it's a non-writeable dummy MBR look-alike). Grub2 has been written to accommodate this, but it requires some setup be done correctly. But as for lilo, who knows.

There are some notes on using Grub2 with GPT here:

http://slackwiki.com/Dual_Booting_With_FreeBSD_9

Yes the page is primarily about dual booting with FreeBSD but you can just ignore that part.

Edit: With regards to getting system up before you install Grub2 from SlackBuilds, just skip the lilo section in the Slackware installer and on reboot use the Slackware CD/DVD to boot the huge SMP kernel, e.g at the "boot:" prompt type something like this (I assume /dev/sda1 is your / partition, adjust accordingly):
Code:

hugesmp.s root=/dev/sda1 rdinit= ro
I am pretty sure this should work because lilo is reading the kernel from the CD/DVD and this isn't GPT. Though I must admit I have not actually tested it.

Alternatively if I am wrong, I can think of at least one other way. Fully boot the Slackware CD/DVD, mount your disk and chroot into your Slackware install (again assuming that /dev/sda1 is your / partition):

Code:

mkdir /gptslack
mount /dev/sda1 /gptslack
mount --bind /proc /gptslack/proc
mount --bind /sys /gptslack/sys
mount --bind /dev /gptslack/dev
chroot /gptslack

Note: You might need to manually mount a few more things if you have other partitions!

Now that you have your installed system up and running you can fetch Grub2 from SlackBuilds.org and configure as per the wiki page.

ruario 06-23-2012 05:49 PM

As I have never actually used a GPT with Slackware, I thought I would give it a quick test just now. All in all, it was pretty straightforward but I did notice a few things that could catch people out.

Firstly the install script didn't seem to find my swap partition, so I had to 'mkswap [device id]' and then add an entry manually to /etc/fstab after install.

Secondly as I was using BIOS rather than UEFI I had to make a "BIOS boot partition" (partition type EF02 in gdisk). Apparently it can be as small as 30 KiB but the general advice on most websites I looked at seems to be that you should make 1 MiB because future boot loaders might require more space and many modern disk partitioning tools have 1 MiB partition alignment policies. Apparently it doesn't matter where on disk it is but I tried it as the first partition and this worked nicely for me.

During install I skipped the lilo setup step for obvious reasons. On reboot I used the CD to boot my new system as outlined in the edit to my previous post. Then I setup an initrd for use with the generic kernel as per the regular guidelines. This is where I hit the third minor issue. It seems that a little messing around is required to get grub2 to find your initrd.gz file. grub-mkconfig reads configuration scripts in '/etc/grub.d/' and one of these files ('10_linux') expects certain naming for initrd files (presumably based on how other distros name them). You can either adjust '/etc/grub.d/10_linux' directly and tell it to look for initrd.gz in addition to the other naming formats or just rename your initrd.gz to one of the names it expects. Several naming formats are supported, e.g. initrd-kernel-release. So if you were using 32Bit Slackware 13.37 with vmlinuz-generic-smp-2.6.37.6-smp then you could issue the following:

Code:

# mv /boot/initrd.gz /boot/initrd-2.6.37.6-smp
Once you have either tweaked /etc/grub.d/10_linux or given your initrd a new name, you can run the following commands:

Code:

# grub-install --modules=part_gpt /dev/sda
# grub-mkconfig -o /boot/grub/grub.cfg

This should detect your kernel and initrd and put it in the grub menu. All you need do now is reboot and you should have your GPT based system configured! ;)

ruario 06-25-2012 04:34 PM

Quote:

Originally Posted by ruario (Post 4710282)
Firstly the install script didn't seem to find my swap partition, so I had to 'mkswap [device id]' and then add an entry manually to /etc/fstab after install.

Hmm, I did another test. It seems that the install script does find the swap partition as long as you 'mkswap [device id]' before you start the install script!

fskmh 06-26-2012 09:19 AM

Your feedback is appreciated ruario, as are your efforts with the Opera browser.

ruario 06-27-2012 09:08 AM

Booting GPT disks with Extlinux
 
@fskmh: No problem. I quite enjoyed playing around with this as it gives me good preparation for the future. I'm bound to buy a suitably big disk one day. ;)

Anyway, I have yet another update. I recently realised that the Extlinux bootloader available with Slackware -current (part of the Syslinux package) is capable of booting ext2/ext3/ext4/btrfs GPT partitions (when a BIOS is used, though sadly not with EFI). Personally I think this is still preferable to Grub2 (unless you have an EFI system) as it avoids having to install an extra boot loader and its various dependencies.

I used the official Extlinux page along with the Arch Linux Wiki page on Syslinux as sources of information on how to setup Extlinux, needing to adapt the information only very slightly for Slackware (e.g. some differences in paths). I thought I would once again outline what I found in case it is useful to others.

First off, my test system (actually a VM under VirtualBOX) was slackware-current (32bit) with the disk partitioned as follows:

Code:

Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 8590MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start  End    Size    File system    Name                Flags
 1      1049kB  7517MB  7516MB  ext4            Linux/Windows data
 2      7517MB  8589MB  1072MB  linux-swap(v1)  Linux swap
 3      8589MB  8590MB  1032kB                  BIOS boot partition  bios_grub

Note: Extlinux doesn't actually need the "BIOS boot partition". My understanding is that the bootloaders have a slight size problem when installing on GPT systems under BIOS, due to the lack of post-MBR embed gap on GPT disks. Grub2 works around this by having the first stage of its bootloader look for a "BIOS boot partition" where it stores a second, bigger file. This second stage file includes support for a large set of filesystems. Extlinux however has a different solution. Since it supports fewer filesystems, its first stage is still small enough to include ext2+/btrfs support. It can therefore have the second stage on the /boot partition directly. Of course it still need to know which partition is the /boot partition and this is done by marking it with a special attribute.

Anyway, I set this attribute with sgdisk (provided by the gdisk package) as follows:

Code:

# sgdisk /dev/sda --attributes=1:set:2
I then used sgdisk to confirm it was indeed set correctly, i.e.:

Code:

# sgdisk /dev/sda --attributes=1:show
1:2:1 (legacy BIOS bootable)

With that out of the way I installed extlinux as follows:

Code:

# mkdir -p /boot/extlinux
# extlinux --install /boot/extlinux
# cat /usr/share/syslinux/gptmbr.bin > /dev/sda

Since I wanted a boot menu, I copied menu.c32 over into the extlinux boot directory as well:

Code:

# cp /usr/share/syslinux/menu.c32 /boot/extlinux/
I then created a /boot/extlinux/extlinux.conf file that looked like this:

Code:

UI menu.c32
PROMPT 0
MENU TITLE Boot options
TIMEOUT 50
DEFAULT generic

LABEL generic
      MENU LABEL Slackware (vmlinuz-generic-smp-3.2.21-smp)
      KERNEL /boot/vmlinuz-generic-smp-3.2.21-smp
      APPEND root=/dev/sda1 ro
      INITRD /boot/initrd.gz

LABEL huge
      MENU LABEL Slackware (vmlinuz-huge-smp-3.2.21-smp)
      KERNEL /boot/vmlinuz-huge-smp-3.2.21-smp
      APPEND root=/dev/sda1 ro

This worked just fine for booting the huge kernel. However, when I attempted to load the generic kernel, booting halted with the following message:

Code:

/boot/initrd.gz:  Loading kernel modules from initrd image:
mount: can't find /mnt in /etc/fstab
ERROR:        No /sbin/init found on rootdev (or not mounted).  Trouble ahead.
        You can try to fix it. Type 'exit' when things are done.

/bin/sh: can't access tty; job control turned off
/ # _

I realised that I could get past this point and continue with booting if I manually did the following:

Code:

/ # mount -o ro /dev/sda1 /mnt
/ # exit

However, this it is not very convenient to have to do this every time, so after booting I did the following:

Code:

echo "/dev/sda1        /mnt            ext4        ro              1  1" >> /boot/initrd-tree/etc/fstab
mkinitrd

I'm not sure if this is the optimal way to fix the issue but it did work because the updated /etc/fstab within my new initrd.gz allows the mount command to find /dev/sda1 by itself. If anyone knows of a better way to do this, I would certainly be interested to hear about it.

ruario 06-27-2012 09:54 AM

Ok, I worked out the problem with my initrd and how to fix it the correct way. Previously I created the initrd with the following command:

Code:

mkinitrd -c -k 3.2.21-smp -m ext4
which are the options I would have used on an MBR partioned disk when using lilo. However, a quick read of 'man mkinitrd' gave me the idea to try specifying -f and -r as well, like this:

Code:

mkinitrd -c -k 3.2.21-smp -m ext4 -f ext4 -r /dev/sda1
This feels a little redundant given the simplicity of my partition setup but hey it worked. Presumably the "magic" that usually allows you to leave out the -f and -r options, doesn't work with GPT partitioned disks.

Edit: Now that this is all working I decided to switch to a simpler /boot/extlinux/extlinux.conf

Code:

PROMPT 0
TIMEOUT 0
DEFAULT generic
LABEL generic
      KERNEL /boot/vmlinuz-generic-smp-3.2.21-smp
      APPEND root=/dev/sda1 ro
      INITRD /boot/initrd.gz



All times are GMT -5. The time now is 11:19 AM.