[SOLVED] Feb. 16 Slackware64-current iso will not recognize GPT

ryanpcmcquen · 02-17-2015, 08:54 AM

I'm using Eric's automatically generated ISO to install the sweet new February 16 Slackware64-current (glibc 2.21!). The problem is it won't recognize a GPT table, only MBR. I've never run into this issue before in the 500 or so times I've installed Slackware.

The message I get when entering setup is:

Code:

NO LINUX PARTITIONS DETECTED
There don't seem to be any partitions on this machine of type Linux.
...

Yet:

Code:

# gdisk -l /dev/sda

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Number  Start (sector)   End (sector)  Size      Code  Name
   1            2048     1953523711   931.5 GiB  8300  primary

Obviously I have condensed the output a little to save typing, but the partitioning is valid right?

I tried using both parted and gdisk to set up one big partition using GPT (w/ protective MBR), I even tried setting up the partitioning, formatting the big partition as ext4 (mkfs.ext4), and then rebooting, but am still receiving the same error.

This has never been an issue before (installing with the January 28 ISO did not have this problem, or any ISO I've installed back to 13.37).

P.S. MBR is recognized instantly.

Thanks for the help,

Ryan

AlleyTrotter · 02-17-2015, 09:30 AM

Confirmed
No help here, but I have the identical problem entering setup
John

ryanpcmcquen · 02-17-2015, 02:14 PM

I did a search through here, but I can't imagine what would be causing this. The only kernel change is related to APIC stuff, and the sysvinit changes just affect output.

http://cgit.notk.org/adrien/slackwar...721e217943a7e2

rworkman · 02-17-2015, 02:31 PM

Almost surely due to changes in util-linux. I've not looked at the installer, but perhaps it screen-scrapes something to determine presence of linux partitions, and util-linux changed the output format of that something. That's a place to start looking anyway...

Didier Spaier · 02-17-2015, 02:44 PM

All I know is that the script /sbin/probe (attached) in the initrd that makes the checks in Slackware64-14.1 and Slackware64-current is identical.

Here is the code snippet from /usr/lib/setup/setup that calls it (also unchanged):

Code:

# Before probing, activate any LVM partitions
# that may exist from before the boot:
vgchange -ay 1> /dev/null 2> /dev/null
if probe -l 2> /dev/null | grep -E 'Linux$' 1> /dev/null 2> /dev/null ; then
 probe -l 2> /dev/null | grep -E 'Linux$' | sort 1> $TMP/SeTplist 2> /dev/null
else
 dialog --title "NO LINUX PARTITIONS DETECTED" \
 --msgbox "There don't seem to be any partitions on this machine of type \
Linux.  You'll need to make at least one of these to install Linux.  \
To do this, you'll need to leave 'setup', and make the partitions using \
'cfdisk' (MBR partitions) or 'cgdisk' (GPT partitions).  For more \
information, read the 'setup' help file from the next menu." 10 64

I didn't investigate further.

ryanpcmcquen · 02-17-2015, 03:56 PM

Quote:

Originally Posted by Didier Spaier

Code:

if probe -l 2> /dev/null | grep -E 'Linux$' 1> /dev/null 2> /dev/null ; then
 probe -l 2> /dev/null | grep -E 'Linux$' | sort 1> $TMP/SeTplist 2> /dev/null
else

This gave me a good start. I'm not sure why, but removing the '$' from 'Linux$' in the if check fixes the issue. I tested it against having an 8300 type partition and a bf04 (I just wanted something that was definitely not 8300).

bf04:
http://s11.postimg.org/bxrmcfegz/Scr...1_52_41_PM.png

8300:
http://s27.postimg.org/a465j43xv/Scr...1_53_02_PM.png

Could this actually be due to a change in grep?

ryanpcmcquen · 02-17-2015, 03:59 PM

And removing the dollar sign from both instances in that if loop allows the installer to recognize the partition correctly:

http://s3.postimg.org/5stlz2vg3/Scre...1_58_17_PM.png

ryanpcmcquen · 02-17-2015, 04:15 PM

This actually makes sense now.

`probe` outputs 'Linux filesystem' for gpt, and 'Linux' for mbr. Ergo, the if loop will not work for gpt anymore. I'll email Pat. :-)

ryanpcmcquen · 02-17-2015, 04:23 PM

Here is what I sent to Pat:

Code:

if probe -l 2> /dev/null | grep -E 'Linux$' 1> /dev/null 2> /dev/null ; then
 probe -l 2> /dev/null | grep -E 'Linux$' | sort 1> $TMP/SeTplist 2> /dev/null
elif probe -l 2> /dev/null | grep 'Linux filesystem' 1> /dev/null 2> /dev/null ; then
 probe -l 2> /dev/null | grep 'Linux filesystem' | sort 1> $TMP/SeTplist 2> /dev/null
else

turtleli · 02-17-2015, 04:39 PM

The behaviour seems to be related to fdisk in util-linux, which recognises GPT partitions now.

On my Slackware64-current UEFI VM:

Code:

#fdisk -l /dev/vda
Disk /dev/vda: 40 GiB, 42949672960 bytes, 83886080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: AFA5B226-49B2-4E4C-ACDB-08DDFCBCE328

Device       Start      End  Sectors  Size Type
/dev/vda1     2048   264191   262144  128M EFI System
/dev/vda2   264192  4458495  4194304    2G Linux swap
/dev/vda3  4458496 83886046 79427551 37.9G Linux filesystem

and on Slackware64-14.1:

Code:

#fdisk -l /dev/sda
WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 256.1 GB, 256060514304 bytes
256 heads, 63 sectors/track, 31009 cylinders, total 500118192 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xad706dab

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1  4294967295  2147483647+  ee  GPT

So the GPT device test in probe actually fails, since it looks for 'GPT'.

rworkman · 02-17-2015, 04:42 PM

That seems reasonable, but without knowing what the probe used to output (i.e. in 14.1), I hate to say for sure.
EDIT: That ^^ was a reply to ryanpcmcquen, but it's pretty clear now (based on the post after ryan's) what the output used to be; thanks!

ryanpcmcquen · 02-17-2015, 05:18 PM

Screenshot from a 14.1 iso, the first line ends in 'Linux' (from `probe`).

http://s1.postimg.org/yqd6eh3pr/Scre...3_17_36_PM.png

ryanpcmcquen · 02-18-2015, 09:57 AM

Modifying the setup code like so:

Code:

if probe -l 2> /dev/null | grep -E 'Linux$' 1> /dev/null 2> /dev/null ; then
 probe -l 2> /dev/null | grep -E 'Linux$' | sort 1> $TMP/SeTplist 2> /dev/null
elif probe -l 2> /dev/null | grep -E 'Linux filesystem$' 1> /dev/null 2> /dev/null ; then
 probe -l 2> /dev/null | grep -E 'Linux filesystem$' | sort 1> $TMP/SeTplist 2> /dev/null
else

did get me through the install. But lilo had a weird error about a video adapter. I've attached a screenshot. I had to manually add a lilo entry after the installer finished:

http://s17.postimg.org/fc4sj4dkf/20150218_073619.jpg

Code:

image = /boot/vmlinuz
  root = /dev/sda1
  label = linux
  read-only

Then I ran:

Code:

/mnt/sbin/lilo -C /mnt/etc/lilo.conf

The video adapter error was still there but 'linux' got added. I was able to reboot and the system seems fine. Running lilo after the reboot did not show the video adapter error.

turtleli · 02-18-2015, 10:26 AM

I sent Pat a different fix for the issue, since pxesetup also depends on probe output and there was an additional issue detecting EFI system partitions.

The change I recommended to Pat was to add before the cat in /sbin/probe:

Code:

sed -i -e 's/ filesystem//g' $TMP/SeTfdisk

(Though I now realise you can just remove the -i from the sed and remove the cat command. Whoops.)

liloconfig depends on the probe output as well when run from an install disk. Line 539 of liloconfig is

Code:

LNXP="`PROBE -l | grep "Linux$"`"

So perhaps that is why it failed.

Didier Spaier · 02-18-2015, 10:53 AM

Just to clarify, as a reminder we have actually two different "probe":

/sbin/probe in the installer that I have attached to post #5

the probe function in /sbin/liloconfig that begins line #729:

Code:

# 'probe()' borrowed from LILO QuickInst.
probe()
{
 [ ! -z "`dd if=$1 bs=1 count=1 2>/dev/null | tr '\0' x`" ]
 return
}

This is stated in liloconfig from line #113:

Code:

# This is a different 'probe' than the function below.
PROBE() {
  if [ -x /sbin/probe ]; then
    /sbin/probe -l

Anyway don't worry: I'm pretty sure that Pat will cook his own fix or at least check carefully any proposed one, as he is very careful not to break anything in the installer