Hi everybody,
I have several large disks filled with experiments and multiboots. I need to make changes to the current /boot/grub/grub.cfg but I have no idea which one I'm using or which one of the systems' grub config tools were used so I don't dare just grab any old one and use it
I've searched through seven VolumeGroups full of LogicalVolumes and can't seem to find the one I'm using. Also combed through partitions that are not part of LVM.
Does the boot process leave any footprints behind telling where it booted from?
Rapidly losing what little is left of my mind...
TIA, Mike Wright
On 02/15/2016 06:42 PM, Mike Wright wrote:
Hi everybody,
I have several large disks filled with experiments and multiboots. I need to make changes to the current /boot/grub/grub.cfg but I have no idea which one I'm using or which one of the systems' grub config tools were used so I don't dare just grab any old one and use it
I've searched through seven VolumeGroups full of LogicalVolumes and can't seem to find the one I'm using. Also combed through partitions that are not part of LVM.
Does the boot process leave any footprints behind telling where it booted from?
Rapidly losing what little is left of my mind...
TIA, Mike Wright
Don't know if you have legacy grub or not. With legacy grub, you can change the names in menu.lst--put a 1 or 2 or whatever after the description, and when you start up, the display will let you choose which is which. Your display at boot time will look like:
Fedora 1 Fedora 2 Fedora 3 Windows Mint
and so on.
On 02/15/2016 03:42 PM, Mike Wright wrote:
Hi everybody,
I have several large disks filled with experiments and multiboots. I need to make changes to the current /boot/grub/grub.cfg but I have no idea which one I'm using or which one of the systems' grub config tools were used so I don't dare just grab any old one and use it
I've searched through seven VolumeGroups full of LogicalVolumes and can't seem to find the one I'm using. Also combed through partitions that are not part of LVM.
Does the boot process leave any footprints behind telling where it booted from?
Rapidly losing what little is left of my mind...
You can always "cat /proc/cmdline" to see what the boot command line was. In my case:
[root@prophead ~]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.3.4-200.fc22.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet LANG=en_US.UTF-8
So it booted the 4.3.4-200.fc22.x86_64 kernel (yes, this machine is still F22) and the current /dev/mapper/fedora-root is the root of my filesystem. Digging a bit more:
[root@prophead ~]# ls -l /dev/mapper/fedora-root lrwxrwxrwx. 1 root root 7 Feb 1 15:09 /dev/mapper/fedora-root -> ../dm-1 [root@prophead ~]# ls -l /dev/dm-1 brw-rw----. 1 root disk 253, 1 Feb 1 15:09 /dev/dm-1
So, /dev/mapper/fedora-root is is /dev/dm-1 or device major 253, minor 1. Dig a bit deeper:
[root@prophead ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 500M 0 part /boot └─sda2 8:2 0 931G 0 part ├─fedora-swap 253:0 0 15.6G 0 lvm [SWAP] ├─fedora-root 253:1 0 606.8G 0 lvm / ├─fedora-home 253:2 0 293G 0 lvm /home └─fedora-tmp 253:3 0 15.6G 0 lvm /tmp sdb 8:16 0 465.8G 0 disk └─sdb1 8:17 0 465.8G 0 part /media/500GB-Drive sr0 11:0 1 2K 0 rom
So you can see my boot partition is a plain-old partition on /dev/sda1 and the root filesystem (block device 253:1) is a Linux LVM living on /dev/sda2.
Does that help any? ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - grasshopotomus: A creature that can leap to tremendous heights... - - ...once. - ----------------------------------------------------------------------
On 02/15/2016 04:10 PM, doug wrote:
On 02/15/2016 06:42 PM, Mike Wright wrote:
Does the boot process leave any footprints behind telling where it booted from?
Don't know if you have legacy grub or not. With legacy grub, you can change the names in menu.lst--put a 1 or 2 or whatever after the description, and when you start up, the display will let you choose which is which. Your display at boot time will look like:
Fedora 1 Fedora 2 Fedora 3 Windows Mint
Thanks Doug,
The problem isn't which o/s to boot, but which /boot is being booted from.
On 02/15/2016 04:21 PM, Rick Stevens wrote:
On 02/15/2016 03:42 PM, Mike Wright wrote:
Does the boot process leave any footprints behind telling where it booted from?
You can always "cat /proc/cmdline" to see what the boot command line was. In my case:
[root@prophead ~]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.3.4-200.fc22.x86_64root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet LANG=en_US.UTF-8
So it booted the 4.3.4-200.fc22.x86_64 kernel (yes, this machine is still F22) and the current /dev/mapper/fedora-root is the root of my filesystem. Digging a bit more:
[root@prophead ~]# ls -l /dev/mapper/fedora-root lrwxrwxrwx. 1 root root 7 Feb 1 15:09 /dev/mapper/fedora-root-> ../dm-1 [root@prophead ~]# ls -l /dev/dm-1 brw-rw----. 1 root disk 253, 1 Feb 1 15:09 /dev/dm-1
So, /dev/mapper/fedora-root is is /dev/dm-1 or device major 253, minor
Dig a bit deeper:
[root@prophead ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 500M 0 part /boot └─sda2 8:2 0 931G 0 part ├─fedora-swap 253:0 0 15.6G 0 lvm [SWAP] ├─fedora-root 253:1 0 606.8G 0 lvm / ├─fedora-home 253:2 0 293G 0 lvm /home └─fedora-tmp 253:3 0 15.6G 0 lvm /tmp sdb 8:16 0 465.8G 0 disk └─sdb1 8:17 0 465.8G 0 part /media/500GB-Drive sr0 11:0 1 2K 0 rom
So you can see my boot partition is a plain-old partition on /dev/sda1 and the root filesystem (block device 253:1) is a Linux LVM living on /dev/sda2.
Does that help any?
Hi Rick,
Thanks but not the cigar I was looking for. "lsblk" has 49 entries, none of which are boot which would seem to indicate /boot in question is on the mapped root. But changes made to that grub.cfg don't show up in the options available in the subsequent boot. Since that does seem to be the smoking gun I'll check it again.
On 02/15/2016 04:21 PM, Rick Stevens wrote:
On 02/15/2016 03:42 PM, Mike Wright wrote:
Does the boot process leave any footprints behind telling where it booted from?
So you can see my boot partition is a plain-old partition on /dev/sda1 and the root filesystem (block device 253:1) is a Linux LVM living on /dev/sda2.
Does that help any?
Have reverified what my grub.cfg contains and it is not what is booting. That grub.cfg has only two entries and both are recent kernels.
The one presented on boot offers four entries, all of which are down rev. kernels.
Mysteriouser and mysteriouser.
Does anybody know how to follow the footprints starting with the boot sector?
Allegedly, on or about 15 February 2016, Mike Wright sent:
I have several large disks filled with experiments and multiboots. I need to make changes to the current /boot/grub/grub.cfg but I have no idea which one I'm using or which one of the systems' grub config tools were used so I don't dare just grab any old one and use it
I think the simplest way is to slightly customise each one, so you can see differences in the text. Then match what you see on-screen as you boot, and the files you look at on the drive partitions. Change the text that's for you, without modifying anything that affects how booting works.
Usually, with things like that, I'd look for the kernel version numbers in the grub.conf file, but they don't use a single flat file, any more.
Does the boot process leave any footprints behind telling where it booted from?
I don't think there's an guarantee that what was GRUB's root (which doesn't have to be a "/boot") at boot time remains mounted.
On 02/15/16 17:42, Mike Wright wrote: <>
Hi everybody,
I have several large disks filled with experiments and multiboots. I need to make changes to the current /boot/grub/grub.cfg but I have no idea which one I'm using or which one of the systems' grub config tools were used so I don't dare just grab any old one and use it
I've searched through seven VolumeGroups full of LogicalVolumes and can't seem to find the one I'm using. Also combed through partitions that are not part of LVM.
Does the boot process leave any footprints behind telling where it booted from?
. not sure if i understand question as you meant it, and after reading replies, your question does not full define what you are asking.
from first reading, i am presuming that you want to know which _grub_configuration_ of which installation the boot sector of boot drive is loading.
when i first read your post, my first thought was that you have most likely been using grub config from your first installation and all additional installs are 'chained' to it.
from that something comes to mind is that you _might_ be using a /boot partition that you are defining for all the additional installs. or you are using a boot directory in / root of each install. or you are using a /boot partition for each install.
having followed this thread and noting replies, Rick Stevens, and Tim give replies that should give you answer if you apply both.
1st, following Tim's suggestion, boot into install that you first made. open the grub config file, "/etc/default/grub". just above line with 1st line with "title", insert a new line as;
title main boot
in next "title" line that shows what is booting, change to something like;
title Fedora 23 @ sda 3 (4.3.5-300.fc23)
or where ever it is locate.
save the file, run 'update-grub' to update.
next, mount the other installs and do similar editing of "/etc/default/grub" for fedora installs or what ever flavors you have, making the 1st line's "title" line unique for each install.
reboot system and note what is shown in boot menu.
if you are booting with grub, you can edit "/boot/grub/grub.conf" and apply same basics editing.
Rapidly losing what little is left of my mind...
. welcome to the club.
when ever someone tells me i am crazy, my reply is;
thank you. i am glad you noticed.
much luck.
On 02/15/2016 05:42 PM, Mike Wright wrote:
Hi everybody,
I have several large disks filled with experiments and multiboots. I need to make changes to the current /boot/grub/grub.cfg but I have no idea which one I'm using or which one of the systems' grub config tools were used so I don't dare just grab any old one and use it
I've searched through seven VolumeGroups full of LogicalVolumes and can't seem to find the one I'm using. Also combed through partitions that are not part of LVM.
In GRUB legacy, if you get the boot menu displayed, type "c" to get a "grub>" command prompt, then you can enter the command "root" and see which BIOS drive and partition is being used.
At the GRUB menu, type
pager=1 set
Look for variable 'prefix=' this will be drive, partition, and path, to the GRUB directory where its cfg and modules are found.
Chris Murphy
Allegedly, on or about 15 February 2016, Mike Wright sent:
I have several large disks filled with experiments and multiboots...
Once you sort this out, you want to plan how you do multiboots in the future. Way back when I tried it, and even two is a pain, one good solution was to make your own custom boot partition, and all it did was let you select which partition to boot, it chainloaded the next one.
Whatever the /next/ one was, is a Fedora install with its own boot partition. Whenever that installation does any kernel updates, it only touches files in its own /boot.
Likewise, the alternative /next/ thing to boot, was a CentOS install, with its own boot partition. And whenever it does any kernel updates, it only messes with file in its own /boot.
I treated new installations as if they were a complete new hard drive to themselves, whether that's actually the case (and dedicating a whole drive to an OS tends to be easier), or whether I was halving a drive between two OSs, but still acting as if each OS was the only drive in the box.
Other people eschew multibooting for running virtual machines. In essence, you have a container that pretends its the hard drive for a machine. Everything that instance does to itself, is all within that container.
I've since reclaimed my sanity by not multibooting. I use more than one computer. Much more precise division between things that way.
On 02/16/16 08:29, Robert Nichols wrote: <<>>
In GRUB legacy, if you get the boot menu displayed, type "c" to get a "grub>" command prompt, then you can enter the command "root" and see which BIOS drive and partition is being used.
.
good to know. thanks for posting.
was aware of using;
root (hd2,1)
or some such to change boot partition, but not aware that just "boot" would show which partition was to be booted.
sure does beats what i posted. much easier. ;-)
On 02/16/2016 08:15 AM, Chris Murphy wrote:
At the GRUB menu, type
pager=1 set
Look for variable 'prefix=' this will be drive, partition, and path, to the GRUB directory where its cfg and modules are found.
All right Chris!
While at the boot prompt I have no access to anything and had forgotten the "pager=1" bit so after getting into grub> it was hit or miss with huge text overflowing the screen. By habit I typed ls and don't know if what it did was what I expected but near the bottom of the screen was the prefix= line. Ahhh, serendipity.
I copied, with pencil and paper, the 102 character string, cursing the entire time the genius behind this madness, and rebooted.
A portion of that string, reformatted without slashes and hyphens, was located in one of /dev/disk/by-id's 107 entries and which turned out to be a sym-link to dm-16. dm-16 was claimed by a sym-link in /dev/mapper.
(Editors comment: this crap could only have been created by somebody with a cast of thousands and an unlimited budget and would have gotten an "F" at the Oscars.)
And there was a recognizable quatrain of stanzas minus any commenting other than the title. After editing and changing the module lines to refer to the current kernel (when booting Xen kernels and initrds are modules) I rebooted and... WTF? the original unmodified boot page.
So apparently grub.cfg is ?compiled? into some other secret location know only to the bootloader. I have the sinking feeling I have to run some grub2 magic spell to get the modified boot file into wherever it goes but am loathe to try anything. The reason I have a stripped down grub.cfg is because the last one generated for me was pushing 200K and the boot lines in each stanza had, so help me, nineteen swap files included in each one.
Now the question:
Is there a command that will take my simplified grub.cfg and install it without modifying it in any way and leave me with a bootable system? (please please please say yes).
Thank you everybody for helping get me this far and sorry for the novella.
Mike Wright
ps. extra points to whomever can point me to a simpler disk management system appropriate for somebody with a beer budget who can't afford that cast of thousands and is rapidly running out of time on the top side of the dirt?
On 02/16/2016 08:33 AM, Tim wrote:
Allegedly, on or about 15 February 2016, Mike Wright sent:
I have several large disks filled with experiments and multiboots...
Once you sort this out, you want to plan how you do multiboots in the future. Way back when I tried it, and even two is a pain, one good solution was to make your own custom boot partition, and all it did was let you select which partition to boot, it chainloaded the next one.
That sounds like the ideal approach for what I do. Do you have an example of that you'd be willing to share? I've never used chain loading and have only seen it referenced on this list.
Whatever the /next/ one was, is a Fedora install with its own boot partition. Whenever that installation does any kernel updates, it only touches files in its own /boot.
Likewise, the alternative /next/ thing to boot, was a CentOS install, with its own boot partition. And whenever it does any kernel updates, it only messes with file in its own /boot.
I treated new installations as if they were a complete new hard drive to themselves, whether that's actually the case (and dedicating a whole drive to an OS tends to be easier), or whether I was halving a drive between two OSs, but still acting as if each OS was the only drive in the box.
I use a very similar approach. Since a lot of my installs are intended to be run in a custom Xen environment they can't even single boot but I still need the kernels and initrds to copy elsewhere. The problems arise when the installer does what it thinks is best for me and starts screwing with my LVM setup or goes scarfing through all my disks creating boot stanzas for installations that are incapable of standalone boots. Gets really big and really ugly really fast. I have had much better luck with Ubuntu installers.
Other people eschew multibooting for running virtual machines. In essence, you have a container that pretends its the hard drive for a machine. Everything that instance does to itself, is all within that container.
I've since reclaimed my sanity by not multibooting. I use more than one computer. Much more precise division between things that way.
On Tue, 2016-02-16 at 21:19 -0800, Mike Wright wrote:
Is there a command that will take my simplified grub.cfg and install it without modifying it in any way and leave me with a bootable system? (please please please say yes).
I seem to recall that although GRUB no-longer uses a flat menu file, it can still work that way. Might be worth exploring.
On 02/16/2016 09:19 PM, Mike Wright wrote:
On 02/16/2016 08:15 AM, Chris Murphy wrote:
At the GRUB menu, type
pager=1 set
Look for variable 'prefix=' this will be drive, partition, and path, to the GRUB directory where its cfg and modules are found.
All right Chris!
While at the boot prompt I have no access to anything and had forgotten the "pager=1" bit so after getting into grub> it was hit or miss with huge text overflowing the screen. By habit I typed ls and don't know if what it did was what I expected but near the bottom of the screen was the prefix= line. Ahhh, serendipity.
I copied, with pencil and paper, the 102 character string, cursing the entire time the genius behind this madness, and rebooted.
A portion of that string, reformatted without slashes and hyphens, was located in one of /dev/disk/by-id's 107 entries and which turned out to be a sym-link to dm-16. dm-16 was claimed by a sym-link in /dev/mapper.
(Editors comment: this crap could only have been created by somebody with a cast of thousands and an unlimited budget and would have gotten an "F" at the Oscars.)
And there was a recognizable quatrain of stanzas minus any commenting other than the title. After editing and changing the module lines to refer to the current kernel (when booting Xen kernels and initrds are modules) I rebooted and... WTF? the original unmodified boot page.
So apparently grub.cfg is ?compiled? into some other secret location know only to the bootloader. I have the sinking feeling I have to run some grub2 magic spell to get the modified boot file into wherever it goes but am loathe to try anything. The reason I have a stripped down grub.cfg is because the last one generated for me was pushing 200K and the boot lines in each stanza had, so help me, nineteen swap files included in each one.
Now the question:
Is there a command that will take my simplified grub.cfg and install it without modifying it in any way and leave me with a bootable system? (please please please say yes).
I've never used it, but I suspect grub-menulst2cfg may do what you want. It claims to "Convert a configuration file from GRUB 0.xx to GRUB 2.xx format". If you're going to continue to tinker in this way, you really have to read up on grub2:
http://www.gnu.org/software/grub/manual/grub.html
I agree it's convoluted and confusing and I'm not a fan (just like I'm not a fan of systemd or journald), but that's what you're stuck with.
Most of the config info you may need to change is in /etc/default/grub. The scripts that generate the menu entries are in /etc/grub.d (particularly 10_linux and possibly 40_custom). The final config created by grub2-mkconfig generally ends up in /boot/grub2/grub.cfg.
Dunno if that helps, but... ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - I haven't lost my mind. It's backed up on tape somewhere, but - - probably not recoverable. - ----------------------------------------------------------------------
On Wednesday, February 17, 2016 10:03:04 AM Rick Stevens wrote:
On 02/16/2016 09:19 PM, Mike Wright wrote:
On 02/16/2016 08:15 AM, Chris Murphy wrote:
At the GRUB menu, type
pager=1 set
Look for variable 'prefix=' this will be drive, partition, and path, to the GRUB directory where its cfg and modules are found.
All right Chris!
So apparently grub.cfg is ?compiled? into some other secret location know only to the bootloader. I have the sinking feeling I have to run some grub2 magic spell to get the modified boot file into wherever it goes but am loathe to try anything. The reason I have a stripped down grub.cfg is because the last one generated for me was pushing 200K and the boot lines in each stanza had, so help me, nineteen swap files included in each one.
grub2 uses the file /boot/grub2/grub.cfg by default. This file does get rebuilt by kernel updates, and by running /sbin/grub2-mkconfig
Now the question:
Is there a command that will take my simplified grub.cfg and install it without modifying it in any way and leave me with a bootable system? (please please please say yes).
I've never used it, but I suspect grub-menulst2cfg may do what you want. It claims to "Convert a configuration file from GRUB 0.xx to GRUB 2.xx format". If you're going to continue to tinker in this way, you really have to read up on grub2:
http://www.gnu.org/software/grub/manual/grub.html
I agree it's convoluted and confusing and I'm not a fan (just like I'm not a fan of systemd or journald), but that's what you're stuck with.
Most of the config info you may need to change is in /etc/default/grub. The scripts that generate the menu entries are in /etc/grub.d (particularly 10_linux and possibly 40_custom). The final config created by grub2-mkconfig generally ends up in /boot/grub2/grub.cfg.
If you remove the file /etc/grub.d/30_osprober, then grub2-mkconfig will not look for other operating systems to add to the config file, but will only add the kernels for the current OS. Then if you have a simple chainloader as the initial config that points to each OS, each OS will only have its on entries in its grub.cfg.
Tim:
Once you sort this out, you want to plan how you do multiboots in the future. Way back when I tried it, and even two is a pain, one good solution was to make your own custom boot partition, and all it did was let you select which partition to boot, it chainloaded the next one.
Mike Wright
That sounds like the ideal approach for what I do. Do you have an example of that you'd be willing to share? I've never used chain loading and have only seen it referenced on this list.
Back in the old GRUB 1 days, that was easy enough. And I suppose you could install a version 1 bootloader onto a single /your/ boot partition. It'd be left alone by your installs.
This is from a very old system, which had an entry to chainload from a floppy disk. By using a hd0 instead of fd0 entry, or whatever drive and partition number pertained to the partition that you wanted to boot, you could chainload to another hard drive:
title Fedora Core (2.6.17-1.2142_FC4) root (hd0,0) kernel /vmlinuz-2.6.17-1.2142_FC4 ro root=LABEL=/ acpi=force initrd /initrd-2.6.17-1.2142_FC4.img
title Boot from floppy disk drive lock rootnoverify (fd0) chainloader +1
'twas as simple as that. I'm far from impressed by the incomprehensible mess that GRUB 2 is.
I use a very similar approach. Since a lot of my installs are intended to be run in a custom Xen environment they can't even single boot but I still need the kernels and initrds to copy elsewhere. The problems arise when the installer does what it thinks is best for me and starts screwing with my LVM setup or goes scarfing through all my disks creating boot stanzas for installations that are incapable of standalone boots. Gets really big and really ugly really fast. I have had much better luck with Ubuntu installers.
I think there were options to not probe for other systems. But I haven't done an install for ages.
Of course, if you're going to dedicate an entire hard drive to an installation, the simple solution is to unplug the others while installing. Or, disable their port in the BIOS, temporarily, so they're not found.
Personally, I favoured dedicating whole drives to an install, rather than partition. There's a few advantages: More space for it to use. Very easy to unplug to disable, archive, or transfer. Since I don't install bi-annually, I used to get a new drive for a new install, and try it out independent from prior installs, with it as the sole drive. If it hoses anything, it only does itself. The old drive gets connected, later, data copied over, and the old drive left as an archive.
I never seemed to get a collection of un-used drives, though. It's never long before one gets put into a completely new box, or replaces another drive that's knackered.
time to reminisce.
On 02/17/16 22:11, Tim wrote:
Tim:
Once you sort this out, you want to plan how you do multiboots in the future. Way back when I tried it, and even two is a pain, one good solution was to make your own custom boot partition, and all it did was let you select which partition to boot, it chainloaded the next one.
Mike Wright
That sounds like the ideal approach for what I do. Do you have an example of that you'd be willing to share? I've never used chain loading and have only seen it referenced on this list.
Back in the old GRUB 1 days, that was easy enough. And I suppose you could install a version 1 bootloader onto a single /your/ boot partition. It'd be left alone by your installs.
This is from a very old system, which had an entry to chainload from a floppy disk. By using a hd0 instead of fd0 entry, or whatever drive and partition number pertained to the partition that you wanted to boot, you could chainload to another hard drive:
title Fedora Core (2.6.17-1.2142_FC4) root (hd0,0) kernel /vmlinuz-2.6.17-1.2142_FC4 ro root=LABEL=/ acpi=force initrd /initrd-2.6.17-1.2142_FC4.img
title Boot from floppy disk drive lock rootnoverify (fd0) chainloader +1
'twas as simple as that. I'm far from impressed by the incomprehensible mess that GRUB 2 is.
I use a very similar approach. Since a lot of my installs are intended to be run in a custom Xen environment they can't even single boot but I still need the kernels and initrds to copy elsewhere. The problems arise when the installer does what it thinks is best for me and starts screwing with my LVM setup or goes scarfing through all my disks creating boot stanzas for installations that are incapable of standalone boots. Gets really big and really ugly really fast. I have had much better luck with Ubuntu installers.
I think there were options to not probe for other systems. But I haven't done an install for ages.
Of course, if you're going to dedicate an entire hard drive to an installation, the simple solution is to unplug the others while installing. Or, disable their port in the BIOS, temporarily, so they're not found.
Personally, I favoured dedicating whole drives to an install, rather than partition. There's a few advantages: More space for it to use. Very easy to unplug to disable, archive, or transfer. Since I don't install bi-annually, I used to get a new drive for a new install, and try it out independent from prior installs, with it as the sole drive. If it hoses anything, it only does itself. The old drive gets connected, later, data copied over, and the old drive left as an archive.
I never seemed to get a collection of un-used drives, though. It's never long before one gets put into a completely new box, or replaces another drive that's knackered.
. gone are the 'good old days' of boxes 4 and 5 5" drive bays where one could install install 3" drives in removable drive carriers and swap drives.
Allegedly, on or about 17 February 2016, g sent:
gone are the 'good old days' of boxes 4 and 5 5" drive bays where one could install install 3" drives in removable drive carriers and swap drives.
Yet computer cases are still ridiculously huge...
Most PC cases that I see on sale tend to be desktop towers, with an array of internal bays. And, thankfully, these days they face out sideways, so you don't have to try and manoeuvre a drive out over the top of the motherboard, between the cards, and through the cables.
On Friday 19 Feb 2016 06:41:04 Tim wrote:
Allegedly, on or about 17 February 2016, g sent:
gone are the 'good old days' of boxes 4 and 5 5" drive bays where one could install install 3" drives in removable drive carriers and swap drives.
Yet computer cases are still ridiculously huge...
Most PC cases that I see on sale tend to be desktop towers, with an array of internal bays. And, thankfully, these days they face out sideways, so you don't have to try and manoeuvre a drive out over the top of the motherboard, between the cards, and through the cables.
I like it that way... I have a gaming tower (coolermaster) - [but I dont play games!!] - with loads of room - its on its third motherboard with room for water-cooling if necessary. My disks are easily removable and are in 2 enclosures 1 a single ORICO housing the system disk the other an ORICO 3 drive slot 4 bay hdd internal enclosure. I have a disk array in the 3 bay enclosure. I can swap out/upgrade disks with ease. The disks just slide in or out with ease - no case opening required. I can change components this way and upgrade for many years with minimum fuss. So far from "good old days" - I think this is the way to go if you want a long-term evolving system. Spend some dosh on the enclosure!!!
-
Andy Paterson -
Chris Murphy -
Doug -
g -
Lester M Petrie -
Mike Wright -
Rick Stevens -
Robert Nichols -
Tim