Bug#856590: systemd: Unspecified problems mounting /usr partition

[Emmanuel DECAEN]

Hi,

Le 31/03/2017 à 10:21, Michael Biebl a écrit :
> The udevadm info dump you attached shows that TAGS=:systemd: is missing
> for all your partitions, thus systemd doesn't consider them ready.

The flag is no more missing, and the boot problem is still present.

udevadm info /dev/sda6
P: 
/devices/pci0000:00/0000:00:16.1/0000:0c:00.0/host2/target2:0:0/2:0:0:0/block/sda/sda6
N: sda6
S: disk/by-partuuid/000586b9-06
S: disk/by-path/pci-0000:0c:00.0-scsi-0:0:0:0-part6
S: disk/by-uuid/08511bfb-ef79-432c-b792-c455ec64679e
E: DEVLINKS=/dev/disk/by-partuuid/000586b9-06 
/dev/disk/by-path/pci-0000:0c:00.0-scsi-0:0:0:0-part6 
/dev/disk/by-uuid/08511bfb-ef79-432c-b792-c455ec64679e
E: DEVNAME=/dev/sda6
E: 
DEVPATH=/devices/pci0000:00/0000:00:16.1/0000:0c:00.0/host2/target2:0:0/2:0:0:0/block/sda/sda6
E: DEVTYPE=partition
E: ID_BUS=scsi
E: ID_FS_TYPE=ext3
E: ID_FS_USAGE=filesystem
E: ID_FS_UUID=08511bfb-ef79-432c-b792-c455ec64679e
E: ID_FS_UUID_ENC=08511bfb-ef79-432c-b792-c455ec64679e
E: ID_FS_VERSION=1.0
E: ID_MODEL=Virtual_disk
E: ID_MODEL_ENC=Virtual\x20disk\x20\x20\x20\x20
E: ID_PART_ENTRY_DISK=8:0
E: ID_PART_ENTRY_NUMBER=6
E: ID_PART_ENTRY_OFFSET=46874624
E: ID_PART_ENTRY_SCHEME=dos
E: ID_PART_ENTRY_SIZE=7811072
E: ID_PART_ENTRY_TYPE=0x83
E: ID_PART_ENTRY_UUID=000586b9-06
E: ID_PART_TABLE_TYPE=dos
E: ID_PART_TABLE_UUID=000586b9
E: ID_PATH=pci-0000:0c:00.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-0000_0c_00_0-scsi-0_0_0_0
E: ID_REVISION=1.0
E: ID_SCSI=1
E: ID_TYPE=disk
E: ID_VENDOR=VMware
E: ID_VENDOR_ENC=VMware\x20\x20
E: MAJOR=8
E: MINOR=6
E: PARTN=6
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=2997221


>
> That tag is set in /lib/udev/rules.d/99-systemd.rules.  Is that file
> missing?

This file is present.

> Do you have any custom udev rules in /etc/udev/rules.d ?

ls -l /etc/udev/rules.d/
-rw-r--r-- 1 root root 789 Mar  6  2012 70-persistent-cd.rules

>
> Another (probably unrelated) observation is, that your /etc/fstab uses
> type ext4 while the udev info shows ID_FS_TYPE=ext3

Oups, this morning, i'm converting ext3 to ext4, you should consider the 
following /etc/fstab:

# <file system> <mount point>   <type> <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# / was on /dev/sda1 during installation
UUID=0ab4af79-6e21-4c58-8514-2cf849d53ae1 /     ext3 errors=remount-ro 
0       1
# /home was on /dev/sda7 during installation
UUID=60dac49d-8399-4a6f-9ded-7adc952fc33e /home ext4 defaults 0       2
# /tmp was on /dev/sda6 during installation
UUID=08511bfb-ef79-432c-b792-c455ec64679e /tmp  ext3 defaults 0       2
# /var was on /dev/sda5 during installation
UUID=66610011-7694-4574-ba2f-7ab34169b037 /var  ext3 defaults 0       2
# swap was on /dev/sda2 during installation
UUID=840f5b96-d8ce-4ad5-9750-330cb69bf691 none  swap sw 0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0 0

/dev/sda7 is now converted:
  udevadm info /dev/sda7
[...]
S: disk/by-uuid/60dac49d-8399-4a6f-9ded-7adc952fc33e
E: DEVLINKS=/dev/disk/by-path/pci-0000:0c:00.0-scsi-0:0:0:0-part7 
/dev/disk/by-p artuuid/000586b9-07 
/dev/disk/by-uuid/60dac49d-8399-4a6f-9ded-7adc952fc33e
E: DEVNAME=/dev/sda7
[...]
E: ID_FS_TYPE=ext4
E: ID_FS_USAGE=filesystem
[...]

The problem is still present with this /etc/fstab configuration.

> In any case, we shouldn't hijack this bug report. It's probably not the
> same issue.

If you think it's not related, I can open a new bug report.

Thanks

-- 
*Emmanuel DECAEN*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20170331/5d11a5ff/attachment-0002.html>