SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
If my understanding is correct, as the kernel won't be able to read RAID 1 directly, the initrd, or initramfs would have to be on a regular /boot partition - not a raided one.
The kernel doesn't load the initrd image, the boot loader does. You will still be able to boot from a software RAID set, as long as the bootloader can access the RAID volume and the set is assembled by initrd.
If my understanding is correct, as the kernel won't be able to read RAID 1 directly, the initrd, or initramfs would have to be on a regular /boot partition - not a raided one.
Apart from the already mentioned fact that the boot loader loads the kernel and initrd from the disk before the kernel even starts ...
RAID 1 is no different to a regular disk as far as file system layout goes, remember it is a mirror image nothing more.
You can try in /etc/fstab to use UUID= for /boot so this way it does not matter if /boot is on on /dev/sda or sdb etc, if it has that uuid it will boot.
lsblk -f to list uuids or tune2fs -l /dev/sdX in ext4 or ext3 ifle systems.
As for lilo.conf you can still keep the old way with raid-extra-boot with /dev/sdX,/dev/sdY entries.
You can try in /etc/fstab to use UUID= for /boot so this way it does not matter if /boot is on on /dev/sda or sdb etc, if it has that uuid it will boot.
lsblk -f to list uuids or tune2fs -l /dev/sdX in ext4 or ext3 ifle systems.
As for lilo.conf you can still keep the old way with raid-extra-boot with /dev/sdX,/dev/sdY entries.
Looking at the man page for lilo.conf, it seems that raid-extra-boot mainly deals with where the boot record will be written. I'm not sure how lilo would be dealing with being able to point to the kernel or initrd on *either* /boot partition - to cope with one hdd going missing. Actually, thinking about it, I'm not sure how lilo copes even at the moment with loading the kernel or the initrd off a /boot partition which sits on top of RAID 1. Clearly, I have to do more reading on this. The lilo.conf man page doesn't seem to shed enough light on how lilo copes with RAID 1. Also, I could be wrong, but the notes in lilo.conf appear to refer to the case of entire disks being array members - as opposed to having partitions as array members. For example they recommend using boot=/dev/md0 - but, if my understanding is correct, this would only work if /dev/md0 has entire disks as members, not partitions.
Looking at the man page for lilo.conf, it seems that raid-extra-boot mainly deals with where the boot record will be written.
Given a RAID1 setup with 2 disks the correct use of this option will enable lilo to write itself to both disks so that when a disk is removed lilo will still be on the remaining disk.
Quote:
I'm not sure how lilo would be dealing with being able to point to the kernel or initrd on *either* /boot partition - to cope with one hdd going missing.
The way lilo writes it's records to each disk is such that if the disks are different or have partitions in different locations each record is unique to the disk it sits on.
When a disk is removed from a computer the remaining disks are reordered in sequence, all lilo has to do is assume it is on the first disk and it will load.
Quote:
Actually, thinking about it, I'm not sure how lilo copes even at the moment with loading the kernel or the initrd off a /boot partition which sits on top of RAID 1.
So long as it is only RAID1 and a v0.9 superblock and does not have partitions inside the RAID device then lilo can create a sector map of the files it needs to load.
This is no different to booting off a non RAID device, it just has extra options to enable creating the extra boot records on the second and later disks in case of the first disk suffering a failure.
I should also point out that RAID is not designed to deal with data corruption on a disk only the total failure of a disk, data corruption can only be dealt with via backups.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.