Re: SDD puzzle -- *maybe* solved

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



said Dr. Nikolaus Klepp:
| Anno domini 2021 Fri, 20 Aug 13:40:03 +0000
|
|  dep scripsit:

| > If it boots reliably from sdc1, as it does now, why would I want to do
| > that?
|
| Good question :) Let's call it habit. When you have more than one
| computer with more than one harddrive and each of them may or may not be
| able to boot from each harddive it's good to ensure that each machine
| can boot from the first device on sata1, otherwise you start cursing
| your younger self for beeing such a moron playing the
| find-the-boot-drive-guess-game with your older self.

I have this thing on my hard drives called GRUB that presents upon reboot a
selection from which I can choose.<g> And I'm not running a computer farm
here -- keeping track of which is which is pretty easy.

| > | And get rid of the old OS on sda1 :)
| >
| > I may not have been clear as to my purpose. The OS on sda1 is
| > *identical* to the one on the SSD, sdc1. I hope to take advantage of
| > the improved speed of the SSD, but I do not utterly trust SSDs (nor
| > hard drives, but I come closer to trusting those). By having both,
| > should the SSD fail I can simply boot an identical system by making
| > that choice in the GRUB menu. So in this case it really is a feature,
| > not a bug.
|
| Sure. But why not put that (old) sda in cold storage? In your scenario
| you won't need it till things get "interesting". Or do you plan to keep
| both devices in sync? e.g. do any config twice, repeate any os upgrade?

There are several reasons. The first is that the machine would be limited
in its usefulness without a /home directory, which resides on the 6tb
sda1. Yes, I coupld move cables around, after which I could also spend
hours changing links that rely currently on it being on sda1 and on the
other drives that rely on their being where they currently are.

And yes, I do intend to keep them in sync, which simply requires booting to
the hard drive once every couple of weeks and doing an #apt update and
upgrade. Most configurations I need to do are in userspace, and in that
both boot partitions point to the same ~/, the configurations will work on
either one. The switch to SSD for daily use as / is a calculated tradeoff
of reliability for speed, and maintaining a boot partition on sda1 -- as
you note, the default for most everybody -- is a way of mitigating the
risk. In that I'm often on deadline, the ability to keep going despite an
SSD failure and dealing with a failed SSD at my later convenience is
preferable to going to cold storage and taking the computer apart, then
updating the Linux onboard, before I can do what I need to do right now.
That was my design and, with the help of you and others here, I've been
able to achieve it. (The problem at the top of this thread, it's now
pretty clear, was due to the BIOS being . . . awful.)

And I don't do a full OS upgrade all that often, every couple of years at
most. I used to get all excited and burn every new kernel that Linus
released -- I remember the exciting Christmas of 2000, which I spent
building and testing a release candidate for 2.4.0 (and which I didn't
mind -- the inlaws were visiting) -- but I haven't done that for many
years. Though having a machine like the one I have now would have made
that easier, because I'd have a pretty easy out when the damned new kernel
blew up!
--
dep

Pictures: http://www.ipernity.com/doc/depscribe/album
Column: https://ofb.biz/author/dep/
____________________________________________________
tde-users mailing list -- users@xxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxx
Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@xxxxxxxxxxxxxxxxxx




[Index of Archives]     [Trinity Devel]     [KDE]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]     [Trinity Desktop Environment]

  Powered by Linux