MBP 13" 2017 Touchbar - OSX Mojave - Fog can't find a disk
rhulet last edited by Sebastian Roth
I am booting via USB, and for whatever reason FOG can’t recognize that there is even a disk???
I am using the most recent Kernal updated on 8/6, HELP!
When I boot into debug, I get an
unable to access /index.php for connection testing
So sorry Sebastian! I was out of the office and got put on another project. I will test this today! Thank you!
@rhulet We’ve pushed this quite far and I’d hope you read this and test the kernel I compiled for you!
@rhulet Any news on this?
I would download the new 5.x kernel and place it in the /var/www/html/fog/service/ipxe directory as bzImage5116 Then go into the host definition for this mac and set the kernel parameter to bzImage5116…
Crud I forgot you are using a usb stick. Copy that to the usb stick as bzImage in the /boot directory (you might want to save the original kernel). Then boot into debug mode again and do a
lsblkcommand to see if the nvme disk is seen.
@rhulet Oh well, just started the compilation and when I got back from the bathroom it was done already: https://fogproject.org/kernels/Kernel.TomElliott.5.1.16_mac-nvme-fix.64
echo 106b 2005 > /sys/bus/pci/drivers/nvme/new_idshould not be needed with this one as far as I understand the patch.
No guarantee this will run with our inits… untested kernel!!
Yeah last time I used it the machine shut down after about 10 seconds
Ok, so we are back to the points of the github topic. So what I would suggest is that I compile a 5.x kernel including the patch mentioned and we’ll see what happens. Won’t get to that tonight though I think. Late here and little sleep.
@george1421 Yeah last time I used it the machine shut down after about 10 seconds
@rhulet If you are still in debug mode the echo command that Sebastian mentioned was this:
echo 106b 2005 > /sys/bus/pci/drivers/nvme/new_id
(I did see that Sebastian posted the exact command below)
What others have said is the system runs for about 10 seconds, hangs and you get high fan spin. Others said it worked, but most said not.
@Sebastian-Roth Keyboard doesn’t work. I have a USB to USB-c that I have a keyboard plugged into, use that to get ssh working, and then ssh in from another machine.
I don’t get this. Probably you have a different model than the one discussed in that topic and the simple
echohack is enough for your device.
@rhulet @george1421 From what I read here I get the impression that when you do that
echo ... > ... new_idthe machine restarted after about 10 seconds or so for most (if not all) users posting there. Did you see this happen as well?
I think the main comment that should point us on what exactly is the issue is this one:
… Linux kernel in no way supports non-0x40 sized SQ command queues. This would have to be added. I have no idea if such a patch would even be accepted …
I am still not through all the messages but the are definitely talking about kernel version 5.x which we don’t use yet. We can, but we haven’t yet.
Some time in July there was another guy joining the discussion and offering a different kernel patch and as far as I got now it sounds as if they all agreed the new one was better. The issue is way to complex (all about SSD internal queues and so forth) for me to really see if they are on the right track. But from what I read it sounds as if they are really experienced kernel hackers!
@rhulet I’d just say add the
echo ... > ... new_idas post script and try capturing an image from that machine. I doubt it works but give it a go!
ref5: Tech german explain the patch: https://www.youtube.com/watch?v=fepSwZFCCg4
So what I found out so far, the nvme disk controller is managed by the T2 security chip. The chip will only “unlock” the hard drive if the kernel is signed by microsoft. So Windows and AppleOS will boot/have access to the disks on these devices. Its pretty much an enhanced hardware managed secure boot option.
The github patch looks pretty interesting and simple.
Are you saying it isn’t worth pursuing at this time?
I think what he’s saying is there are some pretty smart folks working on the problem and we as a linux consumer project is not ready to deploy to those machines. From the github site this issue is being looked at it right now (today). As soon as a reliable patch is made the developers could look at integrating that into the FOS Linux kernel.
I wouldn’t rush into it. Please give me a few more minutes to fully read the discussion on github to get an idea.
@rhulet I think what he’s saying is there are some pretty smart folks working on the problem and we as a linux consumer project is not ready to deploy to those machines. From the github site this issue is being looked at it right now (today). As soon as a reliable patch is made the developers could look at integrating that into the FOS Linux kernel.
Are you saying it isn’t worth pursuing at this time?
ref4: https://github.com/Dunedan/mbp-2016-linux/issues/71#issuecomment-507325112 still trying to decipher this one
Well, the important part here is:
This patch is provided with no guarantee, responsibility or liability. Use at your own risk. I have only tested file system reading, not writing, write should work just fine but you are taking the risk yourself, as it might brick the laptop just as well.
I wouldn’t go there just now.
@rhulet Here you go, next quick test: Boot back into the Linux FOS system where you got the
lspcioutput. Then run the following commands:
echo 106b 2005 > /sys/bus/pci/drivers/nvme/new_id lsblk
Take a picture and post here.
@rhulet Sorry not enough but I think George is on the right track already. Mass storage sounded just too easy so I didn’t follow that one… ;-)
We’ll surely figure out if it’s possible or not soon!