[opensuse] grub2 and partitioning questions
I am having difficulty getting grub2 installed properly on a new system with oss 13.2. Here is the saga so far: Setup: Machine with 4 SATA disks of 500 GB each. All disks have a GPT partition table. Machine is not using EFI. Goal: Have minimum number of partitions (no separate home, var etc). Be able to fully withstand single disk failure (so swap and /boot, if separate partition, have to be protected). Use only software components (md raid). Have as much of the filesystem(s) on btrfs as possible. Attempt 1: A) Created a 4 GB md raid partition on all 4 disks, and then created md raid 5 across them. This was for swap. B) Created another md raid partition on all remaining disks, and made that raid 5 for / with btrfs. Results: Machine would not boot, could not install grub2 from rescue mode. Finally gave up and went to attempt 2. Attempt 2: A) Create a 256 MB md raid partition on all 4 disks. B) Create raid 1 md0 from /dev/sda1 + /dev/sdb1. Format this as ext4 for /boot. B) Create raid 1 md1 from /dev/sdc1 + /dev/sdd1. Format this as ext4 for /boot1. This is just to keep disk layout on all 4 disks the same, and perhaps involves some dreams of later mirroring /boot to ./boot1 C) Create 2 GB md raid partition on all 4 disks and use it as raid 5 swap. This is md2. D) Create md raid partition using all remaining space on all 4 disks, and make it raid 5 btrfs for /. This is md3 Results: Machine does not boot. Attempting to install grub2 from rescue mode produces various errors (depending on device that the install is attempted on). I booted the system into rescue mode, mounted /boot and / and then chrooted to it (with appropriate binds for /proc, /dev etc). Attempts to install grub2 and results are below: Command: grub2-install --recheck /dev/sda1 Results: Installing for i386-pc platform. grub2-install: warning: File system `ext2' doesn't support embedding. grub2-install: error: embedding is not possible, but this is required for RAID and LVM install. Command: grub2-install --recheck /dev/sda Results: Installing for i386-pc platform. grub2-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. grub2-install: error: embedding is not possible, but this is required for RAID and LVM install. Command: grub2-install --recheck /dev/md0 Results: Installing for i386-pc platform. grub2-install: warning: File system `ext2' doesn't support embedding. grub2-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. grub2-install: error: will not proceed with blocklists. Is the setup described in attempt 1 sane? I did not think it was and went with the setup in attempt 2. I ~think~ it is sane, but I am new to btrfs and grub2. fwiw, I have multiple machines with oss131 running legacy grub with /boot, swap, and root on md raid with lvm on top and ext4 on top of that running just fine. Any help in moving forward is much appreciated. -- --Moby They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Have you considered using not using GPT? I don't see any point for HDs smaller than the BIOS maximum. Have you considered not using md devices for /boot and/or swap? The HDs I create md devices from have ordinary (primary) partitions for boot (with EXT2, where I install Grub), and for swap. Grub2 tries hard to thwart attempts to install to a partition. It's pretty good at it. For 13.2 installations I partition first, then install Grub Legacy, then install openSUSE with *no* bootloader, taboo os-prober, and ensure Grub Legacy is installed. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/22/2014 11:08 PM, Felix Miata wrote:
Have you considered using not using GPT? I don't see any point for HDs smaller than the BIOS maximum.
Have you considered not using md devices for /boot and/or swap? The HDs I create md devices from have ordinary (primary) partitions for boot (with EXT2, where I install Grub), and for swap.
Grub2 tries hard to thwart attempts to install to a partition. It's pretty good at it. For 13.2 installations I partition first, then install Grub Legacy, then install openSUSE with *no* bootloader, taboo os-prober, and ensure Grub Legacy is installed. Thanks Felix. Yes, I definitely have no need for GPT and will not use if I end up re-installing. In all honesty I did not even realize the system was using GPT until I started trying to fix grub2.
The reason I like md for swap is to not have a kernel panic if machine is swapping and a swap disk croaks. I am not full sure, but I think in that case one could risk a machine or process crash. Reason for using md for boot is again to handle disk failure. If a disk croaks and machine has to be rebooted prior to replacing the disk, my hope (never tried it) is that the machine could be booted off the remaining partner of the mirror. From what you say, is it correct then that you do not use grub2 at all with 13.2? Barring any ideas presented here on how to move forward, I will follow your recommendations (mostly) and go without GPT, and grub legacy. How do you partition and install grub legacy with no opensuse, and then how do you install opensuse without a bootloader? Are there options in the installer to perform each of these actions? Thanks again for the ideas. -- --Moby They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Moby composed on 2014-12-22 23:50 (UTC-0600):
Yes, I definitely have no need for GPT and will not use if I end up re-installing. In all honesty I did not even realize the system was using GPT until I started trying to fix grub2.
The reason I like md for swap is to not have a kernel panic if machine is swapping and a swap disk croaks. I am not full sure, but I think in that case one could risk a machine or process crash.
With the amount of RAM people install any more, the risk of disk failure while swap is actually in use should be infinitesimal for all but the most demanding uses.
Reason for using md for boot is again to handle disk failure. If a disk croaks and machine has to be rebooted prior to replacing the disk, my hope (never tried it) is that the machine could be booted off the remaining partner of the mirror.
I separately install Grub on the "/boot" partitions on each HD, but mounting only one of the two (sda1, or neither) as boot, and the other(s) elsewhere. That means manual maintenance (which I don't mind doing), including the Grub Legacy shell (familiar), as little as it ever needs doing. I actually use the Grub shell a lot, and Grub scripts rarely.
From what you say, is it correct then that you do not use grub2 at all with 13.2?
The only things around here allowed to install Grub2 are *buntus, which get installed and used rather infrequently. The Debian installer always miswrites every extended partition's partition table entry, which to repair most easily requires deleting and recreating the first logical partition in order to prevent conforming tools used later from reporting and possibly being halted by partition table errors.
Barring any ideas presented here on how to move forward, I will follow your recommendations (mostly) and go without GPT, and grub legacy. How do you partition and install grub legacy with no opensuse, and then how do you install opensuse without a bootloader?
Partitioning I always do in advance of starting any operating system's installation program. I use DFSee for partitioning, in part because it provides functionally and UI identical binaries for DOS, Linux, Mac, OS/2 and Windows, so it works the same regardless what I've booted. With an empty HD, I usually boot a Knoppix (the original and still the best live Linux) CD or DVD to run DFSee, create filesystems on partitions where Grub will go, then install Grub and WinDOS-compatible MBR code. YaST will still maintain Grub Legacy and menu.lst. The openSUSE installer simply doesn't offer an option to install it any more. Grub2 is so much more powerful (aka complicated, and still evolving) that the YaST maintainers use all their available time just to keep the code working with it.
Are there options in the installer to perform each of these actions?
Grub Legacy can be installed, but I don't know if it can be setup while the openSUSE installer is running. 13.2's installer only offers two bootloader options, Grub2, and no bootloader. Before you jump completely into doing things my way, at least think about trying what Andrei suggested first. That path should be supported, or at least supportable, while mine requires some extra knowledge and hands-on, FOSS *my* way, controlled more by me and less by script writers. :-) -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/23/2014 04:50 PM, Moby wrote:
On 12/22/2014 11:08 PM, Felix Miata wrote:
Have you considered using not using GPT? I don't see any point for HDs smaller than the BIOS maximum.
Have you considered not using md devices for /boot and/or swap? The HDs I create md devices from have ordinary (primary) partitions for boot (with EXT2, where I install Grub), and for swap.
Grub2 tries hard to thwart attempts to install to a partition. It's pretty good at it. For 13.2 installations I partition first, then install Grub Legacy, then install openSUSE with *no* bootloader, taboo os-prober, and ensure Grub Legacy is installed. Thanks Felix. Yes, I definitely have no need for GPT and will not use if I end up re-installing. In all honesty I did not even realize the system was using GPT until I started trying to fix grub2.
The reason I like md for swap is to not have a kernel panic if machine is swapping and a swap disk croaks. I am not full sure, but I think in that case one could risk a machine or process crash.
Reason for using md for boot is again to handle disk failure. If a disk croaks and machine has to be rebooted prior to replacing the disk, my hope (never tried it) is that the machine could be booted off the remaining partner of the mirror.
From what you say, is it correct then that you do not use grub2 at all with 13.2?
Barring any ideas presented here on how to move forward, I will follow your recommendations (mostly) and go without GPT, and grub legacy. How do you partition and install grub legacy with no opensuse, and then how do you install opensuse without a bootloader? Are there options in the installer to perform each of these actions?
Thanks again for the ideas.
I have been 'following' this thread but as I am not using a RAID setup I cannot offer help. However, I would suggest that you download and burn to a CD the SYSTEMRESCUECD ( http://www.sysresccd.org/SystemRescueCd_Homepage ) which is invaluable when striking problems when installing openSUSE 13.2 and Tumbleweed. Tumbleweed (and, from memory, 13.2) INSIST that the boot goes into an available EXTENDED partition (this is a generalisation and not a given) so you need to check which partition has had the 'boot' flag assigned to it. To check the 'boot' flag, use gparted in SRC: gparted>select a partition>Partition>Manage Flags then delete/assign the flag if it was set incorrectly by the YaST bootloader. BC -- Using openSUSE 13.1, KDE 4.14.3 & kernel 3.18.1-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Dec 23, 2014 at 7:44 AM, Moby
Command: grub2-install --recheck /dev/sda Results: Installing for i386-pc platform. grub2-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. grub2-install: error: embedding is not possible, but this is required for RAID and LVM install.
To install grub2 for BIOS booting on GPT disk you need to do what error message tells you - create small BIOS Boot partition where grub2 core.img (analog of grub legacy stage1.5) is stored. This partition should not have any filesystem or be part of Linux MD RAID. It is small; 1MB is more than enough today; 10MB is likely enough for any foreseeable future. You can create this partition using parted or gdisk. You would need to have BIOS Boot partition on every disk you want to install bootloader. grub2 will have to be installed separately on each disk then. It makes sense to install bootloader on every disk that is part of RAID where /boot/grub2 is located, as long as BIOS can boot from each disk.
Command: grub2-install --recheck /dev/md0
That is going to work only if your Linux MD RAID is recognized by BIOS, which means it is actually fake RAID, not software RAID. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/23/2014 12:22 AM, Andrei Borzenkov wrote:
On Tue, Dec 23, 2014 at 7:44 AM, Moby
wrote: Command: grub2-install --recheck /dev/sda Results: Installing for i386-pc platform. grub2-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. grub2-install: error: embedding is not possible, but this is required for RAID and LVM install.
To install grub2 for BIOS booting on GPT disk you need to do what error message tells you - create small BIOS Boot partition where grub2 core.img (analog of grub legacy stage1.5) is stored. This partition should not have any filesystem or be part of Linux MD RAID. It is small; 1MB is more than enough today; 10MB is likely enough for any foreseeable future.
You can create this partition using parted or gdisk.
You would need to have BIOS Boot partition on every disk you want to install bootloader. grub2 will have to be installed separately on each disk then. It makes sense to install bootloader on every disk that is part of RAID where /boot/grub2 is located, as long as BIOS can boot from each disk.
Command: grub2-install --recheck /dev/md0 That is going to work only if your Linux MD RAID is recognized by BIOS, which means it is actually fake RAID, not software RAID. Thanks Andrei. Still trying to do it the newbie way (using yast and installer options instead of using, say, live knoppix to create my partitioning scheme as Felix does), I created a 10 MiB partition on all disks and set it's type to BIOS-Grub. Then I created a second partition on all disks of 2 GiB and made that a RAID 5 for swap, then created a third partition of all remaining space on all disks and made it BtrFS /. Going to the bootloader section of the installer, I see a warning that bootloader cannot be installed due to my paritioning scheme, and the 10 MiB /dev/sda1 (and sdb1, sdc1, sdd1) are not even listed in the installer to install the bootloader on. Other partitions are listed in the choices to install the bootloader on.
Am I driving the installer wrong, or is the above setup possible but just not possible to achieve through the installer and I need to create the scheme using something like live knoppix? Thanks for all btw who provided much knowledge for me. -- --Moby They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Tue, 23 Dec 2014 21:38:32 -0600
Moby
On 12/23/2014 12:22 AM, Andrei Borzenkov wrote:
On Tue, Dec 23, 2014 at 7:44 AM, Moby
wrote: Command: grub2-install --recheck /dev/sda Results: Installing for i386-pc platform. grub2-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. grub2-install: error: embedding is not possible, but this is required for RAID and LVM install.
To install grub2 for BIOS booting on GPT disk you need to do what error message tells you - create small BIOS Boot partition where grub2 core.img (analog of grub legacy stage1.5) is stored. This partition should not have any filesystem or be part of Linux MD RAID. It is small; 1MB is more than enough today; 10MB is likely enough for any foreseeable future.
You can create this partition using parted or gdisk.
You would need to have BIOS Boot partition on every disk you want to install bootloader. grub2 will have to be installed separately on each disk then. It makes sense to install bootloader on every disk that is part of RAID where /boot/grub2 is located, as long as BIOS can boot from each disk.
Command: grub2-install --recheck /dev/md0 That is going to work only if your Linux MD RAID is recognized by BIOS, which means it is actually fake RAID, not software RAID. Thanks Andrei. Still trying to do it the newbie way (using yast and installer options instead of using, say, live knoppix to create my partitioning scheme as Felix does), I created a 10 MiB partition on all disks and set it's type to BIOS-Grub. Then I created a second partition on all disks of 2 GiB and made that a RAID 5 for swap, then created a third partition of all remaining space on all disks and made it BtrFS /. Going to the bootloader section of the installer, I see a warning that bootloader cannot be installed due to my paritioning scheme, and the 10 MiB /dev/sda1 (and sdb1, sdc1, sdd1) are not even listed in the installer to install the bootloader on. Other partitions are listed in the choices to install the bootloader on.
You do not install grub2 *on* this partition. You install grub2 on whole device (grub2-install /dev/sda) and it will write it into dedicated partition.
Am I driving the installer wrong, or is the above setup possible but just not possible to achieve through the installer and I need to create the scheme using something like live knoppix?
Thanks for all btw who provided much knowledge for me.
If you want to have bootloader redundancy, installer supports Linux MD RAID1. Even in this case you still need to manually enable it in yast bootloader configuration. Then installer will write bootloader to both disks. Installer likely does not support more complicated configurations; nor am I sure whether this was tested with GPT. Otherwise you should be able to manually set /dev/sda as bootloader device. It may be possible to select multiple disks (/dev/sda, /dev/sdb, ...), I have not tried it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/23/2014 10:01 PM, Andrei Borzenkov wrote:
В Tue, 23 Dec 2014 21:38:32 -0600 Moby
пишет: On 12/23/2014 12:22 AM, Andrei Borzenkov wrote:
On Tue, Dec 23, 2014 at 7:44 AM, Moby
wrote: Command: grub2-install --recheck /dev/sda Results: Installing for i386-pc platform. grub2-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. grub2-install: error: embedding is not possible, but this is required for RAID and LVM install.
To install grub2 for BIOS booting on GPT disk you need to do what error message tells you - create small BIOS Boot partition where grub2 core.img (analog of grub legacy stage1.5) is stored. This partition should not have any filesystem or be part of Linux MD RAID. It is small; 1MB is more than enough today; 10MB is likely enough for any foreseeable future.
You can create this partition using parted or gdisk.
You would need to have BIOS Boot partition on every disk you want to install bootloader. grub2 will have to be installed separately on each disk then. It makes sense to install bootloader on every disk that is part of RAID where /boot/grub2 is located, as long as BIOS can boot from each disk.
Command: grub2-install --recheck /dev/md0 That is going to work only if your Linux MD RAID is recognized by BIOS, which means it is actually fake RAID, not software RAID. Thanks Andrei. Still trying to do it the newbie way (using yast and installer options instead of using, say, live knoppix to create my partitioning scheme as Felix does), I created a 10 MiB partition on all disks and set it's type to BIOS-Grub. Then I created a second partition on all disks of 2 GiB and made that a RAID 5 for swap, then created a third partition of all remaining space on all disks and made it BtrFS /. Going to the bootloader section of the installer, I see a warning that bootloader cannot be installed due to my paritioning scheme, and the 10 MiB /dev/sda1 (and sdb1, sdc1, sdd1) are not even listed in the installer to install the bootloader on. Other partitions are listed in the choices to install the bootloader on.
You do not install grub2 *on* this partition. You install grub2 on whole device (grub2-install /dev/sda) and it will write it into dedicated partition.
Am I driving the installer wrong, or is the above setup possible but just not possible to achieve through the installer and I need to create the scheme using something like live knoppix?
Thanks for all btw who provided much knowledge for me.
If you want to have bootloader redundancy, installer supports Linux MD RAID1. Even in this case you still need to manually enable it in yast bootloader configuration. Then installer will write bootloader to both disks. Installer likely does not support more complicated configurations; nor am I sure whether this was tested with GPT.
Otherwise you should be able to manually set /dev/sda as bootloader device. It may be possible to select multiple disks (/dev/sda, /dev/sdb, ...), I have not tried it.
Thanks gain Andrei. It appears the YaST installer warning was scaring me needlessly. Proceeding despite the warning led me to a perfectly working system with settings of my first choice. I have the system working now with GPT partition tables on all 4 disks and grub2. The layout is as follows: One 10 MiB partition on all 4 disks of type BIOS GPT. One 2 GiB Linux RAID partition on all 4 disks. This is then made into a RAID 5 device for swap. All remaining space on all 4 disks is partitioned into Linux RAID partitions. These are than setup as a RAID 5 BtrFS for /. Grub2 is installed on /dev/sda, /dev/sdb, /dev/sdc, and /dev/sdd. The machine is now up and running fine and pretty soon I will start some resiliency testing on it (hot swapping disks, having array survive disk failure, having machine boot minus sda, etc). The hope is that the machine can keep on running and be bootable minus one disk. Fwiw, the eventual goal is to use this type of setup as a Windows Active Diretory integrated (With samba) file server. Thanks again to all for valuable tips and insights. -- --Moby They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Dec 24, 2014 at 10:16 AM, Moby
Grub2 is installed on /dev/sda, /dev/sdb, /dev/sdc, and /dev/sdd.
Did you verify it? Look at first sector of each disk (dd if=/dev/sd[abcd] count=1 | xxd) - do they look the same? Do they have string GRUB somewhere? This was the problem with RAID1 - boot block was installed on just one disk, so second disk was not bootable. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/24/2014 01:22 AM, Andrei Borzenkov wrote:
On Wed, Dec 24, 2014 at 10:16 AM, Moby
wrote: Grub2 is installed on /dev/sda, /dev/sdb, /dev/sdc, and /dev/sdd.
Did you verify it? Look at first sector of each disk (dd if=/dev/sd[abcd] count=1 | xxd) - do they look the same? Do they have string GRUB somewhere?
This was the problem with RAID1 - boot block was installed on just one disk, so second disk was not bootable.
Thanks for the heads up, checking showed that only /dev/sda had grub2! However, executing grub2-install /dev/sd[bcd] fixed that and now the output of your test mentioned above is identical on all 4 disks. Good catch! -- --Moby They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Dec 24, 2014 at 10:31 AM, Moby
Thanks for the heads up, checking showed that only /dev/sda had grub2!
How did you configure during installation? Did you explicitly selected device(s) to install bootloader or used whatever installer decided? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/24/2014 01:38 AM, Andrei Borzenkov wrote:
On Wed, Dec 24, 2014 at 10:31 AM, Moby
wrote: Thanks for the heads up, checking showed that only /dev/sda had grub2! How did you configure during installation? Did you explicitly selected device(s) to install bootloader or used whatever installer decided? Installer had picked /dev/sda and I went with that. I did look at the choices available and choices were /dev/sd[abcd], /dev/sd[abcd]2, and /dev/sd[abcd]3. There was no way to pick multiples.
-- --Moby First they came for the Jews and I did not speak out because I was not a Jew. Then they came for the Communists and I did not speak out because I was not a Communist. Then they came for the trade unionists and I did not speak out because I was not a trade unionist. Then they came for me and there was no one left to speak out for me. -- Pastor Martin Niemöller -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Dec 24, 2014 at 10:47 AM, Moby
On 12/24/2014 01:38 AM, Andrei Borzenkov wrote:
On Wed, Dec 24, 2014 at 10:31 AM, Moby
wrote: Thanks for the heads up, checking showed that only /dev/sda had grub2!
How did you configure during installation? Did you explicitly selected device(s) to install bootloader or used whatever installer decided?
Installer had picked /dev/sda and I went with that. I did look at the choices available and choices were /dev/sd[abcd], /dev/sd[abcd]2, and /dev/sd[abcd]3. There was no way to pick multiples.
Yes, someone probably needs to open feature request for it. In the meantime you can try to add other devices to /etc/default/grub_installdevice - for all I know update-bootloader (program that actually writes bootloader to disk) should support it. It will ensure that in case of grub2 update new version will be written to all disks. Check with "update-bootloader --reinit". It may confuse yast though ... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Dec 24, 2014 at 10:47 AM, Moby
wrote: On 12/24/2014 01:38 AM, Andrei Borzenkov wrote:
On Wed, Dec 24, 2014 at 10:31 AM, Moby
wrote: Thanks for the heads up, checking showed that only /dev/sda had grub2! How did you configure during installation? Did you explicitly selected device(s) to install bootloader or used whatever installer decided? Installer had picked /dev/sda and I went with that. I did look at the choices available and choices were /dev/sd[abcd], /dev/sd[abcd]2, and /dev/sd[abcd]3. There was no way to pick multiples.
Yes, someone probably needs to open feature request for it. In the meantime you can try to add other devices to /etc/default/grub_installdevice - for all I know update-bootloader (program that actually writes bootloader to disk) should support it. It will ensure that in case of grub2 update new version will be written to all disks. Check with "update-bootloader --reinit". It may confuse yast though ... I shall look into that shortly. I just completed testing by removing various disks and rebooting the machine and re-adding the disks back to
On 12/24/2014 01:53 AM, Andrei Borzenkov wrote: the raid5 md device, and it all worked fine. Machine was able to boot fine with degraded with /dev/sda gone. After booting, I was able to add the device back and rebuild the array fine. -- --Moby First they came for the Jews and I did not speak out because I was not a Jew. Then they came for the Communists and I did not speak out because I was not a Communist. Then they came for the trade unionists and I did not speak out because I was not a trade unionist. Then they came for me and there was no one left to speak out for me. -- Pastor Martin Niemöller -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/12/2014 05:44, Moby a écrit :
Any help in moving forward is much appreciated.
I found your setup overly complicated, but given I don't know what is the use of it, I can't juge. the raid is only useful if the disks are hot swappables and the goal is to have permanent service. In this case, the boot system is not a priority :-) - you never reboot. To have a /boot as ext2 out of any raid makes it very easy to backup or fix anything on it. I stopped trust raid when I learned than no raid system (in the basic price list) do control the sanity of *all* the used disks sectors. If you have *two* disks failing at the same time, you are done... and it's not uncommon. so I have *many* backups, on several places, for data security and rebuild my system as new if ever something goes wrong (and for now I build systems on ssd) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Dec 23, 2014 at 11:03 AM, jdd
the raid is only useful if the disks are hot swappables
No; the RAID is useful to avoid *unplanned* downtime. If you cannot afford downtime to replace failed disk, you need hot swappable disks indeed.
I stopped trust raid when I learned than no raid system (in the basic price list) do control the sanity of *all* the used disks sectors. If you have *two* disks failing at the same time, you are done... and it's not uncommon.
As usual it is tradeoff between cost of protection and value of data that is being protected. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/12/2014 09:23, Andrei Borzenkov a écrit :
As usual it is tradeoff between cost of protection and value of data that is being protected.
not really. I have at least as many disks as with a raid, but a power surge wont destroy all (at least a set is not on line nor even at home). the best should to have the two systems, but them it's really expensive (I have a gran total of 17 hard disks for approx 15Tb total data, including backups :-) but why /boot on raid? the /boot disk part will never be damaged, given on such config one boot nearly never... the best could be a sd card with only /boot :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/23/2014 05:58 AM, jdd wrote:
but why /boot on raid? the /boot disk part will never be damaged, given on such config one boot nearly never...
And what if the drive containing /boot failed? RAID is easy to set up and if you're worried about power surges, you should be using a UPS, as you should with any computer containing important data. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/23/2014 02:48 PM, James Knott wrote: > On 12/23/2014 05:58 AM, jdd wrote: >> but why /boot on raid? the /boot disk part will never be damaged, >> given on such config one boot nearly never... > And what if the drive containing /boot failed? > > RAID is easy to set up and if you're worried about power surges, you > should be using a UPS, as you should with any computer containing > important data. > ___________ - and may i please add how good UPS feels with big Car-Battery, or even better with large Marine Deep-Discharge Battery :) ........................... regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/23/2014 05:58 AM, jdd wrote:
Le 23/12/2014 09:23, Andrei Borzenkov a écrit :
As usual it is tradeoff between cost of protection and value of data that is being protected.
not really. I have at least as many disks as with a raid, but a power surge wont destroy all (at least a set is not on line nor even at home).
the best should to have the two systems, but them it's really expensive (I have a gran total of 17 hard disks for approx 15Tb total data, including backups :-)
but why /boot on raid? the /boot disk part will never be damaged, given on such config one boot nearly never...
the best could be a sd card with only /boot :-)
"Expensive" ??!!?? Many of my clients are banks. The expense of downtime or data loss would exceed the cost of "mirrored" equipment or running a 'hot backup' site on another tectonic plate & power grid. Yes they want something that is cost-efficient, but not so much so that it compromises the business survivability. The 9/11 event taught us that! Another of my clients, a high street retailer, has a marketing department running a AIX SP3 multiprocessor rack with a room 12'x60' and a RAID array along the 60' wall. That's just the "big data" used for sales analysis. One holiday w/e when the stores were closed I had to upgrade the microcode on those drives! Six hundred some drives (thank god for perl!) mixed 500G/750G. That was 12 years ago. I hate to think what they have now! Marketing doesn't believe in 'hot backup sites' the way banks do! Basically they NEVER backed up that data. For SMB/home users the large drives and the vendor's shift to drives that don't live forever as the old 20G and 30G drives seem to (we've discussed this before) can be uncomfortable. The problem becomes 'too much" storage, that sucks stuff in, makes backup uncomfortable and crashes the day after warranty runs out. *sigh* I'd run the OS/desktop from one of the 30G drives and everything else NFS'd/mirrored, even at home, but my Dell desktop only takes SATA. I'm experimenting with SATA/ATA converters but they don't seem to want to allow writes. *sigh* -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/12/2014 16:15, Anton Aylward a écrit :
"Expensive" ??!!?? Many of my clients are banks. The expense of downtime or data loss would exceed the cost of "mirrored" equipment or running a 'hot backup' site on another tectonic plate & power grid.
then, why run the server on openSUSE? As I said, I have no way to know what is the OP system for.
For SMB/home users the large drives and the vendor's shift to drives that don't live forever as the old 20G and 30G drives seem to
I always had hard drive failures, randomly and not often (but often at the bad time as always :-()
I'm experimenting with SATA/ATA converters but they don't seem to want to allow writes. *sigh*
?? go through usb adapters... I guess we, at openSUSE deal with home or small business products, not large money capable systems that can afford SLES or SLED the initial problem was grub2 not allowing install on raid.md mix. It's only in this case that I propose to boot, why not on sd card or usb flash key for /boot is nothing more is available (as in all the sata places are used by the raid disks) I certainly wont discuss banks or insurance companies systems jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/23/2014 10:31 AM, jdd wrote:
Le 23/12/2014 16:15, Anton Aylward a écrit :
"Expensive" ??!!?? Many of my clients are banks. The expense of downtime or data loss would exceed the cost of "mirrored" equipment or running a 'hot backup' site on another tectonic plate & power grid.
then, why run the server on openSUSE? As I said, I have no way to know what is the OP system for.
Indeed. For many it seems more to do with salesmen and a "you don't get fired for ..." policies than any rationale. Mind you, it sometimes does work to a rationale: another client is nominally a Microsoft shop in that there is a MS PC on every desk, but the servers are a brace of high end HP machines running SAMBA. More reliable than any PC running MS-Server. Another, a brokerage now taken over by a bank, dumped all its high end SUN workstations running multi-windows brokerage stuff and put in RedHat Linux workstations with bigger screens running equivalent software, even though Linux was unknown elsewhere in the bank. Go figure.
For SMB/home users the large drives and the vendor's shift to drives that don't live forever as the old 20G and 30G drives seem to
I always had hard drive failures, randomly and not often (but often at the bad time as always :-()
Hardware failure is always inconvenient! Always frustrating! Its why we have 'hot spares' and backups and ... Strictly speaking, hardware failure seems to be predictable, if you have the right tools and do the right analysis. I've read of military programs for 'copter maintenance that can predict when something needs replacing with un-nerving accuracy! I'm sure the same could be applied to, for example, disk drives, if one was willing to do the detailed analysis of things like bearing vibration, retry. But is that actually available under SMART?
I'm experimenting with SATA/ATA converters but they don't seem to want to allow writes. *sigh*
?? go through usb adapters...
WTF? These things clip on the back of my ATA drives and let the SATA plug in ... Damn, not enough drive bays in this Dell box!
I guess we, at openSUSE deal with home or small business products, not large money capable systems that can afford SLES or SLED
the initial problem was grub2 not allowing install on raid.md mix. It's only in this case that I propose to boot, why not on sd card or usb flash key for /boot is nothing more is available (as in all the sata places are used by the raid disks)
My big complaint about many of the RAID models is that they require "similar disks". That's why I like LVM and BtrFS. My idea of a proper setup would be to have something like /boot on *every* disk :-) That way, if any disk died (or even a couple) there would still be one to boot from.
I certainly wont discuss banks or insurance companies systems
Why not? Once upon a time, the "Cold War" days, it was the military who paid for an pioneered many of the software techniques and tools we consider normal today. The internet was a DARPA project; accurate GPS was a military feature. A friend has a private single prop 2-seater plane that has C3I/NAV which 25 years ago was developed for the military. Jet engines were originally developed for warplanes. So it goes. These days the people paying for innovation are the consumer giants, of not the likes of Google then the banks and their ilk. Much of what we have in Linux comes from those large firms. One reason I like LVM is that long before it was available for Linux I was using what amounted to the same thing on an large IBM AIX setup, experiment with balancing and load with BD2. Ditto various RAID with IBM, HP. I'm not alone in this learning experience. Many of us here are still in such settings. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward composed on 2014-12-23 10:15 (UTC-0500):
For SMB/home users the large drives and the vendor's shift to drives that don't live forever as the old 20G and 30G drives seem to (we've discussed this before) can be uncomfortable.... *sigh* I'd run the OS/desktop from one of the 30G drives and everything else NFS'd/mirrored, even at home
I remember lots of discussions of non-reliability here, but none suggesting the era of 20G, 30G or 40G being better than others. A 30G may have been the first Quantum PATA I ever had to replace. I have here in my saved for their boards box several HDs in this class, WD300BB 2001-02-08, 20G Fireball Plus AS QMP20000AS, and a 5/8" tall made infamous by high failure rate in Dells 40G DiamondMax Plus 8 2003-10-18. It's the 80Gs, 120Gs and moreso 160Gs that followed that I remember bailing us temporarily out of an era of frequent failures. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/23/2014 12:07 PM, Felix Miata wrote:
Anton Aylward composed on 2014-12-23 10:15 (UTC-0500):
For SMB/home users the large drives and the vendor's shift to drives that don't live forever as the old 20G and 30G drives seem to (we've discussed this before) can be uncomfortable.... *sigh* I'd run the OS/desktop from one of the 30G drives and everything else NFS'd/mirrored, even at home
I remember lots of discussions of non-reliability here, but none suggesting the era of 20G, 30G or 40G being better than others. A 30G may have been the first Quantum PATA I ever had to replace. I have here in my saved for their boards box several HDs in this class, WD300BB 2001-02-08, 20G Fireball Plus AS QMP20000AS, and a 5/8" tall made infamous by high failure rate in Dells 40G DiamondMax Plus 8 2003-10-18.
It's the 80Gs, 120Gs and moreso 160Gs that followed that I remember bailing us temporarily out of an era of frequent failures.
I've got about a dozen 20G and 30G drives pulled from SFF desktops, or are still in ones that are still going strong in my various 'under the desk' services such as DNS/DHCP, mailhub and LDAP/RADIUS. They've outlived a couple of 1T drives that seem to outlast the warranty period by only months. Yes, the 80G-120G I have are reliable, but those are in or from older laptops. They survive other parts of the laptop! I'm of the opinion that about 15-20 years ago engineers were pressured to make production line friendly drives. Last years when I had to take a drive in for recovery I had a long chat with the techs about reliability engineering and how things have changed over the years; it was a revelation. Statistical methods have taken over, not just at the gross level but at the micro level. The larger (>500G) drives are expected to have many defects and the first few tracks contain 'modules' to do with error handling. That's not just the alternate sectors but also the tables and microcode. Personally I think having them at the outer sectors is a bad idea since that's where a head retraction crash will -- as I found and the techs agreed -- cause damage. They said that's what happened to the drive I brought in. If the 'look-aside' stuff had been on the innermost tracks it would have been recoverable. Failure by lack of a robust design? I don't want to sound like a conspiracy nut-job but there was the general observation that modern drives seem engineered to match their warranty period and not much more. There are tales that Hank Ford The First went round to visit a junk yard to see what parts of old Ford cars survived and hence were "over-engineered". Probably apocryphal but it makes a point. I'm sure there would have been a transition point about 15 years ago and a great deal of instability in drive design. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Andrei Borzenkov
-
Anton Aylward
-
Basil Chupin
-
ellanios82
-
Felix Miata
-
James Knott
-
jdd
-
Moby