{"id":159,"date":"2010-02-08T21:26:22","date_gmt":"2010-02-08T21:26:22","guid":{"rendered":"http:\/\/blog.schmoigl-online.de\/?p=159"},"modified":"2010-02-10T06:48:56","modified_gmt":"2010-02-10T06:48:56","slug":"repotting-fedora-core-12-on-software-raid","status":"publish","type":"post","link":"http:\/\/blog.schmoigl-online.de\/?p=159","title":{"rendered":"Repotting Fedora Core 12 on Software RAID"},"content":{"rendered":"<p>Last weekend I had to change the size of the root partition of a <a href=\"https:\/\/fedoraproject.org\">Fedora Core<\/A> 12 system. Reason for it was a) the size of the partition where the root file system is located is too large and b) the remaining free space shall be used in another partition (for a different purpose). Due to the circumstances it was not an option to use the disk space within the same partition. <!--more--> The obviously tricky part, however, was clear to me right from the beginning: As the system is running in a productive environment I had set up the system on a software RAID using <a href=\"http:\/\/neil.brown.name\/blog\/mdadm\">mdadm<\/A> (as it is normally done when you use the partitionizing assistant within anaconda during setup of Fedora). How to resize an existing ext3 partition which is not located on software RAID can be done quite easy. Having to understand this part of the task the following webpages helped me to get the basic principle:<\/p>\n<ul>\n<li><a href=\"http:\/\/www.howtoforge.com\/linux_resizing_ext3_partitions\">http:\/\/www.howtoforge.com\/linux_resizing_ext3_partitions<\/A><\/li>\n<li><a href=\"http:\/\/www.howtoforge.com\/how-to-resize-raid-partitions-shrink-and-grow-software-raid\">http:\/\/www.howtoforge.com\/how-to-resize-raid-partitions-shrink-and-grow-software-raid<\/a><\/li>\n<\/ul>\n<p>Let me briefly comment on the second link above. What is written there is correct: The size of the software RAID is reduced after doing the steps in section 2.1, but compare it to the first link! mdadm does not touch the partition table (via fdisk) and it does good to do so (<a href=\"http:\/\/en.wikipedia.org\/wiki\/Unix_philosophy\">paradigm No. 2 of the Unix philosophy<\/A>: Make each program do one thing well.). Consequently, you changed the size of your RAID &#8220;filesystem&#8221;, but you did not change the size of the partitions. <\/p>\n<h4>Adoption Changing also the Partition Size<\/h4>\n<p>I therefore adopted my approach as follows:<\/p>\n<ol>\n<li>Having booted with Fedora Core&#8217;s installation DVD using the rescue mode, I ran e2fsck on the md device<\/li>\n<li>Afterwards I ran resize2fs with a slightly smaller size than I want later (wanting 26 GB at the end I used 25GB, so 1 GB less)<\/li>\n<li>Using mdadm I stopped the raid array entirely<\/li>\n<li>By executing fdisk I deleted the partitions on both hard disk where the raid array was located and recreated the raid partitions (with partition type FD) manually again; this time with the correct &#8211; not the slightly reduced! &#8211; size (quite similarly on how it is described in <a href=\"http:\/\/www.howtoforge.com\/linux_resizing_ext3_partitions\">http:\/\/www.howtoforge.com\/linux_resizing_ext3_partitions<\/a>\n<li>Using mdadm I created a new software RAID array which writes a new set of software RAID metadata to the partitions.\n<li>Now I ran resize2fs again not specifying any size as last argument which means &#8220;take the largest value possbile&#8221; &#8211; so it took everything that the software RAID system delivered.\n<\/ol>\n<p>I decided to use this approach, because it can be quite tricky to find out how much size the metadata for the software RAID takes at the end of your partitions. By being able to let resize2fs decide on its own you can safely ignore this question. So good so far. <\/p>\n<p>However, no site on the net discussed about what might happen, if you are doing as described above and promptly I fell into a very ugly problem: The system did not boot anymore (please note: the filesystem on the software RAID on which I executed the procedure above has to be mounted as root partition) saying that the root file system could not be found! I took me two hours to figure out what was happening.<br \/>\n<!--nextpage--><\/p>\n<h4>RAID UUID and initramfs<\/h4>\n<p>After many many reboots between the running system and the rescue console of the Fedora DVD I figured out the root cause: Each Software RAID created with mdadm has a unique identifier (a UUID to be precise). You can determine your one with<\/p>\n<pre>\r\nmdadm --misc -D \/dev\/md0\r\n<\/pre>\n<p>(side remark: for the time being I assume that the software RAID device is called \/dev\/md0) What follows are the metadata details of your RAID. Amonst others there is a line which looks like this:<\/p>\n<pre>\r\nUUID : c9d6cd07:d2960626:1eb1e02d:b8b6db4b\r\n<\/pre>\n<p>This UUID is being written (during setup of Fedora) to the file \/etc\/mdadm.conf where (in my case) it reads something like this:<\/p>\n<pre>\r\nARRAY \/dev\/md0 level=raid1 num-devices=2 UUID=10c62146:3d716744:bf078010:bc810f04\r\n<\/pre>\n<p>If you recreate your software RAID manually, the UUID changes &#8212; but the line in \/etc\/mdadm.conf is not! Please note that this is no bug, because the system cannot know what the purpose of the just newly created software RAID device is. Having found this point, I changed it accordingly (which is a good idea), but it soon turned out that this was not enough: the same error still was shown to me. When booting Fedora does not use this file on the root partition directly, but it starts from the initramfs file which you can find in your \/boot directory. In this boot image a copy (!) of \/etc\/mdmadm.conf has been stored when it was created during the setup procedure of Fedora. The error message above therefore is quite misleading: The root cause of it is not that the root file system cannot be found, but that the software RAID array with the old UUID is not being detected (and thus the system cannot gain access to the root file system). As you need a running system for creating a new initramfs I did the following workaround:<\/p>\n<ol>\n<li>I made a copy of the initramfs file &#8211; just to make sure that if I killed something I could revert back to the start at any time<\/li>\n<li>By renaming the file I added the postfix .gz to it<\/li>\n<li>You can uncompress the initramfs now with gunzip<\/li>\n<li>The uncompressed file is an <a href=\"http:\/\/wiki.laptop.org\/go\/Building_initramfs\">archive created with cpio<\/a>. However, I did not uncompress it<\/li>\n<li>Using vi in binary mode\n<pre># vi -b<\/pre>\n<p> I opened the entire file and searched for the term mdadm.conf. Shortly thereafter the content of the mdadm.conf can be seen. As cpio neither does implement a compression algorithm nor does it impose error dedecting codes like CRC checksums or similar, you can change the UUID manually. However, please note that you still need to be careful, because you may not modify the length of the file (otherwise the entire file&#8217;s structure does not fit anymore).<\/li>\n<\/ol>\n<p>I then did the entire chain back again (saving, compressing it, renaming it back to the original name) and started the system: and hurray! The system booted from the new software RAID device without a problem!<\/p>\n<h4>Appendix<\/h4>\n<p>Please note also that it is a good idea to recreate the initramfs file from scratch again. Unfortunately this can also be a very tricky task. In the case of Fedora Core posts like <a href=\"http:\/\/kb.qlogic.com\/KanisaPlatform\/Publishing\/394\/12902_f.html\">http:\/\/kb.qlogic.com\/KanisaPlatform\/Publishing\/394\/12902_f.html<\/a> can be very misleading: here again, it proofs that Fedora ain&#8217;t RedHat &#8211; the tool with which you can create a new initramfs file on Fedora is called dracut. You can find more details on this <a href=\"http:\/\/fedoraproject.org\/wiki\/Dracut\">here<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Having installed the root partition of a Fedora Core 12 system on a software RAID device can be a tricky situation when it comes to resizing the file system. The post describes what needs to be done to ensure that the system can also boot after resizing has happened.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,10],"tags":[16,13,15,14,12,17],"class_list":["post-159","post","type-post","status-publish","format-standard","hentry","category-fedora","category-linux","tag-ext3","tag-mdadm","tag-resize2fs","tag-root-partition","tag-software-raid","tag-uuid"],"_links":{"self":[{"href":"http:\/\/blog.schmoigl-online.de\/index.php?rest_route=\/wp\/v2\/posts\/159","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/blog.schmoigl-online.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.schmoigl-online.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.schmoigl-online.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.schmoigl-online.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=159"}],"version-history":[{"count":19,"href":"http:\/\/blog.schmoigl-online.de\/index.php?rest_route=\/wp\/v2\/posts\/159\/revisions"}],"predecessor-version":[{"id":234,"href":"http:\/\/blog.schmoigl-online.de\/index.php?rest_route=\/wp\/v2\/posts\/159\/revisions\/234"}],"wp:attachment":[{"href":"http:\/\/blog.schmoigl-online.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=159"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.schmoigl-online.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=159"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.schmoigl-online.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=159"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}