On Fri, 2016-03-25 at 08:00 -0600, Alex Schultz wrote:
>
> On Fri, Mar 25, 2016 at 7:32 AM, Dmitry Guryanov com> wrote:
> > Here is the bug which I'm trying to fix - https://bugs.launchpad.ne
> > t/fuel/+bug/1538587.
> >
> > In VMs (set up with fuel-virtualbox) kernel panic occurs every
> > tim
On Fri, Mar 25, 2016 at 7:32 AM, Dmitry Guryanov
wrote:
> Here is the bug which I'm trying to fix -
> https://bugs.launchpad.net/fuel/+bug/1538587.
>
> In VMs (set up with fuel-virtualbox) kernel panic occurs every time you
> delete node, stack trace shows error in ext4 driver [1].
> The same as
Here is the bug which I'm trying to fix -
https://bugs.launchpad.net/fuel/+bug/1538587.
In VMs (set up with fuel-virtualbox) kernel panic occurs every time you
delete node, stack trace shows error in ext4 driver [1].
The same as in the bug.
Here is a patch - https://review.openstack.org/297669 .
I've read carefully the article about bios_grub partition you've given link
to. And it turned out for me that it's only used for non-UEFI boot. It this
case it's impossible to boot without stage1 (in mbr), because our PXE
doesn't touch hard disks. So clearing BIOS_boot partition will not
introduce
On Wed, Mar 23, 2016 at 7:49 PM, Dmitry Guryanov
wrote:
>
> I have no objections against clearing bios boot partition, but could
> you describe scenario, how non-efi system will boot with valid
> BIOS_grub and wiped boot code in MBR
>
I thoroughly agree that it's impossible to boot without stag
On Wed, 2016-03-23 at 18:22 +0300, Alexander Gordeev wrote:
> Hello Dmitry,
>
> .
>
> 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.
>
> Nope, I think that zeroing of 446 bytes is not
Hello Dmitry,
First of all, thanks for recovering the thread.
Please read my comments inline.
On Tue, Mar 22, 2016 at 1:07 PM, Dmitry Guryanov
wrote:
>
> 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
For GPT disks and non-UEFI boot this method will work, since MBR will still
contain first stage of a bootloader code. For UEFI boot things are little
more complicated, we have to find EFI system partition, mount it and
remove/edit some files.
On Tue, Mar 22, 2016 at 4:26 PM, Bulat Gaifullin
wrote
What about GPT[1] disks?
As I know we have plans to support UEFI boot and GPT disks.
[1] https://en.wikipedia.org/wiki/GUID_Partition_Table
Regards,
Bulat Gaifullin
Mirantis Inc.
> On 22 Mar 2016, at 13:46, Dmitry Guryanov wrote:
>
> On Tue, 2016-03-22 at 13:07 +0300, Dmitry Guryanov wrote
On Tue, 2016-03-22 at 13:07 +0300, Dmitry Guryanov wrote:
> Hello,
>
> ..
>
> [0] https://github.com/openstack/fuel-astute/blob/master/mcagents/era
> se_node.rb#L162-L174
> [1] https://github.com/openstack/fuel-
> agent/blob/master/fuel_agent/manager.py#L194-L221
Sorry, here is a correct li
Hello,
Here is a start of the discussion -
http://lists.openstack.org/pipermail/openstack-dev/2015-December/083021.html
. I've subscribed to this mailing list later, so can reply there.
Currently we clear node's disks in two places. The first one is before
reboot into bootstrap image [0] and the
11 matches
Mail list logo
