Bug 15805 - I cannot read the partition table of device sdX, it's too corrupted for me (DrakX v16.93) if attached to USB3 port
Summary: I cannot read the partition table of device sdX, it's too corrupted for me (D...
Status: RESOLVED INVALID
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Thomas Backlund
QA Contact:
URL:
Whiteboard: FOR_ERRATA
Keywords:
Depends on:
Blocks: 14069
  Show dependency treegraph
 
Reported: 2015-04-30 18:57 CEST by David Medina
Modified: 2015-05-31 10:39 CEST (History)
8 users (show)

See Also:
Source RPM: HardWare
CVE:
Status comment:


Attachments
Gparted screenshot (47.84 KB, image/png)
2015-04-30 18:57 CEST, David Medina
Details
report bug (56.25 KB, application/x-xz)
2015-05-01 20:20 CEST, papoteur
Details
report (159.82 KB, text/plain)
2015-05-01 20:53 CEST, David Medina
Details
ddebug.log of when I hit this bug, with gpt disk on USB 3.0 (72.20 KB, text/plain)
2015-05-02 21:42 CEST, Marja Van Waes
Details
report.bug.xz of a pre-5-final install (156.36 KB, application/x-xz)
2015-05-13 21:50 CEST, Marja Van Waes
Details
report.bug.xz from QA first round classical pre-5final install (147.16 KB, application/x-xz)
2015-05-14 12:09 CEST, Marja Van Waes
Details

Description David Medina 2015-04-30 18:57:12 CEST
Created attachment 6403 [details]
Gparted screenshot

Description of problem:
Mageia 5 RC DVD 64 bits installer seems not to identify clearly an Antergos (ArchLinux) installation in UEFI mode occupying only a half of the disk. It displays the message "I cannot read the partition table of device sda, it's too corrupted for me (the error is /proc/partitions does not agree with drakx3! = 0: /proc/partitions)" and then, if click on continue, only offers to use the existing partitions. 

The intention was to install Mageia alongside Antergos, using the option "use free space", and let Mageia handle the UEFI boot. The courious thing is that Gparted lists the EFI partition as mounted as /boot and not /boot/EFI but the BIOS is set to UEFI and it boots correctly. (Could it still not be a UEFI installation?)

I attach a screenshot of the disk's layout with Antergos' partitions and the free space reserved for Mageia.
Thanks,
Rémi Verschelde 2015-04-30 19:17:30 CEST

CC: (none) => thierry.vignaud

Comment 1 Thierry Vignaud 2015-04-30 21:49:11 CEST
Please try again.
Once you hit the error message, please:
- plug a USB key
- go to console 2 (alt+ctrl+F2)
- run the "bug" command

Then attach to this bug report (not paste) the report.bug file you'll found on your USB key

Keywords: (none) => NEEDINFO

Comment 2 papoteur 2015-05-01 20:01:00 CEST
Same problem here

CC: (none) => yves.brungard_mageia

Comment 3 papoteur 2015-05-01 20:20:13 CEST
Created attachment 6421 [details]
report bug
Comment 4 David Medina 2015-05-01 20:51:20 CEST
First of all, just in case, I wanted to verify that the existing Linux installation was an UEFI one, and it is. Several different boot selection attempts confirmed it.

Then an interesting turn:
When trying again today to get the bug report, I have found something else. The first round of failed tries I connected the USB installer key to an extension cable of a usb 3.0 rear port. The error came up every time. Now, in order to get ready to plug another usb key, I connected the installer key directly to a usb 2.0 at the rear with the intention to use the cable one for the report key. Result: the disk layout was successfully recognized and the installer offered to use the free space among other options. Good, problem solved. Mmm...Was it the usb 3.0?

Another try: I connected the installer key to the usb 3.0 rear port directly, no cables, and the error came again. Plugged the report key and got the file I attach. I have repeated both situations again with the same results.
I hope it's useful.
Comment 5 David Medina 2015-05-01 20:53:20 CEST
Created attachment 6422 [details]
report
Marja Van Waes 2015-05-02 10:18:03 CEST

CC: (none) => marja11
Attachment 6422 mime type: application/octet-stream => text/plain

Comment 6 Marja Van Waes 2015-05-02 10:50:47 CEST
You have

* error: /proc/partitions does not agree with drakx 3 != 0:

and Yves has:

* error: /proc/partitions does not agree with drakx 13 != 0:

in the setupSCSI step.

I've seen the same error, but thought my external USB disk was corrupted, because at that time diskdrake (on an installed system) had had problems starting when that disk was attached. Gparted had no problems.

I had touched the disk with both diskdrake and gparted before, and wondered whether there might be a disagreement between the two tools. 

Now the problem is gone, but I already use a newer stage2 version than on the iso, and most partitions on that disk have been wiped and new ones created.
 
However, it is also true that I switched to attaching that particular gpt-partitioned disk to a USB 2.0 port. 
The USB 3.0 port is now used for a same brand, same type, same size, but msdos partitioned disk that contains my local mirror.

Diskdrake on an installed system now starts fine when that disk is attached, regardless of whether it is on a USB 3.0 oe 2.0 port

last stage2 and draxtools I use, were created from drakx with all updates until this one http://gitweb.mageia.org/software/drakx/commit/?id=78e290b5b3cc2cfa9de1aac882707d04a125db37 + the three patches tv added to bug 9627

if I find time, then I'll test that disk with 5RC stage2, too

Keywords: NEEDINFO => (none)

Comment 7 Marja Van Waes 2015-05-02 14:30:39 CEST
My memory seems to have fooled me  :-[

Forget what I said about around the time diskdrake had a problem starting.

The report.bug.xz's from back then, show a different error, about a dos partitioned disk (then attached to a USB2 port) that contained my mirror.

* err, fstab and partition table do not agree for sdc1 type: ntfs-3g vs ntfs
(with DrakX v.

Sorry
claire robinson 2015-05-02 15:35:43 CEST

CC: (none) => eeeemail

Comment 8 claire robinson 2015-05-02 15:52:31 CEST
Setting release blocker

Priority: Normal => release_blocker
Blocks: (none) => 14069

claire robinson 2015-05-02 15:54:49 CEST

CC: (none) => mageia, pterjan, tmb

Comment 9 Marja Van Waes 2015-05-02 18:57:04 CEST
(In reply to claire robinson from comment #8)
> Setting release blocker

I was able to reproduce it with 5RC, so with DrakX v16.86 , but _only_ when the _gpt_ partitioned external HD was on a USB 3.0 port, not when it was on USB 2.0, 

(Thanks David Medina, for having told about that difference between USB 2.0 and 3.0 in comment 4)

From the logs:
* running: blkid -o udev -p /dev/sdb
* error: /proc/partitions does not agree with drakx 11 != 0:

and I got the screen that told

  I cannot read the partition table of device sdb, it's too corrupted for me :(

However, I'm sure it is fixed in newer DrakX, I did not see it in "DrakX v16.90½", as described in comment 6

Summary: I cannot read the partition table of device sda, it's too corrupted for me => I cannot read the partition table of device sdX, it's too corrupted for me (DrakX v16.86)

Comment 10 Marja Van Waes 2015-05-02 20:24:41 CEST
I misread what David said, he talked about: 
 installer key attached to USB 3.0 => this bug
 installer key attached to USB 2.0 => no problem

I talked about:
 gpt disk attached to USB 3.0 => this bug (with DrakX v16.86)
 gpt disk attached to USB 3.0 => no bug with DrakX v 16.90½ + tv patches
 gpt disk attached to USB 2.0 => no problem

I'll attach the installer key to the USB 3.0 port on next install
If the bug occurs, then I'll test whether that is also solved in DrakX v16.90½+
Comment 11 Marja Van Waes 2015-05-02 20:44:21 CEST
(In reply to Marja van Waes from comment #10)
> I misread what David said, he talked about: 
>  installer key attached to USB 3.0 => this bug
>  installer key attached to USB 2.0 => no problem

Unfortunately, I could not reproduce that with DrakX v16.86, so I can't test either whether it got fixed later.

> 
> I talked about:
>  gpt disk attached to USB 3.0 => this bug (with DrakX v16.86)
>  gpt disk attached to USB 3.0 => no bug with DrakX v 16.90½ + tv patches
>  gpt disk attached to USB 2.0 => no problem
>
Comment 12 papoteur 2015-05-02 21:18:02 CEST
I can no more reproduce the problem. I think it is because I go further in the installation process and something changed no the disk.
Comment 13 Marja Van Waes 2015-05-02 21:42:17 CEST
Created attachment 6430 [details]
ddebug.log of when I hit this bug, with gpt disk on USB 3.0
Comment 14 Anne Nicolas 2015-05-08 13:49:45 CEST
Can you still reproduce this bug, especially initial reporter ? Otherwise we will need to decrease priority while we cannot test it

CC: (none) => ennael1

Comment 15 Marja Van Waes 2015-05-13 21:50:51 CEST
Created attachment 6537 [details]
report.bug.xz of a pre-5-final install

(In reply to Anne Nicolas from comment #14)
> Can you still reproduce this bug, especially initial reporter ? Otherwise we
> will need to decrease priority while we cannot test it

I just saw it again when testing for bug 8819 (with DrakX v16.93 + patch that can't influence this)

I don't have the slightest idea what triggers it, it was the 4th install in a row to sdc, when I got this message about sda. Nothing on sda had changed, apart from sda2 (the ESP), which still worked fine.

The gpt disk was _not_ on USB 3.0. However, the ntfs partition disk with my local mirror was on USB 3.0

attaching report.bug.xz
Marja Van Waes 2015-05-13 21:56:19 CEST

Summary: I cannot read the partition table of device sdX, it's too corrupted for me (DrakX v16.86) => I cannot read the partition table of device sdX, it's too corrupted for me (DrakX v16.93)

Comment 16 Marja Van Waes 2015-05-14 12:09:06 CEST
Created attachment 6541 [details]
report.bug.xz from QA first round classical pre-5final install

Hit it again, with a QA iso (DrakX v 16.91), while installing to a disk on a USB 3.0 port

The only thing that is consistent about this bug is that we've seen it (unless papoteur did not use USB 3.0):

* using stage2 on a disk or flash drive attached to a USB 3.0 port
=> hitting it gave a message that *sda*'s partition table is too corrupted
* installing to a disk attached to a USB 3.0 port
=> hitting it gave a message that *sdb*'s partition table is too corrupted (where sdb was the disk that was on that USB 3.0 port)
Comment 17 Thierry Vignaud 2015-05-15 07:44:20 CEST
Looks like a kernel bug to me...

Summary: I cannot read the partition table of device sdX, it's too corrupted for me (DrakX v16.93) => I cannot read the partition table of device sdX, it's too corrupted for me (DrakX v16.93) if attached to USB3 port
Source RPM: (none) => kernel

Comment 18 Marja Van Waes 2015-05-15 07:47:33 CEST
(In reply to Thierry Vignaud from comment #17)
> Looks like a kernel bug to me...

assigning to its maintainer

Assignee: bugsquad => tmb

Comment 19 Thomas Backlund 2015-05-15 08:33:36 CEST
What brand/model of USB disk is this ?
Comment 20 Thomas Backlund 2015-05-15 08:42:48 CEST
Never mind, I see in the logs its a WD My Passport 0820
Comment 22 Pascal Terjan 2015-05-15 09:07:26 CEST
It's already a 1012 in the logs :(
Comment 23 Martin Whitaker 2015-05-15 09:58:37 CEST
Don't focus too heavily on the WD model - both David and papoteur are using different hardware. I also saw this error early in the beta testing phase, but haven't been able to reproduce it recently.
Comment 24 Rémi Verschelde 2015-05-15 09:59:25 CEST
(In reply to Pascal Terjan from comment #22)
> It's already a 1012 in the logs :(

The second post on the topic in comment 21 seems to hint that a user was experiencing random disconnections with the firmware 1012, and then fixed it by upgrading to 1025.

@Marja, could you try upgrading the disk's firmware and see if that does the trick?

@papoteur: When you were experiencing the issue, was it also when using USB3 ports, and maybe also with a WD My Passport disk?
Thierry Vignaud 2015-05-15 10:02:53 CEST

Priority: release_blocker => Normal
Source RPM: kernel => HardWare

Comment 25 Marja Van Waes 2015-05-15 10:20:55 CEST
(In reply to Rémi Verschelde from comment #24)
> (In reply to Pascal Terjan from comment #22)
> > It's already a 1012 in the logs :(
> 
> The second post on the topic in comment 21 seems to hint that a user was
> experiencing random disconnections with the firmware 1012, and then fixed it
> by upgrading to 1025.
> 
> @Marja, could you try upgrading the disk's firmware and see if that does the
> trick?
> 

Thanks for the link, Pascal, and thanks for spotting that comment, Rémi.

I'll update the firmware next week when I'm back from the real life (and really long ;-) ) docteam meeting in Lille
Comment 26 papoteur 2015-05-15 11:23:57 CEST
Hello,
I was attempting to install on real HDD /dev/sda (1To GPT formatted) using a USB stick (8Go on /dev/sdb) in UEFI mode.
Here are information about the USB stick:
[ 7609.933052] usb 1-2: new high-speed USB device number 5 using xhci_hcd
[ 7610.097657] usb 1-2: New USB device found, idVendor=8644, idProduct=800e
[ 7610.097661] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7610.097663] usb 1-2: Product: USB Flash Disk
[ 7610.097664] usb 1-2: Manufacturer: General
[ 7610.097666] usb 1-2: SerialNumber: 0127000000019149
[ 7610.137197] usb-storage 1-2:1.0: USB Mass Storage device detected
[ 7610.137254] scsi4 : usb-storage 1-2:1.0
[ 7610.137308] usbcore: registered new interface driver usb-storage
[ 7611.141155] scsi 4:0:0:0: Direct-Access     General  USB Flash Disk   1.0  PQ: 0 ANSI: 2
[ 7611.141700] sd 4:0:0:0: [sdb] 15669248 512-byte logical blocks: (8.02 GB/7.47 GiB)
Comment 27 Thomas Backlund 2015-05-15 12:20:49 CEST
(In reply to Martin Whitaker from comment #23)
> Don't focus too heavily on the WD model - both David and papoteur are using
> different hardware. I also saw this error early in the beta testing phase,
> but haven't been able to reproduce it recently.


Yeah, I know that, but I wanted to see if they are using disks with with asmedia usb -> sata bridge as that one has has some issues...

The 3.19.8-1 kernel does have some fixes for both asmedia and xhci (usb3) so some of you could test if current boot.iso behaves any differently
Comment 28 Marja Van Waes 2015-05-16 08:30:42 CEST
(In reply to Thomas Backlund from comment #27)
> (In reply to Martin Whitaker from comment #23)
> > Don't focus too heavily on the WD model - both David and papoteur are using
> > different hardware. I also saw this error early in the beta testing phase,
> > but haven't been able to reproduce it recently.
> 
> 
> Yeah, I know that, but I wanted to see if they are using disks with with
> asmedia usb -> sata bridge as that one has has some issues...
> 
> The 3.19.8-1 kernel does have some fixes for both asmedia and xhci (usb3) so
> some of you could test if current boot.iso behaves any differently

I don't know whether I have such a disk. However, in my last tests it seemed to always occur. With the boot-nonfree iso of May 12th, it did not occur in the first test, but it did in the (identical) 2nd test, both with stage2 on a WD My Passport disk attached to a USB3 port
Rémi Verschelde 2015-05-26 10:36:56 CEST

Whiteboard: (none) => FOR_ERRATA

Comment 29 Thierry Vignaud 2015-05-29 13:32:43 CEST
Closing as INVALID (HW bug)

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

Comment 30 Marja Van Waes 2015-05-31 10:39:35 CEST
(In reply to Rémi Verschelde from comment #24)
> (In reply to Pascal Terjan from comment #22)
> > It's already a 1012 in the logs :(
> 
> The second post on the topic in comment 21 seems to hint that a user was
> experiencing random disconnections with the firmware 1012, and then fixed it
> by upgrading to 1025.
> 
> @Marja, could you try upgrading the disk's firmware and see if that does the
> trick?
> 
Sorry for my late reply, I only found time yesterday.

When, using the WD firmware update tool, I tried, I got a message that I'm already on the last version.

Apparently, version 1025 only exists for My Passport _0748_

However, I have My Passport _0820_ (the same type as the person who started the topic) with the same version 1012 that solved the issue for him.

I won't reopen this report, though, only telling this in case someone else still hits the problem.

The motherboard of the laptop I saw this on has died (it going to die maybe contributed to the problem?), and I do not have another one with a USB3.0 port.

Note You need to log in before you can comment on or make changes to this bug.