Thanks Glen for your great help last Sat, and also Daniel's, in finally
figuring out what exactly happened to Justin PC's failure to partition the
SSD for his Linux distro.
Your explanation here in luv main list in clear technical details on the
whole issue is certainly of great value to anyone who encounter similar
issue in future!
I'm sure this tricky problem will be solved on or before our next LUV
On Jun 21, 2015 12:07 AM, "Glenn McIntosh" <neonsignal(a)meme.net.au> wrote:
> > On Jun 14, 2015 11:10 PM, "Justin Fisher" <justinlewisfisher(a)gmail.com
> > <mailto:firstname.lastname@example.org>> wrote:
> > I'm still no further along with this install. I have tried again
> > today with the KXstudio live disc, and for whatever reason the ssd
> > is now no longer being recognized from the live disc and from Win7.
> > The instructions listed in the links you sent I had pretty much
> > already followed as I had used this guide
> On 16/06/15 06:19, Wen Lin wrote:> Are you able to bring just your
> desktop to our Linux Beginners Workshop
> > this coming Sat 20 June? The address is: VPAC 110 Victoria St, Carlton
> > South VIC 3053. Quite a number of us will be there, and can have a
> > closer look at your SSD and troubleshooting.
> Just an update on where things got to with Justin's install:
> He has an SSD (with a Windows install) and 2 hard drives (data only). He
> wanted to add a second SSD with a KXStudio (Ubuntu 14.04 based) install,
> and end up with a dual boot system.
> For some reason the distro wouldn't install with the new SSD on the
> fourth SATA port (failed during partitioning), but after removing the
> other disks and putting the new SSD on the second SATA port, it
> installed fine. Incidentally the BIOS wouldn't allow it to be added to
> the boot list until the distro was installed (presumably a secure boot
> feature). We decided to put grub on the Linux drive so that the Windows
> drive would still have the original boot even if used alone or moved to
> another machine.
> What works: the BIOS can boot to either operating system, with that SSD
> alone; also, with both SSD drives in place, it can boot to Linux.
> What doesn't work: (1) with both SSD drives in place (Windows on the
> first SATA port), an attempt to BIOS boot to Windows appears to start
> the Windows boot ("Windows is loading files"), but then the system boots
> from the other (Linux drive); (2) also, update-grub on the Linux side
> does not find the Windows system. We ran out of time to try adding the
> chainload entry in grub.cfg by hand.
> The Windows drive is GPT partitioned, and the Linux drive is MBR
> partitioned, perhaps that is part of the problem?
> sks-keyservers.net 0x6d656d65
> luv-main mailing list
Wen Lin wrote:
> One key point: *BIOS and UEFI: set it to AHCI*
Unless you're dual-booting, *always* set your SATA controllers to AHCI.
The options "legacy", "hybrid" and "PATA" are worse choices for Linux.
Erratum: current hardware seems to add NVMe, which appears to be better?
> using the parameter 'noatime'.
The default should be relatime (check /proc/mounts),
which should be near enough.
Changing it to noatime will break a handful of programs,
but you probably don't use them anyway.
Thanks for your update. This is great! This means with the newer distros
nowadays, we can basically treat SSD no different from conventional hard
disks - when come to disk partitioning or formatting. I remember 2-3 years
ago when I was installing Ubuntu onto my 2nd generation eeepc with SSD, I
got instructions at the time to skip the swap space all together. Can I
assume that with new distros on SSD - swap space is back in again?
How about the "reserve 7% for overprovisioning" suggestion? Do you think
it is still valid now?
Anyway, the focus for Justin at the moment is to get his SSD to install
Ubuntu 14.04 without error.
Let us know how you go, Justin. :-)
On Mon, Jun 8, 2015 at 11:49 AM, Chris Samuel <chris(a)csamuel.org> wrote:
> Hi Wen, Justin,
> On Mon, 8 Jun 2015 09:01:26 AM Wen Lin wrote:
> > Another key point: A Solid State Drive is worn down relatively quickly by
> > write actions. So this site introduced steps/commands on how to minimise
> > the action of writing to SSD by turning off the updating whenever a file
> > read (last accessed time) - using the parameter 'noatime'.
> That's out of date - the kernel already defaults to "relatime" (since
> released 6 years ago pretty much today), Red Hat describe it thus:
> # Relatime maintains atime data, but not for each time that a file
> # is accessed. With this option enabled, atime data is written to
> # the disk only if the file has been modified since the atime data
> # was last updated (mtime), or if the file was last accessed more
> # than a certain length of time ago (by default, one day).
> So in other words for files that aren't being written you'll get an
> atime update at most once a day on reading it.
> commit 0a1c01c9477602ee8b44548a9405b2c1d587b5a2
> Author: Matthew Garrett <mjg(a)redhat.com>
> Date: Thu Mar 26 17:53:14 2009 +0000
> Make relatime default
> Change the default behaviour of the kernel to use relatime for all
> filesystems. This can be overridden with the "strictatime" mount
> Signed-off-by: Matthew Garrett <mjg(a)redhat.com>
> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
> Best of luck!
> Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC