Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #202483 > unrolled thread

New SSD on a MacBook Pro

Started bysolitone <solitone@mail.com>
First post2018-11-15 18:30 +0100
Last post2018-11-17 17:50 +0100
Articles 17 — 5 participants

Back to article view | Back to linux.debian.user


Contents

  New SSD on a MacBook Pro solitone <solitone@mail.com> - 2018-11-15 18:30 +0100
    Re: New SSD on a MacBook Pro deloptes <deloptes@gmail.com> - 2018-11-15 21:10 +0100
      Re: New SSD on a MacBook Pro solitone <solitone@mail.com> - 2018-11-15 21:40 +0100
        Re: New SSD on a MacBook Pro deloptes <deloptes@gmail.com> - 2018-11-15 22:00 +0100
          Re: New SSD on a MacBook Pro solitone <solitone@mail.com> - 2018-11-16 14:00 +0100
          Re: New SSD on a MacBook Pro solitone <solitone@mail.com> - 2018-11-16 14:30 +0100
            Re: New SSD on a MacBook Pro Stefan Monnier <monnier@iro.umontreal.ca> - 2018-11-16 14:50 +0100
              Re: New SSD on a MacBook Pro solitone <solitone@mail.com> - 2018-11-16 15:40 +0100
                Re: New SSD on a MacBook Pro Stefan Monnier <monnier@iro.umontreal.ca> - 2018-11-16 16:40 +0100
                  Re: New SSD on a MacBook Pro deloptes <deloptes@gmail.com> - 2018-11-16 21:10 +0100
              Re: New SSD on a MacBook Pro solitone <solitone@mail.com> - 2018-11-17 08:00 +0100
                Re: New SSD on a MacBook Pro Stefan Monnier <monnier@iro.umontreal.ca> - 2018-11-17 16:20 +0100
                  Re: New SSD on a MacBook Pro Dan Ritter <dsr@randomstring.org> - 2018-11-17 16:30 +0100
                    Re: New SSD on a MacBook Pro Stefan Monnier <monnier@IRO.UMontreal.CA> - 2018-11-17 19:20 +0100
                      Re: New SSD on a MacBook Pro solitone <solitone@mail.com> - 2018-11-17 21:10 +0100
                        Re: New SSD on a MacBook Pro Stefan Monnier <monnier@iro.umontreal.ca> - 2018-11-17 22:40 +0100
                  Re: New SSD on a MacBook Pro solitone <solitone@mail.com> - 2018-11-17 17:50 +0100

#202483 — New SSD on a MacBook Pro

Fromsolitone <solitone@mail.com>
Date2018-11-15 18:30 +0100
SubjectNew SSD on a MacBook Pro
Message-ID<wUtCN-6ov-1@gated-at.bofh.it>
Hi, I've got a compatibility question regarding SSDs.

I run debian 9.6 on a MacBookPro12,1 (Early 2015, 13"). I'm thinking of 
upgrading the stock 128 GB SSD [1]. Specifically, I'm considering the 
Trascend JetDrive 850 [2].

The original SSD uses a PCIe 3.0 x4 interface and the AHCI protocol. 
Although MacBookPro12,1 cannot take advantage of PCIe 3.0 (I gather it 
only supports PCIe 2.0), it  supports the NVMe specification, hence it'd 
be possible to upgrade to an NVMe SSD [3]. JetDrive 850 uses a PCIe 3.0 
x4 interface with NVMe.

What do you think in terms of compatibility with debian? What worries me 
is that JetDrive 850 requires macOS version 10.13 or later, and I wonder 
whether debian supports it. Is this only a matter of NVMe (macOS 
supports NVMe starting from version 10.13; linux since kernel version 
3.3), or is there something else to consider?

Thanks in advance!


[1] I'm running short of space, since I've got a Windows 10 instance in 
KVM that's hungry of storage space. Almost all of the 32 GB that I've 
allocated are used by just the system and its updates!
[2] https://www.transcend-info.com/Products/No-956
[3] 
https://beetstech.com/blog/apple-proprietary-ssd-ultimate-guide-to-specs-and-upgrades#hdr-21

[toc] | [next] | [standalone]


#202506

Fromdeloptes <deloptes@gmail.com>
Date2018-11-15 21:10 +0100
Message-ID<wUw7D-851-1@gated-at.bofh.it>
In reply to#202483
solitone wrote:

> What do you think in terms of compatibility with debian? What worries me
> is that JetDrive 850 requires macOS version 10.13 or later, and I wonder
> whether debian supports it. Is this only a matter of NVMe (macOS
> supports NVMe starting from version 10.13; linux since kernel version
> 3.3), or is there something else to consider?

I don't think so, I also do not think you have to stick to this specific
drive (JetDrive 850) - perhaps macOS certified, but from linux perspective
it would make no difference.

[toc] | [prev] | [next] | [standalone]


#202510

Fromsolitone <solitone@mail.com>
Date2018-11-15 21:40 +0100
Message-ID<wUwAF-8fk-5@gated-at.bofh.it>
In reply to#202506
On 15/11/2018 21:01, deloptes wrote:
> I also do not think you have to stick to this specific
> drive (JetDrive 850) - perhaps macOS certified, but from linux perspective
> it would make no difference.

The thing is the form factor, which unfortunately is proprietary [1]. 
The connector resembles the standard M.2, but in fact is different.

Another options would be OWC Aura Pro X [2], but many people report 
overheating issues with that drive.

[1] 
https://beetstech.com/blog/apple-proprietary-ssd-ultimate-guide-to-specs-and-upgrades#hdr-6
[2] https://www.owcdigital.com/products/aura-pro-x

[toc] | [prev] | [next] | [standalone]


#202513

Fromdeloptes <deloptes@gmail.com>
Date2018-11-15 22:00 +0100
Message-ID<wUwU1-8mH-3@gated-at.bofh.it>
In reply to#202510
solitone wrote:

> The thing is the form factor, which unfortunately is proprietary [1].
> The connector resembles the standard M.2, but in fact is different.

OK this is a valid argument. Check first if someone has used it on your type
of hardware and what is the feedback - I assume you are not the first. NVMe
is working fine - debian provide the kernel which provides the support and
I have seen M.2 working just fine - don't know what is in the background,
but linux was on top.

[toc] | [prev] | [next] | [standalone]


#202529

Fromsolitone <solitone@mail.com>
Date2018-11-16 14:00 +0100
Message-ID<wULT3-14A-3@gated-at.bofh.it>
In reply to#202513
On 15/11/2018 21:48, deloptes wrote:
> Check first if someone has used it on your type
> of hardware and what is the feedback - I assume you are not the first. NVMe
> is working fine - debian provide the kernel which provides the support and
> I have seen M.2 working just fine

Late 2016 - Mid 2017 MacBookPros (MBPs) with Generation 5 SSDs (PCIe 3.0 
x4 NVMe) do work with linux kernel >= 4.11 [1].

MacBookPro13,3 (it uses a Samsung NVMe controller) also works with 
kernel < 4.11. In contrast, MacBookPro13,1, MacBookPro13,2, 
MacBookPro14,1, and MacBookPro14,2 (they have an Apple NVMe controller) 
need a kernel patch with kernel < 4.11 [1].

I would think that kernel >= 4.11 supports Trascend JetDrive 850, but 
since different controllers have a different level of support I can't 
say it for sure. For the time being I have found no reports on this SSD 
with linux.

[1] https://gist.github.com/roadrunner2/1289542a748d9a104e7baec6a92f9cd7

[toc] | [prev] | [next] | [standalone]


#202530

Fromsolitone <solitone@mail.com>
Date2018-11-16 14:30 +0100
Message-ID<wUMm5-1ul-1@gated-at.bofh.it>
In reply to#202513
Another issue I have is--how to migrate my debian system from the old 
original SSD to the new larger SSD?

As for macOS [1], it should be easy. There is a macOS application called 
Time Machine that allows to backup macOS from the old SSD and to restore 
it to the new SSD. This would work with a single boot system with macOS, 
but I have no idea what will happen to Grub [2] in this process.

However my main concern is with the linux partition. How can I migrate 
it? If I simply clone the linux partition from the old drive to the new 
drive, I fear something would go wrong, as the new drive is different 
and would require different drivers, missing in the original linux system.

What would be the best strategy?

[1] I have a dual boot system, and I have kept macOS mainly to keep the 
possibility of firmware upgrades.
[2] Grub allows to boot debian. If I do nothing, Grub starts and boots 
debian. If I press the "alt" key during startup, the Apple's original 
EFI boot loader starts and boots macOS.

[toc] | [prev] | [next] | [standalone]


#202531

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2018-11-16 14:50 +0100
Message-ID<wUMFr-1Bp-1@gated-at.bofh.it>
In reply to#202530
> However my main concern is with the linux partition. How can I migrate it?
> If I simply clone the linux partition from the old drive to the new drive,
> I fear something would go wrong, as the new drive is different and would
> require different drivers, missing in the original linux system.

I would expect the clone to work just fine.  I'd expect your initrd
contains drivers for both SATA and NVMe anyway.

But it's easy to check:

    zcat /boot/initrd.img-<VERSION> | cpio -vt | grep nvm

will show you the relevant files in the your initrd.
You should have about 10 of them inside ../kernel/drivers/nvme/ if your
initrd is ready to boot from an NVMe drive.


        Stefan

[toc] | [prev] | [next] | [standalone]


#202532

Fromsolitone <solitone@mail.com>
Date2018-11-16 15:40 +0100
Message-ID<wUNrQ-280-5@gated-at.bofh.it>
In reply to#202531
On 16/11/2018 14:46, Stefan Monnier wrote:
> I would expect the clone to work just fine.  I'd expect your initrd
> contains drivers for both SATA and NVMe anyway.
> 
> But it's easy to check:
> 
>      zcat /boot/initrd.img-<VERSION> | cpio -vt | grep nvm
> 
> will show you the relevant files in the your initrd.
> You should have about 10 of them inside ../kernel/drivers/nvme/ if your
> initrd is ready to boot from an NVMe drive.


I've got 8 of them:

$ lsinitramfs /boot/initrd.img-4.18.0-0.bpo.1-amd64 | grep nvme
lib/modules/4.18.0-0.bpo.1-amd64/kernel/drivers/nvme
lib/modules/4.18.0-0.bpo.1-amd64/kernel/drivers/nvme/target
lib/modules/4.18.0-0.bpo.1-amd64/kernel/drivers/nvme/target/nvmet-fc.ko
lib/modules/4.18.0-0.bpo.1-amd64/kernel/drivers/nvme/target/nvmet.ko
lib/modules/4.18.0-0.bpo.1-amd64/kernel/drivers/nvme/target/nvmet-rdma.ko
lib/modules/4.18.0-0.bpo.1-amd64/kernel/drivers/nvme/host
lib/modules/4.18.0-0.bpo.1-amd64/kernel/drivers/nvme/host/nvme-fc.ko
lib/modules/4.18.0-0.bpo.1-amd64/kernel/drivers/nvme/host/nvme-rdma.ko
lib/modules/4.18.0-0.bpo.1-amd64/kernel/drivers/nvme/host/nvme.ko
lib/modules/4.18.0-0.bpo.1-amd64/kernel/drivers/nvme/host/nvme-core.ko
lib/modules/4.18.0-0.bpo.1-amd64/kernel/drivers/nvme/host/nvme-fabrics.ko

[toc] | [prev] | [next] | [standalone]


#202533

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2018-11-16 16:40 +0100
Message-ID<wUOnU-2Kt-9@gated-at.bofh.it>
In reply to#202532
> I've got 8 of them:

So you should be all set.


        Stefan

[toc] | [prev] | [next] | [standalone]


#202545

Fromdeloptes <deloptes@gmail.com>
Date2018-11-16 21:10 +0100
Message-ID<wUSBd-5vZ-7@gated-at.bofh.it>
In reply to#202533
Stefan Monnier wrote:

>> I've got 8 of them:
> 
> So you should be all set.

It is worth trying, though Appli plays always dirty, but chances are good.

[toc] | [prev] | [next] | [standalone]


#202553

Fromsolitone <solitone@mail.com>
Date2018-11-17 08:00 +0100
Message-ID<wV2Ke-3kM-3@gated-at.bofh.it>
In reply to#202531
On 16/11/2018 14:46, Stefan Monnier wrote:
> I would expect the clone to work just fine.  I'd expect your initrd
> contains drivers for both SATA and NVMe anyway.

OK. Now that I know that initrd does contain NVMe drivers, I would ask 
whether my strategy for cloning is sensible.

Firstly, here's my original partition table:

===================================
$ sudo parted -l
Model: ATA APPLE SSD SM0128 (scsi)
Disk /dev/sda: 121GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system     Name                  Flags
  1      20.5kB  210MB   210MB   fat32           EFI System Partition 
boot, esp
  2      210MB   22.6GB  22.4GB  hfs+
  3      22.6GB  23.2GB  650MB   hfs+
  4      23.2GB  31.2GB  8000MB  linux-swap(v1)  swap
  5      31.4GB  121GB   89.8GB  ext4            linux
===================================

Partition 3 is macOS, partition 5 is linux. I don't know why partition 2 
is there, macOS's Disk Utility created it when I originally partitioned 
the disk to make room for linux.

Partition 1 is the EFI partition, which is mounted on /boot/efi:

===================================
$ df
Filesystem     1K-blocks     Used Available Use% Mounted on
udev             4021656        0   4021656   0% /dev
tmpfs             807236     1352    805884   1% /run
/dev/sda5       85825416 68182636  13240004  84% /
tmpfs            4036168     4892   4031276   1% /dev/shm
tmpfs               5120        4      5116   1% /run/lock
tmpfs            4036168        0   4036168   0% /sys/fs/cgroup
/dev/sda1         201633    23678    177955  12% /boot/efi
tmpfs             807232        0    807232   0% /run/user/113
tmpfs             807232       16    807216   1% /run/user/1000
===================================

The debian installer put the Grub2 loader in this partition:

===================================
$ sudo ls /boot/efi/EFI/debian
grubx64.efi

$ sudo efibootmgr -v
BootCurrent: 0000 

Timeout: 5 seconds 

BootOrder: 0000,0080 

Boot0000* debian 
HD(1,GPT,d43355a1-7dc2-4a96-ba68-4400a5db3981,0x28,0x64000)/File(\EFI\debian\grubx64.efi) 

Boot0080* 
PciRoot(0x0)/Pci(0x1c,0x5)/Pci(0x0,0x0)/Sata(0,0,0)/HD(3,GPT,911f18b9-6252-4cb8-8ad3-81c9ca73ded5,0x2a0f760,0x135f20)/File(\System\Library\CoreServices\boot.efi) 
 

Boot0081* Mac OS X 
PciRoot(0x0)/Pci(0x1c,0x5)/Pci(0x0,0x0)/Sata(0,0,0)/HD(3,GPT,911f18b9-6252-4cb8-8ad3-81c9ca73ded5,0x2a0f760,0x135f20) 
 

BootFFFF* 
PciRoot(0x0)/Pci(0x1c,0x5)/Pci(0x0,0x0)/Sata(0,0,0)/HD(3,GPT,911f18b9-6252-4cb8-8ad3-81c9ca73ded5,0x2a0f760,0x135f20)/File(\System\Library\CoreServices\boot.efi)
===================================

Now, here is what I would perform:

(1) Use macOS Time Machine to backup macOS on an external hard drive.
(2) dd the linux partition into an image file:
$ sudo dd bs=4M if=/dev/sda5 of=<ext_media>/debian_part.img
(3) Install new drive.
(4) Use macOS Recovery to restore macOS from the Time Machine backup.
(5) I believe that point (4) will also restore the EFI partition, but 
will debian/grubx64.efi be preserved as well? Need to gather some info 
and check. Anyhow, I should have ended up with just two partitions: the 
EFI partition and the macOS partition.
(6) Use macOS Disk Utility to partition the new disk.
(7) How to restore the backed up debian partition? Do I need to 
reinstall a basic debian system from scratch and then run something like:
sudo dd bs=4M if=<ext_media>/debian_part.img of=/dev/sdaN
(where N is the new partition number)?
Or is there some tool that can ease the recovery process?

Thanks!

[toc] | [prev] | [next] | [standalone]


#202568

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2018-11-17 16:20 +0100
Message-ID<wVay6-eD-7@gated-at.bofh.it>
In reply to#202553
>  4      23.2GB  31.2GB  8000MB  linux-swap(v1)  swap
>  5      31.4GB  121GB   89.8GB  ext4            linux

Didn't use LVM?  Too bad: that means there's a risk your new dirve and
partitions will get new identifiers so your fstab may need to be adjusted.

> Now, here is what I would perform:
>
> (1) Use macOS Time Machine to backup macOS on an external hard drive.
> (2) dd the linux partition into an image file:
> $ sudo dd bs=4M if=/dev/sda5 of=<ext_media>/debian_part.img
> (3) Install new drive.
> (4) Use macOS Recovery to restore macOS from the Time Machine backup.
> (5) I believe that point (4) will also restore the EFI partition, but will
> debian/grubx64.efi be preserved as well? Need to gather some info and
> check. Anyhow, I should have ended up with just two partitions: the EFI
> partition and the macOS partition.

macOS doesn't touch EFI, AFAIK, so don't expect the Time Machine to
touch it either.

This sounds rather complicated.
Here's what I'd do:

1- take out the old SSD and put it into an external reader that you can
   connect via USB
2- put the new SSD in
3- connect the old SSD via USB and boot to its macOS this way (if you
   can boot into Debian this way, even better).
4- create the same partitions on the new drive as you had on the old drive.
5- Use `dd` to copy the content of each partition from the old drive to
   the new drive.
6- reboot without the old drive.  You should be done.


        Stefan

[toc] | [prev] | [next] | [standalone]


#202569

FromDan Ritter <dsr@randomstring.org>
Date2018-11-17 16:30 +0100
Message-ID<wVaHL-i7-1@gated-at.bofh.it>
In reply to#202568
Stefan Monnier wrote: 
> 1- take out the old SSD and put it into an external reader that you can
>    connect via USB

I think that's going to be difficult-to-expensive: it's not a
SATA SSD, it connects through NVMe PCIe.

There are external boxes that can support PCIe via Thunderbolt,
but the cheap ones are around $200.

-dsr-

[toc] | [prev] | [next] | [standalone]


#202571

FromStefan Monnier <monnier@IRO.UMontreal.CA>
Date2018-11-17 19:20 +0100
Message-ID<wVdmh-20Z-1@gated-at.bofh.it>
In reply to#202569
>> 1- take out the old SSD and put it into an external reader that you can
>>    connect via USB
> I think that's going to be difficult-to-expensive: it's not a
> SATA SSD, it connects through NVMe PCIe.

Really?  I thought his old drive was SATA (hence his worries that his
new drive would need new drivers).


        Stefan

[toc] | [prev] | [next] | [standalone]


#202572

Fromsolitone <solitone@mail.com>
Date2018-11-17 21:10 +0100
Message-ID<wVf4J-38F-3@gated-at.bofh.it>
In reply to#202571
On 17/11/2018 16:50, Stefan Monnier wrote:
> Really?  I thought his old drive was SATA (hence his worries that his
> new drive would need new drivers).

No, the old original drive is PCIe 3.0 x4 AHCI. The new one is PCIe 3.0 
x4 NVMe.

[toc] | [prev] | [next] | [standalone]


#202575

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2018-11-17 22:40 +0100
Message-ID<wVgtQ-3T7-5@gated-at.bofh.it>
In reply to#202572
>> Really?  I thought his old drive was SATA (hence his worries that his
>> new drive would need new drivers).
> No, the old original drive is PCIe 3.0 x4 AHCI. The new one is PCIe 3.0
> x4 NVMe.

If we can't get the two drives connected to the same system at the same
time, I guess I'd use a third (USB-connected) drive as intermediary
(and do twice the steps I outlined).


        Stefan

[toc] | [prev] | [next] | [standalone]


#202570

Fromsolitone <solitone@mail.com>
Date2018-11-17 17:50 +0100
Message-ID<wVbXc-10p-5@gated-at.bofh.it>
In reply to#202568
On 17 Nov 2018, at 16:06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Didn't use LVM?  Too bad: that means there's a risk your new dirve and
> partitions will get new identifiers so your fstab may need to be adjusted.

Ehm.. no.. I didn’t!

> macOS doesn't touch EFI, AFAIK, so don't expect the Time Machine to
> touch it either.

I also believe Time Machine won’t backup the EFI partition. Therefore macOS Recovery should recreate a default EFI partition when recovering from the Time Machine backup. A default EFI partition that would only contain Apple’s data, and not the Grub2 loader I have at the moment in the current drive.

Regarding you suggestion and the external reader, I need to check if I can find something cheap.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web