blkid (sometimes?) hangs on extended partition if same device name existed before partitioning

As you can see in pic 3/9 killing os-prober causes the installer to make progress. I had to kill it again in 6/9 to complete the install. I have seen this problem in 3 netbooks already, I was unable to get any log/debug info because Nvidia graphics was messing up the VT. The above happend on a Acer Aspireone D250-1995

What do you mean, "not present"? 50mounted-tests just calls "blkid -o value -s TYPE /dev/sda2" here to identify the filesystem type. Why would that hang if /dev/sda2 doesn't exist?

As indicated in a duplicate bug, /dev/sda2 is an extended partition in this case that blkid is hanging.

My bug report #528225 would fall under this same bug.

I reinstalled Lucid Alpha 3 using the alternate CD, and grub install, os detection, and update-grub all worked flawlessly on the same hardware where blkid hung before with the desktop ubiquity install.

/dev/sda2 is the extended partition that only holds /dev/sda6 which is the swap file when using the entire disk.

reassigning to util-linux, which provides blkid.

Also - point to 528667

I'm confused.

The bug title says that /dev/sda2 *is not present*, but Mario says that it *is* present and is just an extended partition - which is it guys?

You'll have to ask Mario :-)

In my case, the partition table looked something like this:

sda1 Primary / 15.1GB
sda2 Extended 716MB
sda5 Logical swap 716MB

What seems to be happenign is that blkid is reading trying to get some sort of info from the extended partition, and AFAIK, extended partitions are just META partitions, and don't really posess things like UUID (I could be wrong, but that's my understanding at this point).

So yes, /dev/sda2 does exist, BUT it's simply an Extended partition, which really is just a metapartition containing X local partitions within.

Personally, I really do NOT like the use of extended partitions in default partitioning schemes. There's really no reason at all for the defaut partition scheme to look like this. I could see it for a custom scheme that involved more than 4 partitions, but for this, no.

IMO, the default partitioning should just be two primary partitions.

I have a feeling that this issue will not be seen in custom schemes or in schemes that use an existing partition (the "Install alongside" option. I haven't tried either of those though to find out.

On Fri, Feb 26, 2010 at 10:10:47PM -0000, Jeff Lane wrote:
> Personally, I really do NOT like the use of extended partitions in
> default partitioning schemes. There's really no reason at all for the
> defaut partition scheme to look like this. I could see it for a custom
> scheme that involved more than 4 partitions, but for this, no.

Using logical partitions wherever possible is much friendlier to
multi-boot systems, and in general puts much less stress on partitioning
algorithms that have to cope with the deficient but pervasive MS-DOS
partition table format. Since Ubuntu occasionally suffers from
installation problems on systems that already had four primary
partitions in place (or indeed, on some older BIOSes, three primary
partitions), it behooves us not to contribute to this situation
ourselves.

Good point, Colin. I concede :-)

As I said, that was just my preference, but with your explanation I can certainly understand where my prefs may not be ideal for the rest of the world.

I would like to clarify that this setup was created by the installer and created by the user, I was doing a fresh install of Lucid on a brand new system with Windows 7 pre-installed.

I would like to clarify that this setup was created by the installer and *NOT* created by the user, I was doing a fresh install of Lucid on a brand new system with Windows 7 pre-installed.

I got the excact same problem .. had to kill blkid twice during install to complete (on probing other OS and installing grub).
I had win7 installed, but chose to "use complete" disk during install (so no other OS would be present) Installer made 61GB(sda1) + 2.7GB Extended(sda2) + 2.7GB SWAP(sda5) on my 64G SSD.
Setup completly made by installer.

This bug was fixed in the package util-linux - 2.17-0ubuntu3

---------------
util-linux (2.17-0ubuntu3) lucid; urgency=low

  * Fix infinite loop in blkid when superblocks_probe bails out right at the
    start, as it may do on extended partitions (LP: #528073).
 -- Colin Watson <email address hidden> Sat, 13 Mar 2010 00:21:08 +0000

On Sat, 2010-03-13 at 01:42 +0000, Launchpad Bug Tracker wrote:

> util-linux (2.17-0ubuntu3) lucid; urgency=low
>
> * Fix infinite loop in blkid when superblocks_probe bails out right at the
> start, as it may do on extended partitions (LP: #528073).
> -- Colin Watson <email address hidden> Sat, 13 Mar 2010 00:21:08 +0000
>
Hi Colin,

Have you sent this patch upstream? Or did you steal it from there in
the first place?

Scott
--
Scott James Remnant
<email address hidden>

Yes, I sent it upstream just after uploading it.

  http://article.gmane.org/gmane.linux.utilities.util-linux-ng/3059

> 50mounted-tests just calls "blkid -o value -s TYPE /dev/sda2"

Note that since util-linux-ng 2.17 you can use low-probe mode (to avoid /etc/blkid.tab cache) for this task, it means:

    blkid -p -o value -s TYPE <device>

Thanks for the patch.

Installing Lucid Lynk 10.04 RC test ISO (on Wubi) from CD or ISO image mounted on XP, I had the same problem.

Workaround: clicking with the mouse, moving the window or hitting ENTER again and again let the install complete the task (but very slow!)

Previous comment related to:

"The installer hangs at 93% (looking for other OS)" the hang continues periodically until 100% installation is completed. (Ubuntu Lynx rebooted then works fine)

On Thu, Apr 22, 2010 at 09:31:09AM -0000, Alex - Microsmeta wrote:
> Installing Lucid Lynk 10.04 RC test ISO (on Wubi) from CD or ISO image
> mounted on XP, I had the same problem.

Are you sure, and if so how can you be sure? It seems more likely that
you have some different problem with similar symptoms; in any case,
please file a *new* bug attaching your installation logs (use
'ubuntu-bug ubiquity') rather than commenting on this one. Thanks.

Fresh install of 11.10

os-prober hangs on /usr/lib/os-probes/50mounted-tests repeatedly with many package installs/removals, kernel upgrades, grub updates, etc.
because of ntfs disagreements about /dev/sda2

I've learned I needed to kill pstree of 50mounted-tests repeatedly to unfreeze, and then often installations fail due to half-installed state.

os-prober hangs on /usr/lib/os-probes/50mounted-tests

  ├─su-to-root,2151,master /usr/sbin/su-to-root -X -c /usr/sbin/startupmanager
  │ └─gksu,2158 -u root /usr/sbin/startupmanager
  │ └─sudo,2160,root -H -S -p GNOME_SUDO_PASS -u root -- /usr/sbin/startupmanager
  │ └─python,2161 /usr/sbin/startupmanager
  │ ├─{python},2164
  │ └─sh,2165 -c /usr/sbin/update-grub
  │ └─grub-mkconfig,2166 /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg
  │ └─30_os-prober,2486 /etc/grub.d/30_os-prober
  │ └─30_os-prober,2499 /etc/grub.d/30_os-prober
  │ ├─os-prober,2500 /usr/bin/os-prober
  │ │ └─50mounted-tests,2633 /usr/lib/os-probes/50mounted-tests /dev/sda2
  │ │ └─10freedos,2645 /usr/lib/os-probes/mounted/10freedos /dev/sda2 /var/lib/os-prober/mount fuseblk
  │ │ ├─ls,2648 -1 /var/lib/os-prober/mount
  │ │ └─grep,2649 -q -i ^kernel.sys$
  │ ├─tr,2501 ^
  │ └─paste,2502 -s -d

==> /var/log/syslog <==
Jan 29 00:50:10 quant 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/10qnx
Jan 29 00:50:10 quant 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/20macosx
Jan 29 00:50:10 quant 10qnx: debug: /dev/sda2 is not a QNX4 partition: exiting
Jan 29 00:50:10 quant 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/20macosx
Jan 29 00:50:10 quant macosx-prober: debug: /dev/sda2 is a FUSE partition
Jan 29 00:50:10 quant macosx-prober: debug: /dev/sda2 is a FUSE partition
Jan 29 00:53:51 quant kernel: [12361.016087] INFO: task 20macosx:27533 blocked for more than 120 seconds.
Jan 29 00:53:51 quant kernel: [12361.016092] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

==> /var/log/kern.log <==
Jan 29 00:53:51 quant kernel: [12361.016087] INFO: task 20macosx:27533 blocked for more than 120 seconds.
Jan 29 00:53:51 quant kernel: [12361.016092] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 29 00:53:51 quant kernel: [12361.016096] 20macosx D 00000000 0 27533 2633 0x00000000
Jan 29 00:53:51 quant kernel: [12361.016103] f243ddb4 00000086 00006b91 00000000 f243dd82 f243dd58 c1761fe0 c186dec0
Jan 29 00:53:51 quant kernel: [12361.016112] c186dec0 8a31804f 00000b0a f5005ec0 f31d4c80 f31d0cc0 00000000 e5928013
Jan 29 00:53:51 quant kernel: [12361.016121] ee697ca8 00000005 00000005 f243de0c f243dec8 f243dd94 c113338e f243dea8
Jan 29 00:53:51 quant kernel: [12361.016130] Call Trace:
Jan 29 00:53:51 quant kernel: [12361.016142] [<c113338e>] ? __follow_mount_rc...

11.10

When calling "update-grub" (which is also called during upgrades of kernel packages), the process hangs. In the table of processes, I see a process called "grub-mount" trying to mount an ntfs partition. After manually killing it, it proceeds to my next ntfs partition, and agin hangs. After manually killing it again, it proceeds nicely with the rest of my partitions (non-ntfs).

This looks as if grub-mount has difficulties mounting ntfs partitions. This never happened before.