Unsolved
This post is more than 5 years old
2 Posts
0
907
September 7th, 2017 10:00
2720 AIO Haswell i7/16GB 32GB SSD -> 256GB SSD dual boot ubuntu 16.04 LTS / Windows 10
I have been having intermittent problems at boot for a while now. Some time ago, I replaced the 32GB SSD with a Samsung EVO850 256GB, and clean installed Win 10 and Ubuntu 16.04 on separate partitions. At startup, boot selectable from Grub menu.
Windows was fine, but after a while, Ubuntu started having problems at boot, with either a hanging pink screen that required a hard reboot, or a linux kernal / terminal screen that rolled off a long list of diagnostics. If I turned off and attempted to boot Ubuntu a few times, it eventually loaded. Once the OS loaded, there was no problem until the next reboot.
I decided that I'd need to re-install Ubuntu, and deferred it for a period. Subsequently, I had the equivalent problem with Windows, which required a "repair". The repair did not succeed, and finally neither system would boot, no matter how many attempts. It appears that Windows somehow invalidated itself once the "repair" processing was initiated.
I retained the original 32GB SSD, which had my previous Ubuntu installation on it. I also have the original Windows 10 installation on the hard drive in its own system partition...data separate.
Prior to upgrading the SSD, if I removed the SSD, it would boot straight into windows without 1st booting Grub. Once both OSes were installed on the 256GB SSD, it seems that UEFI configured the hard drive OS as "non-bootable". After reverting to the original configuration, I could not boot either system. I reinstalled a clean Ubuntu on the 32 GB SSD. Windows on th hard drive was detected, but won't boot due to having failed a "repair". However, now the 32GB Ubuntu has the same intermittent problems that previously plagued the 256GB SSD. If Ubuntu boots, it runs without any issue until reboot.
The only common denominator is the UEFI hardware.
The obvious nexct step is to restore the 256 GB SSD from backup. However, the symptoms give me no confidence that this will achieve anyhing more than basic "comfort" of the base software. If problems reamin (which they are more likely to do rather than miraculously disappearing, how should we respond to the revelation?.
speedstep
9 Legend
•
47K Posts
0
September 7th, 2017 13:00
SSD Write endurance is likely the issue. If you install on hard drives it will likely be fine.
ParmOligarch
2 Posts
0
September 7th, 2017 22:00
Thanks for looking at this. I've looked into SSD write endurance now, and given it some thought in this case. It's possible, but unlikely. The problem only occurs during the boot sequence. If the drives were approaching their write endurance limit, they would fail in other places too, and not solely during a boot sequence. Both drives fail at the same point in the boot sequence. That suggests to me that the problem lies somewhere in the circuit that controls that. I would assume it is UEFI, but I know little about it.
speedstep
9 Legend
•
47K Posts
1
September 8th, 2017 08:00
UEFI is not hardware its software. Setting Secure Boot OFF and Legacy CSM ON should be more in line with Grub booting.