cgdisk problem during install

You have a problem with Salix? Post here and we'll do what we can to help.

cgdisk problem during install

Postby Kimdino » 18. Mar 2017, 02:35

Hi folks,
I have been using Slackware for many years but liked the Salix additions so much (Sourcery is brilliant) that I added the Salix repository to my Slackware installation. As my old hard drive was showing signs of failing I bought a new 3TB drive and decided I might as well migrate my system fom Slackware 14 to a proper Salix syatem during the installation.

I always preconfigure a hard drive before installation as I like to the new system to boot into my previous Desktop settings, files & setup as much as possible. So, before starting the install I setup the partitions using GParted using my standard scheme i.e. sd?1 as ext4 for / (20Gb), sd?2 as linux-swap for swap (16Gb), sd?3 as ext4 for home (2.5Tb) & sd?4 as ext4 for opt (150Gb). As the drive was above 2.2Tb I found I was unable to use 'cfdisk' and so used GParted instead to get GPT capability.

After formatting I copied the files across from my 'home' and 'opt' partitions on to the new drive. This was all done with the new drive connected via a USB to SATA adapter. I then installed the new drive in place of my current drive. I then booted on to the Salix64 Xfce 14.2 DVD for the installation.

On reaching the partitioning stage I tried to tell the installer to continue with partitioning but couldn't as the installer insisted there was no valid Linux partition. So I tried the Setup Partition option. 'cgdisk' showed my partition map but described my partitions as 'Microsoft basic data'. (0700).

I had a look at 'cgdisk's available options and they made no sense to me. The was 'Linux /', 'Linux home' and similar but no sign of which Linux type (i.e. ext, reiser etc). I then set sda1 to 'Linux /' but the installer still balked insisting there was no valid Linux partition. sda3 & sda4 have become sacrosanct so I did not try any messing with them.

I have since reinstalled the Slackware drive and used this to examine the new drive. 'GParted' reports all's well with partition 1 still formatted as ext4 ????.
[img]file:///home/dino/Desktop/partitions.png[/img]

Can anyone give any pointers to where I might be going wrong and how to continue?
Kimdino
 
Posts: 6
Joined: 18. Mar 2017, 01:24

Re: cgdisk problem during install

Postby DidierSpaier » 18. Mar 2017, 19:52

Hi Kimdino, welcome to this forum.

At time or setting the filesystems' table (that will become /etc/fstab in the new system) the installer don't look for filesystems (e.g. ext4) but only for partitions, as recorded in the partition table (the GPT for GUID Partition Table in this case), and changing a partition's type doesn't alter an existing filesystem in this partition, conversely changing the file system doesn't change the partition table. This is because the file system is inside the partition, but the partition table where each partition's type is recorded is elsewhere. I realized this some time ago.

So, to investigate further, please connect the new drive again, then from the Slackware system type these commands and post the full output (of course replace ? by the letter for the new disk):
Code: Select all
lsblk -o model,name,size,fstype,mountpoint
gdisk /dev/sd?
p # to display the partition table.
DidierSpaier
 
Posts: 105
Joined: 20. Jun 2016, 20:15

Re: cgdisk problem during install

Postby westms » 19. Mar 2017, 11:26

Hello,

the use of a data including (external) SATA hard drive with an connected USB-to-SATA adapter, directly as an internal SATA hard drive, can work. But you have to be very lucky. In most cases it will not happen. The connected USB-to-SATA adapter is not bound to any rules when handling the hard drive. For a failure of the move it is already sufficient, if the guest computer e.g. uses sector size 512 bytes, and the USB-to-SATA adapter simulates sector size 512 bytes only, but on the hard disk e.g. 4 KiB sector size is used.

The foregoing applies to USB-to-SATA adapters, as they are used in casing for external hard disks with USB connection. If, however, it is an HDD docking station, it may be that this device does not cope with large hard disks.

The best way would be to install the new hard drive and connect it as the only one. Then install Salix. The old hard disk is then connected and the data is then copied.

For a partioning before the Salix installation I see basically no reason, but with a hard disk size of 3 TiB you will want to use the GPT scheme. Therefore, it may be useful to use a GParted live distribution e.g. Gparted-live-0.28.1-1-i686.iso to partition the disk first using the GPT scheme, even if UEFI is not used.
westms
 
Posts: 264
Joined: 17. Mar 2013, 18:51

Re: cgdisk problem during install

Postby Kimdino » 19. Mar 2017, 12:55

Hi Didier,
The question has become academic after humouring 'cgdisk' and allowing it to write 'type Linux' to the drive. I then discovered, to cut a long story short, that the data on my old drive was beyond recovery. However, I have discovered the joys of keeping some of the data stored on a separate file server. We live and learn

So now a simple fresh install is the best option. And, thanks for your help.
Kimdino
Kimdino
 
Posts: 6
Joined: 18. Mar 2017, 01:24

Re: cgdisk problem during install

Postby Kimdino » 19. Mar 2017, 13:50

Hi westms,
Thanks for your reply.

My aim was not to use a USB connected drive as an internal drive but to facilitate copying. In such a case as this I feel that accidents are less prone to happen if connected physically distinct. The sector size is of no concern as I used 'cp -rpxv <sourcedir>/* destdir>/' toensure the data is free of any media attributes.

Re> The best way would be to install the new hard drive and connect it as the only one. Then install Salix. The old hard disk is then connected and the data is then copied.
I like that idea, but do like to make the copy first as I have found that (a) it saves the new OS having to write any uneccessary clutter and/or (b) prevents possible confusion in the new OS from being presented with different data from what it expected. It also has the virtue of impressing people when they see their computer start up in a state that allows them to continue exactly as they left it, only with a brand new OS - something that MS-Windows cannot do. I have done this many times previously with no problem. This time, I believe the problem may have come from my unfamiliarity with 'cgdisk', instead of 'cfdisak' which I am used to. 'cgdisk's presenting existing ext4 partitions (subsequently verified as such with 'GParted') as 'Microsoft basic data' does strike me as a bug, . However, I have learnt to tread very carefully in reporting such, especially after Googling reveals no other reports of this behaviour - does anyone else have any comments?

Anyway, thanks for your help, Kimdino
Kimdino
 
Posts: 6
Joined: 18. Mar 2017, 01:24

Re: cgdisk problem during install

Postby laprjns » 19. Mar 2017, 19:36

Kimdino wrote: cgdisk's presenting existing ext4 partitions (subsequently verified as such with 'GParted') as 'Microsoft basic data' does strike me as a bug,

fdisk, gdisk, cfdisk, and cgdisk are disk partitioning tools, they do not format file systems not do they even report (as far as I know) the file system of any formatted partitions. parted and gparted can do both partitioning and file system formatting. As Didier pointed out, a partition type doesn't necessary mean that it contains a file system that would seem to be consistent with the types name. In other words it is possible to have a partition with a partition type as Microsoft basic date formatted as ext4, as apparently your three partitions ( sd*1, sd*3, and sd*4) were. So it is not a bug in cgdisk, since cgdisk doesn't even care about what file system the partition have on them.

What you apparently had was three partitions all formatted with ext4 file system that were somehow identified as Microsoft Basic Data (0700) partition type. The Slackware installer when presenting candidate partitions for the / file system looks at the partition types of all available partitions on the designated disks and present only those with Linux partition types . Since none of your partitions where not designated as Linux types, the installed determined that there where no valid Linux disks. An easy way to fix this would have been to fire up cgdisk or parted and change the partition type to Linux.
User avatar
laprjns
Salix Warrior
 
Posts: 959
Joined: 28. Aug 2009, 01:30
Location: Connecticut USA

Re: cgdisk problem during install

Postby Kimdino » 19. Mar 2017, 23:09

Hi laprjns,
That makes sense, except one must then wonder what makes a partition a 'Linux' type? Does it being formatted with a type commonly used by Linux (i.e. ext) not imply that the underlying partition type is more likely to be a Linux type than a Microsoft type? 'cfdisk' can see the difference, does GPT hide it? Before the format had been done, it could see the partition as type 'ext', which is certainly not a Microsoft type. Someday, when I have a spare bit of drive space to try it with, I might try setting a partition type to NTFS and see if it can be formatted to ext.

Re> An easy way to fix this would have been to fire up cgdisk or parted and change the partition type to Linux.
I did that in the end with cgdisk, which is how I blew my data.? It had been created originally with Gparted,

Cheers, Kimdino
Kimdino
 
Posts: 6
Joined: 18. Mar 2017, 01:24

Re: cgdisk problem during install

Postby DidierSpaier » 19. Mar 2017, 23:27

See https://en.wikipedia.org/wiki/GUID_Part ... type_GUIDs
and especially this note: https://en.wikipedia.org/wiki/GUID_Part ... -linwin-33
tl;dr:
  1. A partition of type Linux Filesystem Data has as GUID 0FC63DAF-8483-4772-8E79-3D69D8477DE4
  2. But a Linux file system (like ext4) can also be installed in a partition of type (from Windows) Basic data partition;, with as GUID: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
But Slackware's and derivatives' installers only accept 0FC63DAF-8483-4772-8E79-3D69D8477DE4. I think that EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 could be accepted as well, and will probably add that in Slint's installer.
DidierSpaier
 
Posts: 105
Joined: 20. Jun 2016, 20:15

Re: cgdisk problem during install

Postby Kimdino » 20. Mar 2017, 00:25

Hi Didier,
My gut feeling is that Slackwares current position of only accepting 0FC63DAF-8483-4772-8E79-3D69D8477DE4 is the technically correct thing. But, for the real world, if Microsoft basic data partitions can be formatted to 'ext' then the option must be offered. Which, I accept, makes 'cgdisk' correct. I don't like it, but probably am biased after having been painfully bitten by not fully understanding all this. A reminder that 'All design is compromise' and my hat is now raised to the folk that put cgdisk together.

Anyway, I now have a working Salix installation and have recovered much of my data. So, thanks to you all - not least for an increased understanding of the innards of a partition system.
Cheers, Kimdino
Kimdino
 
Posts: 6
Joined: 18. Mar 2017, 01:24


Return to Problems