Fix udev rules to consider mmc rpmb partitions

Updated package to udev as the file 60-persistent-storage belongs to udev package.

Status changed to 'Confirmed' because the bug affects multiple users.

Multiple timeout errors occur when trying to install Ubuntu 14.10 on an Asus T100 Transformer. These take the form:

Aug 24 13:42:46 Asus-T100TA kernel: [ 517.844809] Buffer I/O error on device mmcblk0rpmb, logical block 16
Aug 24 13:42:54 Asus-T100TA kernel: [ 526.053415] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
Aug 24 13:42:54 Asus-T100TA kernel: [ 526.058826] mmcblk0rpmb: error -110 transferring data, sector 16, nr 8, cmd response 0x900, card status 0xb00
Aug 24 13:42:54 Asus-T100TA kernel: [ 526.061891] mmcblk0rpmb: retrying using single block read
Aug 24 13:42:55 Asus-T100TA kernel: [ 526.063938] mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
etc.

A workaround takes the form of a kernel patch, developed by Nell Hardcastle (https://dev-nell.com/rpmb-emmc-errors-under-linux.html), that essentially prevents access to the rpmb partition on the T100's eMMC drive and so avoids the timeout issue.

Otherwise, the timeout errors persist once Ubuntu has been installed and result in processing delays.

A permanent fix would be very much appreciated.

This bug is also a problem on the pipo w2.

Any permanent fix would be greatly appreciated here as well

Also experiencing this on an asus x205ta.

Also experiencing this on Acer ES1-111M-C40S.

Also experiencing this on HAIER w1048 lynx

Also experiencing this on HP Omni 10

Same issue on HP Stream 13. Sometimes the boot is a little bit faster, almost usable. Other times the system is completely unusable. This bug is a critical.

The file 60-persistent-storage.rules makes no difference.

Same issue on Medion AKOYA S6214T (MD 99380) with the timeouts. Nell's kernel patch helps.

Which Ubuntu release and kernel version does that apply to? Please send the uname -a output. Testing this under the current vivid kernel (3.18) would be very much appreciated. Thanks!

This occurs on an HP Stream 13 under 14.10. Is there a way to upgrade to vivid? `do-release-upgrade -d` failed for me.

Interesting, do-release-upgrade -d is certainly supposed to work. A bug report with the precise failure would be appreciated! s/utopic/vivid/ in /etc/apt/sources.list and good old "apt full-upgrade" (or apt-get dist-upgrade) works well. But keep in mind that vivid is still under development and pre-feature freeze/beta. So you might want to try a live system first (or only) :-)

Either way, I was mostly curious whether this only affects 14.04 or newer releases too.

Same bug occurs with Vivid (booted as live-system),

uname -a:
Linux ubuntu-desktop-next 3.18.0-12-generic #13-Ubuntu SMP Thu Jan 29 04:35:32 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

System: Acer ES1-111M

I don't have such a device and the original reporter wasn't very clear on where exactly he fixed the rules. I think I understand where it's going wrong, but to double-check, could you please replace /lib/udev/rules.d/60-persistent-storage.rules with this version and confirm that it's working properly now? Thanks!

I tested your new rules on my Acer ES1-111M but the issue still persists.

[ 1.595088] mmcblk0rpmb: mmc0:0001 HBG4e\x05 partition 3 4.00 MiB
...
[ 9.829699] mmcblk0rpmb: error -110 transferring data, sector 8064, nr 8, cmd response 0x900, card status 0xb00
[ 9.829706] mmcblk0rpmb: retrying using single block read
[ 9.831769] mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
[ 9.833802] mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
[ 9.835838] mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
[ 9.837868] mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
[ 9.839898] mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
[ 9.841937] mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
[ 9.841941] end_request: I/O error, dev mmcblk0rpmb, sector 8064
[ 9.841946] Buffer I/O error on device mmcblk0rpmb, logical block 1008
...

Don't you think this problem will be fixed with this kernel 3.20 commit ?

https://github.com/torvalds/linux/commit/aa7ed01f93ff7e149cad46f13f66b269d59c9bc0

@Patrick: Thanks for testing. With that new rule installed, could you please copy&paste the output of

  sudo udevadm test /block/mmcblk0rpmb

That might reveal what else is trying to access it. Thanks!

@jeremy: I don't see RPMB related changes in that commit, but then again I'm not a kernel developer and most of the patch doesn't actually tell me much.

Maybe this is more useful for you

http://blog.gmane.org/gmane.linux.kernel.mmc

http://permalink.gmane.org/gmane.linux.kernel.mmc/31066

@Martin: No Problem, you find the output attached.

@Patrick: That's why:

IMPORT 'udisks-part-id /dev/mmcblk0rpmb' /lib/udev/rules.d/80-udisks.rules:84
starting 'udisks-part-id /dev/mmcblk0rpmb'
'udisks-part-id /dev/mmcblk0rpmb' [10806] exit with return code 0

Apparently you still have the old udisks 1.x installed; can you try "sudo dpkg -P udisks"? If that doesn't work because you have one of the few packages installed that still need it, can you please temporarily move those aside with "sudo mv /lib/udev/rules.d/80-udisks.rules{,.disabled}"? Do you still get error messages after a reboot?

@Martin: This was the issue, problem now solved with disabling /lib/udev/rules.d/80-udisks.rules !

Thanks Patrick!

Status changed to 'Confirmed' because the bug affects multiple users.

http://cgit.freedesktop.org/systemd/systemd/commit/?id=b87b01c

Also experiencing this on Lenovo Thinkpad 10 tablet with Samsung eMMC.

I experience this with a HP Stream 13 and a clean 14.10 install. I tried the 60-persistent-storage.rules in #16, but they did not fix the problem, which I saw about 15 seconds into startup on dmesg.

It may have reduced the occurrences as I only saw it happen once.

Kernel is 3.16.0-23-generic #31-Ubuntu SMP

I experienced it on a fresh Ubuntu 14.04 LTS installation on an HP Stream 11. Tried the #26 patch but the dmesg errors are still there. Kernel is 3.13.0-45-generic #74-Ubuntu SMP.

This bug was fixed in the package systemd - 218-10ubuntu1

---------------
systemd (218-10ubuntu1) vivid; urgency=medium

  [ Martin Pitt ]
  * Merge with Debian unstable. Remaining Ubuntu changes:
    - Hack to support system-image read-only /etc, and modify files in
      /etc/writable/ instead.
    - Keep our much simpler udev maintainer scripts (all platforms must
      support udev, no debconf).
    - initramfs init-top: Drop $ROOTDELAY, we do that in a more sensible way
      with wait-for-root. Will get applicable to Debian once Debian gets
      wait-for-root in initramfs-tools.
    - initramfs init-bottom: If LVM is installed, settle udev,
      otherwise we get missing LV symlinks. Workaround for LP #1185394.
    - Add debian/udev.lvm2.init: Dummy SysV init script to satisfy insserv
      dependencies to "lvm2" which is handled with udev rules in Ubuntu.
    - Provide shutdown fallback for upstart. (LP: #1370329)
    - debian/extra/ifup@.service: Additionally run for "auto" class. We don't
      really support "allow-hotplug" in Ubuntu at the moment, so we need to
      deal with "auto" devices appearing after "/etc/init.d/networking start"
      already ran. (LP: #1374521) Also, check if devices are actually defined
      in /etc/network/interfaces as we don't use Debian's net.agent.
    - ifup@.service: Drop dependency on networking.service (i. e.
      /etc/init.d/networking), and merely ensure that /run/network exists.
      This avoids unnecessary dependencies/waiting during boot and dependency
      cycles if hooks wait for other interfaces to come up (like ifenslave
      with bonding interfaces). (LP: #1414544)
    - Add Get-RTC-is-in-local-time-setting-from-etc-default-rc.patch: In
      Ubuntu we currently keep the setting whether the RTC is in local or UTC
      time in /etc/default/rcS "UTC=yes|no", instead of /etc/adjtime.
      (LP: #1377258)
    - Put session scopes into all cgroup controllers. This makes unprivileged
      user LXC containers work under systemd. (LP: #1346734)
    - Lower Breaks: to plymouth version which has the udev inotify fix in
      Ubuntu.
    - Lower libappamor1 dep to the Ubuntu version where it moved to /lib.
    - Make failure of boot-and-services NSpawn.test_boot non-fatal for now.
      This currently fails when being triggered by Jenkins, but is totally
      unreproducible when running this manually on the exact same machine.

    Upgrade fixes, keep until 16.04 LTS release:
    - systemd Conflicts/Replaces/Provides systemd-services.
    - Remove obsolete systemd-logind upstart job.
    - Clean up obsolete /etc/udev/rules.d/README.

  * ifup@.service: Fix syntax error. (LP: #1421556, #1420601)

  [ Didier Roche ]
  * Add systemd-fsckd multiplexer and feed its output to plymouth. This
    provides an aggregate progress report of running file system checks and
    also allows cancelling them with ^C.
    (LP: #1316796; Closes: #775093, #758902)

systemd (218-10) experimental; urgency=medium

  * Pull latest keymaps from upstream git. (LP: #1334968, #1409721)
  * rules: Fix by-path of mmc RPMB partitions and don't blkid them. Avoids
    kernel buffer I/O errors and timeouts. (LP: #1333140...

Running latest Vivid daily build on Lenovo Thinkpad 10 with Samsung eMMC MDGAGC 116 GiB:

Ubuntu 15.04 (vivid-desktop-amd64.iso 2015-02-16 8:05)
Linux 3.18.0-13-generic
systemd 218-10ubuntu1

[ 12.337332] mmc0: BKOPS_EN bit is not set
[ 12.348788] mmc0: new HS200 MMC card at address 0001
[ 12.361382] input: ThinkPad 10 Touch Case as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/0003:17EF:6061.0001/input/input2
[ 12.361578] hid-generic 0003:17EF:6061.0001: input,hidraw0: USB HID v1.11 Keyboard [ThinkPad 10 Touch Case] on usb-0000:00:14.0-1/input0
[ 12.361964] input: ThinkPad 10 Touch Case as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.1/0003:17EF:6061.0002/input/input3
[ 12.362273] hid-generic 0003:17EF:6061.0002: input,hiddev0,hidraw1: USB HID v1.11 Mouse [ThinkPad 10 Touch Case] on usb-0000:00:14.0-1/input1
[ 12.369112] mmcblk0: mmc0:0001 MDGAGC 116 GiB
[ 12.369786] mmcblk0boot0: mmc0:0001 MDGAGC partition 1 4.00 MiB
[ 12.370414] mmcblk0boot1: mmc0:0001 MDGAGC partition 2 4.00 MiB
[ 12.370976] mmcblk0rpmb: mmc0:0001 MDGAGC partition 3 4.00 MiB
[ 12.376682] mmcblk0: p1 p2 p3 p4

Still get these errors:

[ 21.950514] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock
[ 21.950537] mmc0: Got data interrupt 0x00600000 even though no data operation was in progress.
[ 21.952904] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[ 21.955002] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400900
[ 21.955007] mmcblk0: error -84 transferring data, sector 244277120, nr 8, cmd response 0x900, card status 0x0
[ 21.955011] mmcblk0: retrying using single block read
...
[ 22.197516] mmcblk0boot0: error -84 transferring data, sector 8071, nr 1, cmd response 0x900, card status 0x0
[ 22.199814] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[ 22.201911] mmcblk0boot1: error -110 sending stop command, original cmd response 0x900, card status 0x400900
[ 22.201914] mmcblk0boot1: error -84 transferring data, sector 8064, nr 8, cmd response 0x900, card status 0x0
[ 22.201917] mmcblk0boot1: retrying using single block read
...
[ 22.241280] Buffer I/O error on dev mmcblk0boot0, logical block 1008, async page read
[ 22.244301] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[ 22.246331] mmcblk0boot1: error -110 sending stop command, original cmd response 0x900, card status 0x400900
[ 22.246335] mmcblk0boot1: error -84 transferring data, sector 8064, nr 8, cmd response 0x900, card status 0x0
[ 22.246337] mmcblk0boot1: retrying using single block read
[ 22.248553] mmcblk0boot1: error -84 transferring data, sector 8064, nr 8, cmd response 0x900, card status 0x0
...
[ 22.265044] Buffer I/O error on dev mmcblk0boot1, logical block 1008, async page read

Should we deal with the mmcblk[0-9]*boot[0-9]* pattern in the same way as the mmcblk[0-9]*rpmb one?

SneA, errors on the mmcblk0 device itself, and "-boot" are something different then. In general we do want to blkid those, as if they have a medium then we do want to recognize them. It wuold be intersting to see if we can detect whether they have a medium before we run blkid, perhaps there's something in /sys/block/mmcblk0/ ? Either way, new bug report would be appreciated.

Martin, new bug report created: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1422338

Thank you for the fix. Will it be available for those of us running 12.04, or should I file a new bug report requesting that?

Please don't file a new bug for SRU backports, that just makes all the information and status unnecessarily hard to track.

Understood, thanks Martin. Should I wait for the backports repository to refresh with the fix and then just apply it?

No, this won't be backported. This is a classic bug fix for stable-updates, I'll prepare uploads soon.

Status changed to 'Confirmed' because the bug affects multiple users.

I uploaded a trusty update for this to the SRU review queue. Please test the -proposed package once it is available to verify this, as it's not really practical to write down a test case which works independently of this affected hardware. Thanks!

Hello seshagiri, or anyone else affected,

Accepted systemd into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/204-5ubuntu20.11 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

The issue also affects Ubuntu 14.10 installed on 32GB eMMC (built-in instead of hard disk) on Acer Aspire ES1-111M.

Will the fix be released for Utopic Unicorn, too?

I Have the same problem with my new netbook using Trisquel 7 (based on Ubuntu 14.04).

I'm a Linux beginner and I'd like to know how to install the patch. Can anybody tell me how? Thank you!

Hello Simon,

simon thunder [2015-02-25 5:47 -0000]:
> I'm a Linux beginner and I'd like to know how to install the patch. Can
> anybody tell me how? Thank you!

See comment #42 in this bug report. It's documented here:
https://wiki.ubuntu.com/Testing/EnableProposed

Thanks!

Hello Martin,

Is there any way to implement the patch in Ubuntu 14.10 Utopic Unicorn? Or a new bug should be reported separately for this version?

Thanks

MitraX [2015-02-25 7:57 -0000]:
> Is there any way to implement the patch in Ubuntu 14.10 Utopic Unicorn?

Yes, we can SRU it there, too.

> Or a new bug should be reported separately for this version?

Pretty please no, that only confuses matters for everyone involved.

Martin

Martin:
> Yes, we can SRU it there, too.

OK, Martin, thank you. Please SRU it there, so I can test it.

I can confirm that the updated "proposed" packages fix the problem. I tested the updates on Ubuntu "trusty" and a derivative called Elementary OS Feeya Beta 2 running on an HP Stream 13. The messages and lag are gone once I'm in, but I still suffer from the 1-2 minute bootup lag that I think is associated with this emmc. I'm assuming the fix for this is coming in the form of a kernel patch.

Anyways, thanks for the fix!

Steve

@Martin Pitt

Thank you for replying.

I followed the steps to add Trusty-proposed and did my update, but Trisquel tells me that I need authentication keys and blabla... And I really don't know how to get those keys. Otherwise, can I manually install the patch?

Also, I wonder what would happen if I simply erase and format the mmcblk0rpmb partition in ext4. Is that partition really useful to Linux? I'm using a Trisquel-only machine in legacy mode. No UEFI, no Windows 8.

Thank you in advance for your answer!

 I went to add a sd card and fired up gparted. Right away the app hangs while scanning the drives and the lag started again. I went looked at the logs and the messages are back:

[ 3394.677696] mmcblk0rpmb: error -110 transferring data, sector 8, nr 8, cmd response 0x900, card status 0xb00
[ 3394.677705] mmcblk0rpmb: retrying using single block read
[ 3394.679751] mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
[ 3394.682344] mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
[ 3394.684389] mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
[ 3394.686483] mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
[ 3394.688591] mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
[ 3394.690695] mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
[ 3394.690702] blk_update_request: I/O error, dev mmcblk0rpmb, sector 8
[ 3394.690709] Buffer I/O error on dev mmcblk0rpmb, logical block 1, async page read

After about 20 minutes of waiting I was able to get the sd card partitioned and formatted. Once I closed gparted the messages aand lag are gone. I would now assume the problem isnt completely fixed.

Steve

> Also, I wonder what would happen if I simply erase and format the mmcblk0rpmb partition in ext4.

The Replay Protected Memory Block is not a normal partition. To access it you need the secret key it was most likely programmed with.

Even if you had this key it's unlikely you could do anything with it since this very bug looks like the kernel fails to communicate with it anyway.

> Is that partition really useful to Linux?

I think some Android OEMs might use it - I'd be very surprised if Ubuntu does.

It's quite unfortunate JEDEC re-used the word "partition". The "hardware" partitioning implemented by eMMC has nothing in common with the software partitioning everyone is familiar with (one sits on top of the other).

I finally found how to download and install trusty-proposed packages on Trisquel 7. But the patch doesn't work at all on my netbook. It still takes 17 minutes to boot up.

Now I'm wondering if I should wait until a patched kernel is released or if I should simply return my netbook back to the store...

Anyway, I'd like to thank all of you for the effort !

On my HP stream 11 with xubuntu 14.04, the 204.5ubuntu20.11 did not solve the issue.
(I do not know how to tag it as not working).

paolo, do you have the "udisks" package installed? If so, see above. If not, please file a new bug with the output of "sudo udevadm test /block/mmcblk0rpmb". Thanks!

This bug is resolved in my particular case, running Trusty 14.04.1 on kernel 3.16.0-31-generic on an Acer ES1-111M and without need of any editing of /lib/udev/rules.d/60-persistent-storage.rules

This bug was fixed in the package systemd - 204-5ubuntu20.11

---------------
systemd (204-5ubuntu20.11) trusty; urgency=medium

  [ Ben Howard ]
  * Add debian/extra/rules/62-google-cloudimg.rules: Use "noop" scheduler for
    Google virtio drives. (LP: #1420544)

  [ Martin Pitt ]
  * Add upstream-ignore-mmcrpmb.patch: Fix /dev/disk/by-path/ symlink of mmc
    RPMB partitions and don't blkid them to avoid kernel buffer I/O errors and
    timeouts. (LP: #1333140)
 -- Martin Pitt <email address hidden> Wed, 18 Feb 2015 12:11:49 +0100

The verification of the Stable Release Update for systemd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

A fix is great, however ..

I am unable to install Ubuntu 14.04 LTS on the HP Stream 11, due to this bug. The fix/update would fix this, but I would need to add it to the install image.

I can install Ubuntu 14.10 on the HP Stream 11, but it is slow to boot (due to this bug). This update is not yet released for Utopic (14.10), and may not soon either given the current focus on release of 15.04 ..

Considering raising new BUG (for Utopic, Velvet).

I think more work is needed here for 15.04 too. Booting ubuntu-15.04-desktop-amd64.iso, after a few minutes waiting at the splash screen I press escape and watch it struggle through another couple of minutes of errors related to mmcblk0rpmb.

I have the same problem with Ubuntu 15.04 (after upgrading from 14.10), too. It seems that the bug is not fixed at all.

Should we open a new bug or continue watching this one?

For anyone who is still affected, please run

  sudo udevadm test /block/mmcblk0rpmb

and copy&paste the output here.

Could you please tell us how to interrupt the boot process of the install iso and give a command shell to run this command? The boot process never ends even after 20+mins.

Ah, it's documented in /usr/share/doc/systemd/README.Debian. Boot with holding left shift to get the grub boot menu, "e"dit the default entry, and append "systemd.debug" on the "linux" line. Then you have a root shell on Ctrl+Alt+F9.

calling: test
version 219
=== trie on-disk ===
tool version: 219
file size: 6820666 bytes
header size 80 bytes
strings 1727930 bytes
nodes 5092656 bytes
Load module index
Network interface NamePolicy= disabled on kernel command line, ignoring.
timestamp of '/etc/systemd/network' changed
timestamp of '/lib/systemd/network' changed
Parsed configuration file /lib/systemd/network/99-default.link
Created link configuration context.
timestamp of '/etc/udev/rules.d' changed
Reading rules file: /lib/udev/rules.d/39-usbmuxd.rules
Reading rules file: /lib/udev/rules.d/40-crda.rules
Reading rules file: /lib/udev/rules.d/40-gnupg.rules
Reading rules file: /lib/udev/rules.d/40-hyperv-hotadd.rules
Reading rules file: /lib/udev/rules.d/40-inputattach.rules
Reading rules file: /lib/udev/rules.d/40-libgphoto2-6.rules
Reading rules file: /lib/udev/rules.d/40-libsane.rules
Reading rules file: /lib/udev/rules.d/40-usb-media-players.rules
Reading rules file: /lib/udev/rules.d/40-usb_modeswitch.rules
Reading rules file: /lib/udev/rules.d/40-xdiagnose.rules
Reading rules file: /lib/udev/rules.d/42-usb-hid-pm.rules
Reading rules file: /lib/udev/rules.d/50-apport.rules
Reading rules file: /lib/udev/rules.d/50-firmware.rules
Reading rules file: /lib/udev/rules.d/50-udev-default.rules
Reading rules file: /lib/udev/rules.d/55-dm.rules
Reading rules file: /lib/udev/rules.d/56-hpmud.rules
Reading rules file: /lib/udev/rules.d/56-lvm.rules
Reading rules file: /lib/udev/rules.d/60-cdrom_id.rules
Reading rules file: /lib/udev/rules.d/60-drm.rules
Reading rules file: /lib/udev/rules.d/60-keyboard.rules
Reading rules file: /lib/udev/rules.d/60-pcmcia.rules
Reading rules file: /lib/udev/rules.d/60-persistent-alsa.rules
Reading rules file: /lib/udev/rules.d/60-persistent-input.rules
Reading rules file: /lib/udev/rules.d/60-persistent-serial.rules
Reading rules file: /lib/udev/rules.d/60-persistent-storage-dm.rules
Reading rules file: /lib/udev/rules.d/60-persistent-storage-tape.rules
Reading rules file: /lib/udev/rules.d/60-persistent-storage.rules
Reading rules file: /lib/udev/rules.d/60-persistent-v4l.rules
Reading rules file: /lib/udev/rules.d/61-accelerometer.rules
Reading rules file: /lib/udev/rules.d/61-gnome-bluetooth-rfkill.rules
Reading rules file: /lib/udev/rules.d/61-persistant-storage-android.rules
Reading rules file: /lib/udev/rules.d/64-btrfs.rules
Reading rules file: /lib/udev/rules.d/64-xorg-xkb.rules
Reading rules file: /lib/udev/rules.d/66-xorg-synaptics-quirks.rules
Reading rules file: /lib/udev/rules.d/69-cd-sensors.rules
Reading rules file: /lib/udev/rules.d/69-libmtp.rules
Reading rules file: /lib/udev/rules.d/69-lvm-metad.rules
Reading rules file: /lib/udev/rules.d/69-xorg-vmmouse.rules
Reading rules file: /lib/udev/rules.d/70-btrfs.rules
Reading rules file: /lib/udev/rules.d/70-mouse.rules
Reading rules file: /etc/udev/rules.d/70-persistent-net.rules
Reading rules file: /lib/udev/rules.d/70-power-switch.rules
Reading rules file: /lib/udev/rules.d/70-printers.rules
Reading rules file: /lib/udev/rules.d/70-touchpad.rules
Reading rules file: /lib/udev/rules.d/70-uaccess.rules
Reading rules file: /lib/udev/...

Thanks Daniel. There is nothing any more which tries to access the rpmb device from the udev rule, so something else seems to probe it now. I'm afraid I don't have an off-hand idea what that could be

ChromeOS fix/workaround: https://chromium-review.googlesource.com/#/q/Ibb21a90a754261f0bb5b0f03b868ad8d8dbc6530

I have done repeated installs of 14.04 LTS and 15.04 on an HP Stream 11 notebooks.

This issue generally does NOT occur, other than briefly during initial load of Ubuntu installer (and sometimes during early stages of install). This adds no more than 15% to the time it takes to install Ubuntu (with eMMC storage), and will usually take less than 30 minutes.

However, I realised recently that this was ONLY true for new machines, or those I had already installed Ubuntu on. Out of the box, I was interrupting initial startup (at screen backlight on) to go directly to (BIOS controls for) booting from USB device.

For machines that had were already running Windows 8.1 (or even just asking for region / user details), it will no longer cleanly install Ubuntu. I have had it take from 2 hours to 5-7 hours, or just stall (after about 40 minutes) with continuous errors. This appears to be spurious interrupts (which cause further errors) due to attempts to access the RPMB partition. I am NOT even convinced that the Ubuntu installer is causing these interrupts.

The other possible 'root cause' is that the problem machines (NEW or used) were older, the same model Notebook but with an earlier generation / step release of eMMC chips. I don't have a large enough pool to prove this, but someone may be able to shed light.

Am hoping someone can still help me out with this; I've updating 60-persistent-storage.rules, but still have a delay in start up. . . Looks like to me there are other rules related to USB trying to access, please help!

patrick@patrick-Aspire-ES1-111M ~ $ uname -a
Linux patrick-Aspire-ES1-111M 3.16.0-36-generic #48~14.04.1-Ubuntu SMP Wed Apr 15 13:12:28 UTC 2015 i686 i686 i686 GNU/Linux

calling: test
version 204
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

=== trie on-disk ===
tool version: 204
file size: 5773073 bytes
header size 80 bytes
strings 1271633 bytes
nodes 4501360 bytes
load module index
read rules file: /lib/udev/rules.d/40-crda.rules
read rules file: /lib/udev/rules.d/40-gnupg.rules
read rules file: /lib/udev/rules.d/40-hyperv-hotadd.rules
read rules file: /lib/udev/rules.d/40-inputattach.rules
read rules file: /lib/udev/rules.d/40-libgphoto2-6.rules
GOTO 'libgphoto2_usb_end' has no matching label in: '/lib/udev/rules.d/40-libgphoto2-6.rules'
read rules file: /lib/udev/rules.d/40-usb-media-players.rules
read rules file: /lib/udev/rules.d/40-usb_modeswitch.rules
read rules file: /lib/udev/rules.d/42-usb-hid-pm.rules
read rules file: /lib/udev/rules.d/50-firmware.rules
read rules file: /lib/udev/rules.d/50-udev-default.rules
read rules file: /lib/udev/rules.d/55-dm.rules
read rules file: /lib/udev/rules.d/56-lvm.rules
read rules file: /lib/udev/rules.d/60-cdrom_id.rules
read rules file: /lib/udev/rules.d/60-keyboard.rules
read rules file: /lib/udev/rules.d/60-pcmcia.rules
read rules file: /lib/udev/rules.d/60-persistent-alsa.rules
read rules file: /lib/udev/rules.d/60-persistent-input.rules
read rules file: /lib/udev/rules.d/60-persistent-serial.rules
read rules file: /lib/udev/rules.d/60-persistent-storage-dm.rules
read rules file: /lib/udev/rules.d/60-persistent-storage-tape.rules
read rules file: /lib/udev/rules.d/60-persistent-storage.rules
read rules file: /lib/udev/rules.d/60-persistent-v4l.rules
read rules file: /etc/udev/rules.d/60-vboxdrv.rules
read rules file: /lib/udev/rules.d/61-accelerometer.rules
read rules file: /lib/udev/rules.d/61-gnome-bluetooth-rfkill.rules
read rules file: /lib/udev/rules.d/62-google-cloudimg.rules
read rules file: /lib/udev/rules.d/64-btrfs.rules
read rules file: /lib/udev/rules.d/64-xorg-xkb.rules
read rules file: /lib/udev/rules.d/66-xorg-synaptics-quirks.rules
read rules file: /lib/udev/rules.d/69-libmtp.rules
read rules file: /lib/udev/rules.d/69-xorg-vmmouse.rules
read rules file: /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules
read rules file: /etc/udev/rules.d/70-persistent-net.rules
read rules file: /lib/udev/rules.d/70-power-switch.rules
read rules file: /lib/udev/rules.d/70-printers.rules
read rules file: /lib/udev/rules.d/70-uaccess.rules
read rules file: /lib/udev/rules.d/71-seat.rules
read rules file: /lib/udev/rules.d/73-idrac.rules
read rules file: /lib/udev/rules.d/73-seat-late.rules
read rules file: /lib/udev/rules.d/75-net-description.rules
read rules file: /lib/udev/rul...

It's also important that you fix the live medium + installer because it takes a long time to boot up an install ubuntu.

Status changed to 'Confirmed' because the bug affects multiple users.

Hi - I'm not sure if this is the right place to put this (and apologies if it isn't!), but I think what I'm experiencing on my HP Stream 11 might be related to this issue. I just posted full details on askubuntu here:
http://askubuntu.com/questions/687018/new-14-04-install-on-hp-stream-11-wont-boot-up

This issue is still present on 16.04.1 LTS, and is not resolved by being fully updated.

It is also present for 16.10 ..

While use of eMMC is not widespread, this UNRESOLVED issue causes (at very least) a 15-20 second delay on startup.

Verified still present, for 16.10 ..

New install of 16.10 on 'HP Stream 11 Pro G2'. No issue with install, other than slight delay at startup/re-start(s). Exhibits 15-20 second delay (with screen purple) at EVERY power on/startup.

No change, from issue for 16.04 LTS.

> While use of eMMC is not widespread,...

A majority of Chromebooks rely on eMMC these days...

> Exhibits 15-20 second delay (with screen purple) at EVERY power on/startup.

... and their *total* boot time is way shorter than 10 seconds.

If you're curious, ChromeOS kernels are here:

https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/chromeos-4.4/drivers/mmc
https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/chromeos-3.18/drivers/mmc
https://chromium-review.googlesource.com/#/c/273998/
etc.

This isn't caused by ubiquity if it's at startup, since ubiquity would only care about it w/r/t partitioning, and that hasn't been the case since somewhere during the development cycle of 16.04 -- when we updated partman-base to stop trying to partition rpmb devices.

Closing the ubiquity task as Invalid. Clearly, there's something else that breaks there.

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release