Bug 1297331

Note that fdisk reads whole-disk (e.g. /dev/sde) device to get partitions. The node for the partition does not have exit in /dev.

It's better to use for example 'lsblk' to be sure about block devices.

The fdisk command "w" forces system to re-read partition table, this step triggers kernel to generate event and then udevd creates a /dev/node.

Nothing in this use-case is e2fsprogs responsibility :-)

Ok, so you essentially hotplugged a disk and did not get a device node?
Right, not an e2fsprogs problem, it's just the messenger when you point it at a device that doesn't exist.

I'd attach dmesg showing what happens when you hotplug, and lsblk to see what you have afterwards, and we'll try to find the right home for the bug.

Eric,

The problem is that after the device is powered up, there should be a /dev entry. In this case, an entry does NOT. Maybe the problem is in mount?

More info to come.

George...

Created attachment 1114372 [details]
gzip'd flat file with info requested

Eric,

I booted the system without any external docking stations, then started powering each one up and then checked each one. The second one exhibited the problem (/dev/sde and /dev/sdf).

Since there are two docking stations, the problem could, I suppose, be with the second one I powered up. I could repeat the process starting with #2 first if you feel that's necessary.

Thanks,

George...

Interesting; the kernel finds sde1, but it's not in /dev

[ 1302.596037] usb 2-1.3: new SuperSpeed USB device number 4 using xhci_hcd
[ 1302.609233] usb 2-1.3: New USB device found, idVendor=152d, idProduct=2551
[ 1302.609247] usb 2-1.3: New USB device strings: Mfr=10, Product=11, SerialNumber=3
[ 1302.609253] usb 2-1.3: Product: USB Mass Storage
[ 1302.609259] usb 2-1.3: Manufacturer: G-Max Technology Co., Ltd.
[ 1302.609264] usb 2-1.3: SerialNumber: 000000000048
[ 1302.611584] usb-storage 2-1.3:1.0: USB Mass Storage device detected
[ 1302.612470] scsi host8: usb-storage 2-1.3:1.0
[ 1303.622819] scsi 8:0:0:0: Direct-Access     ST2000DM 001-9YN164       0000 PQ: 0 ANSI: 2 CCS
[ 1303.624905] scsi 8:0:0:1: Direct-Access     ST2000DM 001-1CH164       0000 PQ: 0 ANSI: 2 CCS
[ 1303.630879] sd 8:0:0:0: Attached scsi generic sg5 type 0
[ 1303.631824] sd 8:0:0:0: [sde] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 1303.633608] sd 8:0:0:0: [sde] Write Protect is off
[ 1303.633620] sd 8:0:0:0: [sde] Mode Sense: 28 00 00 00
[ 1303.635385] sd 8:0:0:0: [sde] No Caching mode page found
[ 1303.635400] sd 8:0:0:0: [sde] Assuming drive cache: write through
[ 1303.638861] sd 8:0:0:1: Attached scsi generic sg6 type 0
[ 1303.639800] sd 8:0:0:1: [sdf] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 1303.642493] sd 8:0:0:1: [sdf] Write Protect is off
[ 1303.642504] sd 8:0:0:1: [sdf] Mode Sense: 28 00 00 00
[ 1303.645284] sd 8:0:0:1: [sdf] No Caching mode page found
[ 1303.645291] sd 8:0:0:1: [sdf] Assuming drive cache: write through
[ 1303.971976] sd 8:0:0:0: [sde] Attached SCSI disk
[ 1303.998311]  sdf: sdf1
[ 1304.002612] sd 8:0:0:1: [sdf] Attached SCSI disk
[ 1403.466410]  sde: sde1
                ^^^^^^^^^
but lsblk doesn't show it?  lsblk reads sysfs, so this seems very weird.

The fdisk stuff isn't super interesting; maybe as a fresh test, can you please do:

1) boot up
2) power on these two docking stations

then capture all of the output from:

3) dmesg
4) cat /proc/partitions
5) ls /sys/block/sde
6) lsblk

Thanks,
-Eric

George, 

please, copy & part to BZ output of

  blkid -p -o udev /dev/sde

(this is way how udevd probes the device to be sure it's really partition table, etc.) Thanks.

Created attachment 1114480 [details]
gzip'd flat file with info requested

Eric,

I did a clean reboot.

Powered on the enclosures in the SAME order.

It looks like sdf was completely lost?

George...

 blkid -p -o udev /dev/sde
ID_PART_TABLE_UUID=e68942c8-abe1-47f0-ba0a-ffa3fa954c01
ID_PART_TABLE_TYPE=gpt
fc22-bash 4.3 ~#  blkid -p -o udev /dev/sdf
error: /dev/sdf: No such file or directory

Comment on attachment 1114480 [details]
gzip'd flat file with info requested

Hohum, not sure why sdf wasn't discovered at all this time, but that seems to be a different issue.

What we're looking for is a case where the kernel reports discovery of a partition, i.e. -

[ 1303.971976] sd 8:0:0:0: [sde] Attached SCSI disk
...
[ 1403.466410]  sde: sde1
                     ^^^^ here

but that device is not present in /dev, etc.

Created attachment 1115103 [details]
gzip'd flat file with info requested

Eric,

I reseated all all the usb cables and the drives... all back to normal. I'm enclosing a flat file log of what I did. The procedure is repeatable if you want to see something else.

Thanks,

George...

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This bug exists in F23. Just happened today. lsblk showed an entry for sdb but not sdb1..8. fdisk /dev/sdb and immediate quit resolved the problem.

More info:

With the same devices present during boot, the dev entries are created properly.

George...

Hi,

Can I get someone to at least take a look at this bug please? It's happening right now.

Note: sdb has 8 partitions defined but only 1 shows!

fc23-bash 4.3 ~# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk
├─sda1   8:1    0     8G  0 part [SWAP]
├─sda2   8:2    0     2G  0 part /boot
├─sda3   8:3    0     2G  0 part /
├─sda4   8:4    0     1K  0 part
├─sda5   8:5    0     2G  0 part /var
├─sda6   8:6    0    41G  0 part /opt
├─sda7   8:7    0    41G  0 part /usr
└─sda8   8:8    0 835.5G  0 part /export/home
sdb      8:16   0   1.8T  0 disk
└─sdb1   8:17   0 698.7G  0 part
sdc      8:32   0 698.7G  0 disk
└─sdc1   8:33   0 698.7G  0 part
sr0     11:0    1  1024M  0 rom

fc23-bash 4.3 ~# fdisk /dev/sdb

Welcome to fdisk (util-linux 2.28).                                                                                                              
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): q

Note: Something fdisk does triggers the creation of dev entries for the other sdb partitions.

Note: There are 8 partitions discovered by lsblk

fc23-bash 4.3 ~# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0     8G  0 part [SWAP]
├─sda2   8:2    0     2G  0 part /boot
├─sda3   8:3    0     2G  0 part /
├─sda4   8:4    0     1K  0 part 
├─sda5   8:5    0     2G  0 part /var
├─sda6   8:6    0    41G  0 part /opt
├─sda7   8:7    0    41G  0 part /usr
└─sda8   8:8    0 835.5G  0 part /export/home
sdb      8:16   0   1.8T  0 disk
├─sdb1   8:17   0     2G  0 part
├─sdb2   8:18   0     2G  0 part
├─sdb3   8:19   0     5G  0 part
├─sdb4   8:20   0     1K  0 part
├─sdb5   8:21   0     7G  0 part
├─sdb6   8:22   0    31G  0 part
├─sdb7   8:23   0    31G  0 part
└─sdb8   8:24   0   1.8T  0 part
sdc      8:32   0 698.7G  0 disk
└─sdc1   8:33   0 698.7G  0 part
sr0     11:0    1  1024M  0 rom

The problem here is that this bug is filed against the wrong package - e2fsprogs has nothing to do with this behavior at all - but I don't know where it should be filed.

systemd-udevd maybe?  no idea.

Eric,

Thanks for responding...

How about the kernel?

George...

*********** MASS BUG UPDATE **************
 
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs.
 
Fedora 23 has now been rebased to 4.7.4-100.fc23.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25.
 
If you experience different issues, please open a new bug report for those.

I'll have to upgrade my system in order to check tins in 24. Problem STILL exists in 23 though.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Hi,

I changed this OS level to 25. This problem has changed behavior a bit.

Current config is one docking station with two disks. Each has partitions 1-8... dos partitions with sd4 an extended partition.

First power up showed just 4 partitions, sdb1/2/3/4... 5 6 7 8 missing. Partition map shows 1-8 though. 5-8 would not mount, even after running fdisk /dev/sdb which showed 8 partitions.

I powered off the docking station and then powered it back up. sdb1-8 appeared in the label and ALL partitions were mountable. 

I will test this after a reboot and report more info here from commands listed earlier in this bug report. Should I make a new report? Current rel -s Fedora 25 x86_64 and kernel 4.8.8-300.fc25.x86_64+debug.

Thanks for all your help.

George...

*********** MASS BUG UPDATE **************
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 25 kernel bugs.
 
Fedora 25 has now been rebased to 4.9.3-200.fc25.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26.
 
If you experience different issues, please open a new bug report for those.

Hi,

This problem seems to have gone away.

Thanks for all the hard work!

George...

Thank you for letting us know.

Laura,

This problem has started happening again. Current kernel is:
 4.13.0-0.rc0.git5.1.fc27.x86_64

I'm not using any of the more current kernels because they don't boot. I wrote an URGENT bug report and gave the needed info as requested but have heard nothing since. That bug is: [Bug 1471453] kernel /boot/ initramfs-4.13.0-0.rc0.git6.1.fc27.x86_64 fails to boot

Help!!!!! please.

George...

Hi,

This problem still exists as of kernel 4.13.0-0.rc3.git4.1.fc27.x86_64.

Is anyone working on this bug?

Thanks,

George...