Partitioning SSD with correct allignment?

[Tuxedo]

Hello,

Below is my current partion done with via a GParted USB media prior to
booting Slackware's installation media:

Partition Size Label
-----------------------------------------------------
/dev/nvmeOn1p1 ext4 data 1.52 TiB
/dev/nvmeOn1p2 ext4 slackware 200 GiB
/dev/nvmeOn1p3 ntfs windows 98.72 GiB
/dev/nvmeOn1p4 linux-swap swap 9.28 GB
-----------------------------------------------------

The partitions are so far empty, so the whole set up can easily be recreated
without any data loss.

After loading 'huge.s' via my Slackware 64 media and logging in as 'root' I
ran the following:

# parted
(parted) align-check opt 1

... the output however is:

1 not aligned.

Partitioning appears more complex with SSD. According to the 'parted' tool,
I guess I somehow aligned the partitions incorrectly in GParted.

How can the alignment best be corrected or partitions re-created correctly
using some other tool?

Many thanks,
Tuxedo

[Tuxedo]

While in pre-Slackware install model using a Slackware USB media and running
the 'gdisk' command:

gdisk /dev/nvmeOn1p1

... the output is:

Partition table scan:

MBR: not present
BSD: not present
APM: not present
GPT: not present


(I presume the MBR is not present because no OS has been installed on the
disk so far making a record in the MBR sector.)

If entering 'p' in gdisk's menu, the following details are shown:

Disk /dev/nvmeOn1p1: 7773104 sectors, 3.7 Gib
Logical sector size: 512 bytes
Disk identifier (GUID) ...........
Partition table holds up to 128 entries
Fisst usable sector is 34, last usable sector is 7773070
Partitions will be aligned on 2048-sector boundaries
Total free space is 7773037 secotors (3.7 GiB)

Is gdisk the tool that can be used to fix the alignment? If so, how?

Thanks again,
Tuxedo

[Ars Ivci]

As far as I can remember (too much time elapsed since I used a dual boot
set-up), Windows only installs to MBR(msdos) partitioned drives with
BIOS. Windows only installs to gpt(GUID) partitioned drives with UEFI.
So if you intend to use Win, proceed accordingly. All things considered,
UEFI/gpt seems to be the logical choice for dual-boot.

If you insist on MBR, make sure win partition is primary and has a
bootable flag and I may be be wrong on this, use fdisk, as yours looks
like bios+gpt. I doubt win10 (if it is win10) will manage to boot that way.

Had it been a normal sata drive, I'd say go with mbr, partition with
fdisk and try to install windows. If it boots, fine. Install Slackware,
rewrite MBR with LILO and all is good. If Win does not install or boot,
you have to switch to UEFI/gpt.

peace,
t.

[Eef Hartman]

Tuxedo <tux...@mailinator.com> wrote:
> Partition Size Label
> -----------------------------------------------------
> /dev/nvmeOn1p1 ext4 data 1.52 TiB
> /dev/nvmeOn1p2 ext4 slackware 200 GiB
> /dev/nvmeOn1p3 ntfs windows 98.72 GiB
> /dev/nvmeOn1p4 linux-swap swap 9.28 GB
> -----------------------------------------------------
>
> The partitions are so far empty, so the whole set up can easily be recreated
> without any data loss.
>
> After loading 'huge.s' via my Slackware 64 media and logging in as 'root' I

You didn't say what version of Slackware 64. As far as I know 14.2
still has problems with NVM media so the installer probably won't
work correctly. You should get a "-current" ISO media to try again.
You can get these from AlienBob:
http://bear.alienbase.nl/mirrors/slackware/slackware64-current-iso/

> # parted
> (parted) align-check opt 1

Also: there is a difference between "minimal" aligment and "optimal",
it may well be that GPartEd used the minimal (alignment on 2 KB
boundaries) one while you're checking for the optimal one.

[Tuxedo]

Eef Hartman wrote:

> Tuxedo <tux...@mailinator.com> wrote:
>> Partition Size Label
>> -----------------------------------------------------
>> /dev/nvmeOn1p1 ext4 data 1.52 TiB
>> /dev/nvmeOn1p2 ext4 slackware 200 GiB
>> /dev/nvmeOn1p3 ntfs windows 98.72 GiB
>> /dev/nvmeOn1p4 linux-swap swap 9.28 GB
>> -----------------------------------------------------
>>
>> The partitions are so far empty, so the whole set up can easily be
>> recreated without any data loss.
>>
>> After loading 'huge.s' via my Slackware 64 media and logging in as 'root'
>> I
>
> You didn't say what version of Slackware 64. As far as I know 14.2
> still has problems with NVM media so the installer probably won't
> work correctly. You should get a "-current" ISO media to try again.
> You can get these from AlienBob:
> http://bear.alienbase.nl/mirrors/slackware/slackware64-current-iso/

It's a 64 bit 14.2 I have on my USB-media. However, it may be some years
old. On a previous installation I tested comparing it with the 32 bit
version on a separate partition and found the 64 bit version to work
perfectly including the Multilib setup. In the end I discarded the partition
with the 32 bit version.

I will download the above current iso and do a test-installation on the new
hardware with an SSD. With NVM media, do you refer to the USB installation
media or that SSD's may not work correctly?

My previous Slackware 14.2 64 installation was on an older ThinkPad with a
spinning HDD platter.

>
>> # parted
>> (parted) align-check opt 1
>
> Also: there is a difference between "minimal" aligment and "optimal",
> it may well be that GPartEd used the minimal (alignment on 2 KB
> boundaries) one while you're checking for the optimal one.

Thanks for pointing this out. Running parted now returns:

root@slackware:/# parted
GNU Parted 3.2
Using /dev/sdb
Welcome...
(parted) align-check min 1
1 aligned

Would this be good enough for SDD purposes?

Tuxedo

[Tuxedo]

Ars Ivci wrote:

> On 30-08-2018 12:47, Tuxedo wrote:
>> Tuxedo wrote:

[...]

>
> As far as I can remember (too much time elapsed since I used a dual boot
> set-up), Windows only installs to MBR(msdos) partitioned drives with
> BIOS. Windows only installs to gpt(GUID) partitioned drives with UEFI.
> So if you intend to use Win, proceed accordingly. All things considered,
> UEFI/gpt seems to be the logical choice for dual-boot.
>
> If you insist on MBR, make sure win partition is primary and has a
> bootable flag and I may be be wrong on this, use fdisk, as yours looks
> like bios+gpt. I doubt win10 (if it is win10) will manage to boot that
> way.
>
> Had it been a normal sata drive, I'd say go with mbr, partition with
> fdisk and try to install windows. If it boots, fine. Install Slackware,
> rewrite MBR with LILO and all is good. If Win does not install or boot,
> you have to switch to UEFI/gpt.
>
> peace,
> t.

The last time I installed with dual boot was with a spinning drive using MBR
to load Slackware 14.2 64 or Windows 7, which still works fine.

The bios was configured to default to legacy first and UEFI second, and
perhaps the latter is what takes effect when Windows starts.

I will try the same or similar with the new SDD. Hopefully Slackware will
work on the SSD.

If Windows works, great, and if not, it's not important. I rarely use it.

Encryption with LUKS for the Linux partitions is however probably better
combined with LVM than my current partition setup.

Tuxedo

[Eef Hartman]

Tuxedo <tux...@mailinator.com> wrote:
> It's a 64 bit 14.2 I have on my USB-media. However, it may be some years
> old. On a previous installation I tested comparing it with the 32 bit

The official 14.2 media (both 32- and 64-bit ones) are a bit more than
2 years old (july 2016). Lots of hardware changes have happened since.

> hardware with an SSD. With NVM media, do you refer to the USB
> installation media or that SSD's may not work correctly?

NVMe is a new standard for especially SSD disks and as your partition
table had /dev/nvm* device names (and _not_ /dev/sd<letter><number>
ones, which would result from sata/scsi-like disks) I suspect your
SSD _is_ a NVMe one. They do not use the old S-ATA disk interface
anymore but a special controller, developed for solid state drives
(NVMe stands for Non-Volatile Media-express and works through the
PCI-express bus, just like faster screen adaptors).
You need a newer kernel for those then the 14.2 ISO can provide
(the 4.4.153 one, provided as an update FOR Slackware 14.2, should
have that support, but that one isn't on the ISO and even then the
installer will maybe not detect NVMe technology drives correctly).

BTW: Slackware 14.2 original came out with the 4.4.14 kernel, that one
has been updated (in the patches/packages tree on Slackware mirrors)
multiple times already. This 4.4.153 one was released a few days ago.

[Tuxedo]

I started a test installation with the current full dvd version and just
arrived at the LILO installation stage, where setup suggests /dev/sda as the
auto-detected MBR boot block, but that is not an installable location.

GParted formatted the names of the partitions as follows:
/dev/nvmeOn1p1
/dev/nvmeOn1p2
/dev/nvmeOn1p3
/dev/nvmeOn1p4

Is it possible to install the bootloader to MBR with the current
slackware64-current-install-dvd.iso? If so, what should be entered into the
CONFIRM LOCATION TO INSTALL LILO field?

Is LILO even compatible? Or should I make a boot disk first and thereafter
update the system with an updated and NVM-compatable LILO if it exists?

Many thanks,
Tuxedo

[Pascal Hambourg]

Le 30/08/2018 à 11:47, Tuxedo a écrit :
>
> gdisk /dev/nvmeOn1p1

You're not going to get useful results if you run gdisk or any other
partitioning tool on a partition instead of the whole drive /dev/nvme0n1.

[Henrik Carlqvist]

On Thu, 30 Aug 2018 22:43:56 +0200, Tuxedo wrote:
> GParted formatted the names of the partitions as follows:
> /dev/nvmeOn1p1 /dev/nvmeOn1p2 /dev/nvmeOn1p3 /dev/nvmeOn1p4

> Is LILO even compatible? Or should I make a boot disk first and
> thereafter update the system with an updated and NVM-compatable LILO if
> it exists?

I usually use LILO to boot my Slackware installations, but if I remember
right, when installing on SSD connected by a PCIe card I had to use
something else as LILO did not work with /dev/nvme*. I did choose
extlinux which is part of syslinux and has the same syntax to the
configuration file as isolinux which is used to create bootable CDs/DVDs.

regards Henrik

[Tuxedo]

Tuxedo wrote:

> Eef Hartman wrote:
>
>> Tuxedo <tux...@mailinator.com> wrote:

[...]

> Is LILO even compatible? Or should I make a boot disk first and thereafter
> update the system with an updated and NVM-compatable LILO if it exists?

The problem was that I had selected manual Lilo configuration, which
suggested /dev/sda as the MBR target. With a new installation, I allowed
setup to automatically install Lilo, which worked better.

/etc/lilo.conf shows:

boot = /dev/nvmeOn1

Tuxedo

[Eef Hartman]

Tuxedo <tux...@mailinator.com> wrote:
> With a new installation, I allowed setup to automatically install
> Lilo, which worked better.
>
> /etc/lilo.conf shows:
>
> boot = /dev/nvmeOn1

Thta's what I meant that the _new_ installer of -current understands
NVMe drives. Automatic install probably wouldn't have worked with the
14.2 image.