Hi,
i have just done a test installation of opensuse 12.3 RC1 64 bit on vmware and the installation process has failed, producing an unbootable system.
The partitioning schema is:
All filesystem are ext4 with default settings The partitioning was done within the installation procedure, using yast graphical interface
At the first reboot the system was unbootable, grub2 was not able to find the files it expects in /boot and it ends up in grub recovery mode.
I did some investigations with the opensuse install cd in recovery mode discovering that the problem reside in /dev/md0 not correctly initialized. All the /boot files were in sdb1, but the md0 raid was not initialized and so nothing was written in sda1 which is the boot device really addressed by grub2. I manually started /dev/md0 with sdb1 and then i hot added sda1. Sinchronization started and completed few seconds later ( /boot is only 500 MB large). After sync was completed a rebooted the system and grub2 was able to regularly boot the system.
Have someone of you had a similar experience ? I use an Opensuse 12.2 64 bit with an almost identical partitioning schema and i have never had a similar problem.
No, /boot on MD/LVM is not supported. You get something like “Bootloader cannot be installed due to selected partitioning” or like. I’m going to open feature request about it and ping maintainers, but for now if you intend to use YaST2 to manage your system you should place /boot on physical partition.
grub2 itself does support it and you can manually convert /boot to MD after installation. But you still may get issues when bootloader configuration needs to be updated (I played with ESP on MD and it worked but no UEFI menu entry was created. As example).
Are you serious ??? I have been using /boot on MD raid1 since 2008 on various redhat based distros. And in this moment i’m using an opensuse 12.2 64 bit which has booted from a MD raid1 /boot partition! I’m very surprised of this limitation! How can an enterspire class linux distribution like Suse nowadays not considering the need to boot from a redundant software raid partition! (please note: /boot is using only MD, “/” instead is using LVM on top of MD)
I’m glad to hear that you can open a feature request, thank you very much! I don’t think anything special is required because, as you said in your post, grub2 already support it (also grub1 support it very well) and you only have to pay attention in writing MBR code on both raid 1 member allowing the system to boot also when sda is failed. I’ have not any experience with UEFI bios so i don’t know how complex could be booting from a raid1 volume.
Do you know where can i read something about partitioning schema officialy supported by openSuSE 12.2/12.3 rc1?
How can an enterspire class linux distribution like Suse
openSUSE != SUSE
enterprise class distribution is usually installed on hardware RAID and this is non-issue. And last time I tested RHEL on MD RAID1 it did not boot when one disk was missing (granted, it has been fixed since then).
I don’t think anything special is required
Well … I like your optimistic attitude
grub2 already support it
I said only that grub2 supports /boot on MD. Setting up system to actually boot from it (and more importantly - to ensure it still boots when one drive fails) - is a bit more involving.
(also grub1 support it very well)
Legacy GRUB has no idea about MD at all. Do not confuse ability to install legacy grub on MD RAID1 by abusing device.map with support. Just think about using RAID5 for your array …
and you only have to pay attention in writing MBR code on both raid 1 member
I like this only
Do you know where can i read something about partitioning schema officialy supported by openSuSE 12.2/12.3 rc1?
Not really. This is from experience (I just today had to test something on 12.3 and got into the same situation where yast2-bootloader did not work because of /boot on md1).
I’m sorry, english is not my native language (as you can easily guess), i did not mean to minimize the effort needed to implement the ability to boot from software raid1. I’m aware of the complexity behind a feature like that. What really surprised me is that openSuSE nowadays still does not support it because, i’m absolutely sure, redhat based distro can boot from MD raid 1 since long time ago, also when a disk is missing (i personally verified on centos 5.x, fedora 12, 13 and 14).
By the way i’m going to do some more tests to verify yast2-bootloader functionality, to give you some more elements.
Legacy GRUB has no idea about MD at all. Do not confuse ability to install legacy grub on MD RAID1 by abusing device.map with support. Just think about using RAID5 for your array …
Yes you are right, legacy grub simply ignore raid and boot the partition accessing it directly.
As an afterthought - it is quite possible that openSUSE does support RAID1 using legacy grub. I tested almost exclusively grub2 since 12.2. So we both may be correct in this case.
In any case I appreciate your efforts and your feedback on level of MD RAID support. Thank you!
You are definitively right! Booting from an MD raid1 /boot partition is not supported at all. I verified that grub2 was NOT installed on all the array members, but only on /dev/sda. Obviously the system is not able to boot when sda is not available. yast installer is not able to correctly manage /boot on md raid1.
I’m going to try an installation using grub legacy, i will let you know the result!
Lack of this ability is really a problem for me. I’m evaluating openSuSE because i want to definitively abandon Fedora and its crazy life cycle and bug management. I was really impressed by opensuse distro and its community. But software raid1 support is an essential feature for me, all my hardware was thought with this in mind. I have been testing opensuse since a couple of month ago but honestly i have not really tested this functionality until now! In this moment i’m using a pc which I had “supposed” it was working fine, but that’s not the truth! I’m really confused.
I really hope this feature will be considered in future release.
This might be of interest. It is a scratch machine that is using two reclaimed (from the bin) drives. /dev/sdb1 has several corrupt sectors (getting worse). It can boot from /dev/sda1, but not from /dev/sdb1. It was updated from 11.4(Evergreen) to 12.3RC1 using a DVD install. Both / and root are RAID1 (/dev/sdc is an external drive).
alessia:~ # cat /etc/SuSE-release
openSUSE 12.3 (x86_64)
VERSION = 12.3
CODENAME = Dartmouth
alessia:~ # df -lHTx tmpfs
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 1.1G 33k 1.1G 1% /dev
/dev/md0 reiserfs 22G 7.1G 15G 33% /
/dev/sdc1 ext4 493G 383G 85G 82% /mnt/sdc1
/dev/md1 reiserfs 181G 127G 55G 70% /home
alessia:~ # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid10] [raid6] [raid5] [raid4]
md1 : active raid1 sda3[0] sdb3[1]
176602472 blocks super 1.0 [2/2] [UU]
bitmap: 0/169 pages [0KB], 512KB chunk
md0 : active raid1 sda1[0] sdb1[1]
20972752 blocks super 1.0 [2/2] [UU]
bitmap: 1/161 pages [4KB], 64KB chunk
alessia:~ # fdisk -l
Disk /dev/sda: 203.9 GB, 203928109056 bytes
255 heads, 63 sectors/track, 24792 cylinders, total 398297088 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x31c3275a
Device Boot Start End Blocks Id System
/dev/sda1 * 3132675 45078389 20972857+ fd Linux raid autodetect
/dev/sda2 1028160 3132674 1052257+ 82 Linux swap / Solaris
/dev/sda3 45078390 398283479 176602545 fd Linux raid autodetect
Partition table entries are not in disk order
Disk /dev/sdb: 203.9 GB, 203928109056 bytes
255 heads, 63 sectors/track, 24792 cylinders, total 398297088 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000cd283
Device Boot Start End Blocks Id System
/dev/sdb1 * 63 41945714 20972826 fd Linux raid autodetect
/dev/sdb2 41945715 44050229 1052257+ 82 Linux swap / Solaris
/dev/sdb3 44050230 398283479 177116625 fd Linux raid autodetect
Disk /dev/md0: 21.5 GB, 21476098048 bytes
2 heads, 4 sectors/track, 5243188 cylinders, total 41945504 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0688d239
Device Boot Start End Blocks Id System
Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xd1ba9f1a
Device Boot Start End Blocks Id System
/dev/sdc1 63 976768064 488384001 83 Linux
Disk /dev/md1: 180.8 GB, 180840931328 bytes
2 heads, 4 sectors/track, 44150618 cylinders, total 353204944 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x33322a4d
Device Boot Start End Blocks Id System
YaST (text mode) | System | Boot Loader
shows a dialogue
Because of the partitioning, the boot loader cannot be installed properly.
On 2013-02-22 09:26, eng-int wrote:
> This might be of interest. It is a scratch machine that is using two
> reclaimed (from the bin) drives. /dev/sdb1 has several corrupt sectors
> (getting worse). It can boot from /dev/sda1, but not from /dev/sdb1. It
> was updated from 11.4(Evergreen) to 12.3RC1 using a DVD install. Both /
> and root are RAID1 (/dev/sdc is an external drive).
Installing on a system on which a disk has corrupt sectors on the
increase is highly problematic. A nightmare, actually.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
I have just tried to manually install grub2 on the secondary mbr (/dev/sdb) without any change to grub configuration and, apparently, the system was able to boot without the first hd.
I’m going to do more tests to be sure this can be a reasonably safe procedure to have /boot on a raid partition. I also would like to test a legacy grub installation, to see if yast is able to manage it.
I will let you know the result.
Of course i continue to think that this should be a feature completely and transparently managed by yast and other admin tools as in other distro.
