You are not logged in.
I recently set up a new Arch install on my Lenovo Thinkpad Yoga 460 alongside Windows 10 on a Crucial CT480M500 SSD.
I'm noticing a weird issue where if I reboot from linux, the drive is not recognized on boot. It isn't recognized by the BIOS (under the boot order menu the SSD is not shown) and I can't get to the systemd-boot menu to boot into Arch or Windows.
This happens consistently as long as I reboot using the "reboot" command under Arch Linux. I also tried booting into my installation USB stick, then issuing the "reboot" command there and the same thing happens.
If I instead shutdown, then power back on, the drive is visible. If I power off with the power button, then power back on, it works fine. If I shutdown or restart from in Windows everything works fine too. It's only when I reboot from Linux. After rebooting and noticing that the drive is gone, if I power off and on the drive reappears.
Any suggestions?
Last edited by nonis (2016-04-28 01:50:02)
Offline
First thing would be to check for SSD firmware updates. Second would be to google for similar problems as it might provide some clues to what the problem might be. Third would be to try different kernel version and check if all of them are affected or if it is a recent problem.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I tried updating the firmware with no luck. The app Crucial provides to update their drives' firmware also includes a S.M.A.R.T. stats page. I took a screenshot for comparison then checked back after rebooting under Linux and having the drive not show up again. I noticed that the stat called "Unexpected Power Loss Count" incremented. I did do quite a bit of googling but I couldn't find anything about the drive not showing up after reboot. Tomorrow I'll try using a previous kernel. Thanks for the tips!
Offline
That Unexpected Power Loss Count is not very encouraging, ideally you should get that only if you have to do forced shutdowns (like pulling the power cord), however I suspect that should not be an indication of a problem, unless that happens on every reboot.
I also have a Crucial ssd on my laptop and the Unexpected Power Loss Count does increase once in a while, I have no clue why because I have not had to resort to hard shutdowns as much as the count seems to imply.
If there is a newer firmware version you could always try the bootable iso method, but make sure you have backups of everything important, as all kinds of firmware update have some risk.
When you boot from live media and the disk is not there make sure to check the output of dmesg, there could be some clues there, such as timeouts, errors or something like that.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Is EHCI enabled in the motherboard settings for this SATA port? EHCI should support hotswapping, and even if it loses power would theoretically come back up.
I think I know enough to know I don't know enough.
Offline
@Silkworm205: It's AHCI for SATA. EHCI is related to USB. And don't forget UHCI, OHCI, XHCI, ...
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
I tried the LTS Kernel which is on 4.4.8 (vs. 4.5.1 originally) but had the same issue. There aren't any BIOS settings related to AHCI as far as I can tell. I also upgraded the firmware on the drive itself before the last time I posted.
I tested it a few more times and it definitely increments the Unexpected Power Loss Count each time I reboot under Linux. Luckily this is a brand new install so if I'm not worried about losing data. I think the drive is under warranty still so at least if it's failing in some way I should be able to replace it easily.
Offline
@Alphniner Thanks, I thought I got that wrong. I should've googled more than just to make sure it was a real standard.
I think I know enough to know I don't know enough.
Offline
I would also check if there are any updates to the uefi firmware.
Maybe you could try different reboot methods, you will have to add the reboot= option to your kernel command line.
I'll quote what the documentation says:
reboot= [KNL]
Format (x86 or x86_64):
[w[arm] | c[old] | h[ard] | s[oft] | g[pio]] \
[[,]s[mp]#### \
[[,]b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci]] \
[[,]f[orce]
Where reboot_mode is one of warm (soft) or cold (hard) or gpio,
reboot_type is one of bios, acpi, kbd, triple, efi, or pci,
reboot_force is either force or not specified,
reboot_cpu is s[mp]#### with #### being the processor
to be used for rebooting.
You might be able to combine options [1] so you'll have a good number of combinations to test.
If you do find one method that works, consider reporting this in the kernel bug tracker as that particular laptop+firmware version might need a special quirk to work properly.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
That did it, I think. As long as I boot with kernel param reboot=efi, when I reboot it seems to work.
I'll file a bug report for sure. How can I find out what the default value for reboot_type is on the current arch kernel for comparison?
Also, do you have any insight as to why I need this kernel parameter? I think the laptop's been out for a year now, so I doubt I'm the first person to try to run Linux on it right?
Oh, and thanks for the help!
Last edited by nonis (2016-04-26 23:03:02)
Offline
If my analysis of the kernel source code is correct I believe the default is acpi, but I may be wrong. This means that for arch the default is acpi.
You really want to report this upstream, if I'm not mistaken there is a list (arch/x86/kernel/reboot.c) where quirks are maintained for machines that need it, yours might be a good candidate. The kernel devs will be the ones most qualified to do that decision (maybe after they ask you to do some more tests).
Also don't forget to edit your first post and add [Solved] to the title.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I reported this on the kernel bug tracker. According to a member of Crucial's forum, it has something to do with this particular drive needing to be sent a 'spin-down' command before reboot. Still, I wonder why I didn't notice this problem two years ago the first time I used Linux on this SSD, or why it hasn't affected anyone enough to have been fixed already, since this is a relatively old SSD.
Thanks again for the help.
Offline
It would be nice if you could leave the links to the bug report and the thread at crucial's forum, just in case someone else has the same problem and finds this thread.
Regarding the drive needing to be informed of a shutdown/reboot (if I recall correctly the command is either idle-immediate or standby-immediate), it does make sense so the drive knows that it is time to stop everything and save important things (mapping table). I've seen this recommendation somewhere, maybe in some documentation related to the ssd I own, but I wouldn't be surprised if it is the same for ssds from other brands.
Maybe two years ago you didn't have a problem, maybe something was changed since then and now you see a problem.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Offline