I didn't need to reboot!

I don't know why in the world sda1 (The just created empty partition) was mounted, but after unmounting /dev/sda1 and /dev/sda5, I started draklive-install from live mode again and could continue using existing partitions.

/dev/sda1 was the old root partition, from the previous install.

Ah, wait: this is XFCE!

Maybe /dev/sda1 was auto-mounted before it was wiped in the partitioning step, and for some strange reason not unmounted before it got wiped??

Is that possible at all??

CC: (none) => shybluenight

I should have read my mails first :-)

Op 05-02-17 om 22:07 schreef Martin Whitaker:

> 
> OK, I've reproduced this error. I believe it's caused by Thunar
> auto-mounting the partitions. The installer/diskdrake doesn't see this,
> so thinks it can delete the partitions without needing to unmount them
> first.
> 
> The temporary workaround is to disable the auto-mounting options in
> Thunar before running the installer. When I did this and repeated the
> above experiment, the installation completed without error.
> 
> I think I need to find a way to disable Thunar when the installer is
> running. That would also let us restore the default setting for
> auto-browse.
> 
> Martin
>

Seems we are not the first to have this problem:

  https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1078445

As there, draklive-install uses 'udisks --inhibit' to stop Thunar auto-mounting whilst the installer is running, which no longer works now we've switched to udisks2. Unfortunately udisks2-inhibit is not available in Mageia.

(In reply to Martin Whitaker from comment #3)
> Seems we are not the first to have this problem:
> 
>   https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1078445
> 
> As there, draklive-install uses 'udisks --inhibit' to stop Thunar
> auto-mounting whilst the installer is running, which no longer works now
> we've switched to udisks2. Unfortunately udisks2-inhibit is not available in
> Mageia.

Debian is upstream for udisks2-inhibit, correct?

CC'ing basesystem maintainers and all packagers collectively, in case someone wants to work on importing the package. Also CC'ing our XFCE maintainer.

Btw, for 6sta2 I think it is better to workaround the issue, if that can be done much faster than really fixing it.

Status comment: only valid for pre-testing isos => Only valid for XFCE isos. Needs udisks2-inhibit for a real fix.
CC: (none) => basesystem, jani.valimaa, pkg-bugs

Yes, the script is here:
https://anonscm.debian.org/cgit/pkg-utopia/udisks2.git/tree/debian/local/udisks2-inhibit

Providing it would probably be better as for example gparted will run it if available in the expected location.

(In reply to Pascal Terjan from comment #5)
> Yes, the script is here:
> https://anonscm.debian.org/cgit/pkg-utopia/udisks2.git/tree/debian/local/
> udisks2-inhibit

Thanks :-)
> 
> Providing it would probably be better as for example gparted will run it if
> available in the expected location.

Anyone volunteering to package it, please?



Btw, an additional reason to consider this bug to be a release blocker for _6sta2_, is that this bug may lead to installer installing to a different partition than selected (and thus overwriting everything in the not selected partition). Here, an unselected encrypted partition got overwritten with an XFCE install from the XFCE Live DVD

Done in udisks2-2.1.8-2.mga6.

http://svnweb.mageia.org/packages?view=revision&revision=1085031

commit a0fb747dca1a49527f026d7acdbe1a9fcf61a390
Author: Martin Whitaker <mageia@...>
Date:   Mon Feb 6 19:47:25 2017 +0000

    Prevent udisks2-based auto-mounters operating during installation (mga#20247).
    
    Use udisks2-inhibit if it is available and if the udisks2 daemon is running.
    Fall back to udisks --inhibit (which only works for the older udisks daemon)
    if not.
    
    This prevents file/volume managers such as Thunar from auto-mounting disks
    during the partitioning stage of installation, which can cause partitioning
    to fail and cause the system to be installed on the wrong partition.
---
 Commit Link:
   http://gitweb.mageia.org/software/draklive-install/commit/?id=a0fb747dca1a49527f026d7acdbe1a9fcf61a390

I've tested this locally, repeating the installation sequence Marja describes in the original report, and partitioning completed successfully. There was a problem with grub2 installation, because os-prober found the remains of the previous installation in the first Empty partition and then locked up because most of the file system had been overwritten. Repeating the experiment, but zeroing the first 1MB of the Empty partition before installing grub2 avoided this problem. I think that's a bug in os-prober - it should skip Empty partitions.

I'll rebuild the Xfce ISOs in pretesting with this fix applied.

N.B. We should also use udisks2-inhibit when running diskdrake.

(In reply to Martin Whitaker from comment #9)
 I think that's a bug in os-prober -
> it should skip Empty partitions.

I have pushed a new updated os-prober to updates testing if you would like to see if this makes any difference - reading the changelog I'm not hopeful, but there have been a lot of bug fixes.
https://launchpad.net/debian/+source/os-prober/+changelog

CC: (none) => zen25000

The changes committed in the Feb 6 Mageia-6-sta2-LiveDVD-xfce4-x86_64-DVD.iso
can now screw-up the UEFI install on mulit-disk systems.

If the installer finds an existing /boot/EFI partition on any disk it forces that
partition also be used for the xfce install on the target disk even if 1 is created on /dev/sdc.

Because the /boot/EFI created on /dev/sdc1 is not used or mounted the installer 
will not require that the partition table for /dev/sdc be gpt.

CC: (none) => cae

(In reply to Barry Jackson from comment #11)
> (In reply to Martin Whitaker from comment #9)
>  I think that's a bug in os-prober -
> > it should skip Empty partitions.
> 
> I have pushed a new updated os-prober to updates testing if you would like
> to see if this makes any difference - reading the changelog I'm not hopeful,
> but there have been a lot of bug fixes.
> https://launchpad.net/debian/+source/os-prober/+changelog

It seems fixed: I updated os-prober in Live mode using last night's 32bit XFCE iso, and os-prober found no remains of the former installation on the now empty /dev/sda1. However, I admit having forgotten to reproduce the issue before updating os-prober :-(

This bug with Thunar auto-mounting seems fixed, but I'll run one more test.

(In reply to Charles Edwards from comment #12)
> The changes committed in the Feb 6 Mageia-6-sta2-LiveDVD-xfce4-x86_64-DVD.iso
> can now screw-up the UEFI install on mulit-disk systems.
> 
> If the installer finds an existing /boot/EFI partition on any disk it forces
> that
> partition also be used for the xfce install on the target disk even if 1 is
> created on /dev/sdc.
> 
> Because the /boot/EFI created on /dev/sdc1 is not used or mounted the
> installer 
> will not require that the partition table for /dev/sdc be gpt.

@ Charles

Do you mind filing a separate bug report for that, and giving a link to it in a comment, here?

Status comment: Only valid for XFCE isos. Needs udisks2-inhibit for a real fix. => Only valid for XFCE isos. Fix involving new udisks2-inhibit in Feb.6 isos is being tested.

(In reply to Marja van Waes from comment #13)
> (In reply to Barry Jackson from comment #11)
> > (In reply to Martin Whitaker from comment #9)
> >  I think that's a bug in os-prober -
> > > it should skip Empty partitions.
> > 
> > I have pushed a new updated os-prober to updates testing if you would like
> > to see if this makes any difference - reading the changelog I'm not hopeful,
> > but there have been a lot of bug fixes.
> > https://launchpad.net/debian/+source/os-prober/+changelog
> 
> It seems fixed: I updated os-prober in Live mode using last night's 32bit
> XFCE iso, and os-prober found no remains of the former installation on the
> now empty /dev/sda1. However, I admit having forgotten to reproduce the
> issue before updating os-prober :-(
> 

After downgrading to old os-prober, it doesn't detect the remnants of the previous installation on sda1, so that bug didn't affect me. Sorry.

I've attempted several XFCE installs today, and the ones of which I'm sure they were done with intact partitions / partition table, went very fine.

That included two tests with one or two empty partitions present, and tests with resizing a fat partition and using the new space for the install. In one of them the new Mageia partition got the partition number that the previous Mageia partition had, and that went well, too.

The only thing that I'd still like to test is a "erase and use the entire disk" install

(In reply to Marja van Waes from comment #15)
> I've attempted several XFCE installs today, and the ones of which I'm sure
> they were done with intact partitions / partition table, went very fine.
> 

About the install attempts about which i'm not sure (and which failed):
I had forgotten having read that diskdrake outside installer still needs to be patched. I have used that diskdrake, and may have caused some corruption with it before the first time diskdrake in installer failed.

@ Martin

Had you said that about the fix for this bug, or (also) about the other partitioning bugs?

(In reply to Marja van Waes from comment #16)
> @ Martin
> 
> Had you said that about the fix for this bug, or (also) about the other
> partitioning bugs?

Yes, I've seen Thunar start automounting partitions when I run diskdrake, which can then cause the kernel not to update its view of the partition table when it gets written. If you then ran the installer, you could easily end up with disk corruption.

(In reply to Martin Whitaker from comment #17)

> 
> Yes, I've seen Thunar start automounting partitions when I run diskdrake,
> which can then cause the kernel not to update its view of the partition
> table when it gets written. If you then ran the installer, you could easily
> end up with disk corruption.

Thanks, updating the Status comment.

Apart from diskdrake outside draklive-install, I think this bug is fixed.

However, Dave Hodgins plans to run some tests later in his today. Let's wait for his feedback

Status comment: Only valid for XFCE isos. Fix involving new udisks2-inhibit in Feb.6 isos is being tested. => Seems fixed in the February 6 XFCE isos, except for diskdrake in Live mode (outside draklive-install), which can still cause disk corruption
CC: (none) => davidwhodgins

Created attachment 8948 [details]
Patch to prevent disks being auto-mounted by Thunar when drakdisk is running

As done for draklive-install (and in gparted upstream), this uses udisk2-inhibit if it is available and if the udisks2 daemon is running to inhibit auto-mounting when drakdisk is running.

commit c5512813ad4795f5f3596a7963b84d821604f212
Author: Martin Whitaker <mageia@...>
Date:   Fri Feb 10 23:43:47 2017 +0000

    Inhibit udisks2 when running drakdisk (mga#20247).
    
    This prevents disks/partitions being auto-mounted by e.g. Thunar
    when drakdisk probes the disks or makes changes, which can lead
    to disk corruption.
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=c5512813ad4795f5f3596a7963b84d821604f212

Created attachment 8967 [details]
report for classical install x86_64

not sure if this is the same or a new bug

virgin HDD, Classical x86_64 .iso from USB.(non UEFI / legacy bios).

chose option: "erase and use whole disk"

CC: (none) => westel

(In reply to ben mcmonagle from comment #21)
> Created attachment 8967 [details]
> report for classical install x86_64
> 
> not sure if this is the same or a new bug
> 
> virgin HDD, Classical x86_64 .iso from USB.(non UEFI / legacy bios).
> 
> chose option: "erase and use whole disk"

Extracting what I think is the most important information:

You ran * second stage install running (DrakX v17.71)
It would be _really_nice_ if something were appended to the DrakX version to indicate a different git branch is used.

 
In case that means anything: at the beginning, there's 

* sda: no valid geometry guessed from partition table
* sda: argh! no geometry exists for this partition table


in between "fdisk before" and "fdisk after" there is

* unmounting all filesystems

and

* partitioning wizard log:
>>wizlog>>Not enough free space to allocate new partitions: 0 < 1228800
>>wizlog>>There is no existing partition to use
>>wizlog>>There is no FAT partition to resize (or not enough space left)

* solutions found: Erase and use entire disk, Custom disk partitioning (all solutions found: Erase and use entire disk, Custom disk partitioning)
* solutions: 2
* HERE: Erase and use entire disk,Custom disk partitioning
* partitionWizard calling solution Erase and use entire disk
* partition::dos::write sda



After that, in the formatting step, formatting sda1 (which existed before the partitioning step) succeeds, but then the next one, sda5 (which didn't exist before) fails:

* step "formatPartitions" failed with error: INTERNAL ERROR: unknown device sda5

@ Martin

I don't understand what's going on there... should it go into a separate report?

It's a different cause leading to the same effect. The mechanism that causes the kernel to automatically rescan a DOS partition table when it is written doesn't appear to be active in the cut-down system that runs the classic installer.

(In reply to Martin Whitaker from comment #23)
> It's a different cause leading to the same effect. The mechanism that causes
> the kernel to automatically rescan a DOS partition table when it is written
> doesn't appear to be active in the cut-down system that runs the classic
> installer.

Followed up in bug 20074, comment 42.

commit c7480899a8825b0a0791526eca0d811260346ab4
Author: Martin Whitaker <mageia@...>
Date:   Fri Feb 10 23:43:47 2017 +0000

    Inhibit udisks2 when running drakdisk (mga#20247).
    
    This prevents disks/partitions being auto-mounted by e.g. Thunar
    when drakdisk probes the disks or makes changes, which can lead
    to disk corruption.
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=c7480899a8825b0a0791526eca0d811260346ab4

Can we consider this bug completely fixed with comment 25?

I guess so

Status: NEW => RESOLVED
Resolution: (none) => FIXED