<div dir="ltr">Hello Dmitry,<br><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">First of all, thanks for recovering the thread.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Please read my comments inline.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 22, 2016 at 1:07 PM, Dmitry Guryanov <span dir="ltr"><<a href="mailto:dguryanov@mirantis.com" target="_blank">dguryanov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>The first problem could be solved with zeroing first 512 bytes of each disk (not partition). Even 446 to be precise, because last 66 bytes are partition scheme, see <a href="https://wiki.archlinux.org/index.php/Master_Boot_Record" target="_blank">https://wiki.archlinux.org/index.php/Master_Boot_Record</a> .</div><div><br></div></div></blockquote><div><br></div>Apparently, fuel has been using GPT since the very beginning [1]. <br><div><br></div><div>fuel-agent does create only GPT [2] (but in fact it has got some soft of rudimentary MBR support inside [3], but i really doubt if the corresponding code path was executed even for once for real use cases. Looks like only unit tests are actually using it)<br><br></div><div>Currently, due to lack of UEFI support in fuel, fuel-agent got to use special dedicated partition for allowing to boot in CSM (BIOS/GPT) mode. [4] [5]<br><br></div><div>And it turns out, that you're right about the fact that first stage of grub resides in MBR [6] no<br></div><div><br></div><div><br> [1] <a href="https://github.com/openstack/fuel-library/commit/a2a37e4de2a92171d12f0fbc98a684149ca8b124">https://github.com/openstack/fuel-library/commit/a2a37e4de2a92171d12f0fbc98a684149ca8b124</a><br></div><div><br>[2] <a href="https://github.com/openstack/fuel-agent/blob/dcdd64a95245cdde57f1bd1e0a83720e6bf1f56a/fuel_agent/drivers/nailgun.py#L335-L338">https://github.com/openstack/fuel-agent/blob/dcdd64a95245cdde57f1bd1e0a83720e6bf1f56a/fuel_agent/drivers/nailgun.py#L335-L338</a><br><br>[3] <a href="https://github.com/openstack/fuel-agent/blob/dcdd64a95245cdde57f1bd1e0a83720e6bf1f56a/fuel_agent/objects/partition/parted.py#L56-L97">https://github.com/openstack/fuel-agent/blob/dcdd64a95245cdde57f1bd1e0a83720e6bf1f56a/fuel_agent/objects/partition/parted.py#L56-L97</a><br><br>[4] <a href="https://help.ubuntu.com/community/Grub2/Installing#BIOS.2FGPT_Notes">https://help.ubuntu.com/community/Grub2/Installing#BIOS.2FGPT_Notes</a> <br></div><div> <br>[5] <a href="https://github.com/openstack/fuel-agent/blob/master/fuel_agent/drivers/nailgun.py#L345-L347">https://github.com/openstack/fuel-agent/blob/master/fuel_agent/drivers/nailgun.py#L345-L347</a><br><br>[6]  <a href="https://en.wikipedia.org/wiki/BIOS_boot_partition">https://en.wikipedia.org/wiki/BIOS_boot_partition</a><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>The second problem should be solved only after reboot into bootstrap. Because if we bring a new node to the cluster from some other place and boot it with bootstrap image it will possibly have disks with some partitions, md devices and lvm volumes. So all these entities should be correctly cleared before provisioning, not before reboot. And fuel-agent does it in [1].<br></div><div><br></div></div></blockquote><div><br>However, the code from<span class=""><font color="#888888"> </font></span><br><span class=""><font color="#888888"> <a href="https://github.com/openstack/fuel-agent/blob/master/fuel_agent/manager.py#L194-L221" target="_blank">https://github.com/openstack/fuel-agent/blob/master/fuel_agent/manager.py#L194-L221</a><span class=""><font color="#888888"><br></font></span></font></span><br>is not allowing us to mix LVM and MD. So, fuel-agent could only use/wipe/create them separately. The case when MD is built on top of LVM volumes and vice versa are not supported and then fuel-agent will fail. I suspect this issue should go to another thread entirely, I just want to keep you aware of that the way how fuel-agent does it, it's not perfectly correct. At least, it works for fuel's case.<br></div><div><span class=""><font color="#888888"><br></font></span></div><div> <br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>I propose to remove erasing first 1M of each partiton, because it can lead to errors in FS kernel drivers and kernel panic. An existing workaround, that in case of kernel panic we do reboot is bad because it may occur just after clearing first partition of the first disk and after reboot bios will read MBR of the second disk and boot from it instead of network. Let's just clear first 446 bytes of each disk.</div><div><br></div><div><br clear="all"><div>[0] <a href="https://github.com/openstack/fuel-astute/blob/master/mcagents/erase_node.rb#L162-L174" target="_blank">https://github.com/openstack/fuel-astute/blob/master/mcagents/erase_node.rb#L162-L174</a></div></div></div></blockquote><div> </div><div>Yep, astute needs to be fixed as the way how it wipes the disks is way too fragile, dangerous and not always reliable due to what you mentioned above.<br><br></div><div>Nope, I think that zeroing of 446 bytes is not enough. Why don't we want to wipe bios_boot partition too? Let's wipe all grub leftovers such as bios_boot partitions too. They doesn't contain any FS, so unlikely that kernel or any other process will prevent us from wiping it. No errors, no kernel panic are expected.<br><br><br>On Tue, Mar 22, 2016 at 5:06 PM, Dmitry Guryanov <span dir="ltr"><<a href="mailto:dguryanov@mirantis.com" target="_blank">dguryanov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">For GPT disks and non-UEFI boot this method will work, since MBR will still contain first stage of a bootloader code. </div></blockquote><br></div><div>Agreed, it will work. But how about bios_boot partition? What do you think?<br><br><br></div><div>Thanks,  Alex.<br></div></div><br></div></div></div></div>