I tracked down the cause of the problem. Utility 'probepart' was written in the 2.x kernel days, when /proc/partitions does not list optical media. That is, 'sr0' is not listed, regardless of whether any media is inserted or not.
Sometime, I presume with the 3.x series (I only tested 188.8.131.52, 3.2.29, 3.6.11), /proc/partitions does list sr0.
Initially, with no media in the optical drive, this is what is listed in /proc/partitions:
11 0 1048575 sr0
After inserting a media, the entry changes to reflect the amount of used space in the optical media, for example:
11 0 771392 sr0
...curiously, after removing the media, that size parameter stays the same in /proc/partitions.
Anyway, probepart obtains information about the optical media from /sys/block, and the inclusion of optical drive info in /proc/partitions causes trouble in the script -- the exact trouble reported was the desktop icon not appearing when an audio-CD was inserted.
The solution is to screen sr[0-9] out of /proc/partitions in script 'probepart'. I have done it, see the relevant code portion:
#devices that have partitions...
#([^k] is to eliminate mmcblk0 device -- allow mmcblk0p1 etc) v4.01 bugfix eliminate ram...
#130127 [^kr] screens out sr0-sr9. 2.x kernels do not have these in /proc/partitions, 3.x do, which causes desktop icon to not appear when audio-cd inserted.
PARTITIONS="`grep '^ .*[^kr][0-9]$' /proc/partitions | tr -s ' ' | cut -f 4-5 -d ' ' | grep -vE ' loop| ram'`" #each line ex: 16076800 sda5
PARTNAMES="`echo "$PARTITIONS" | cut -f 2 -d ' '`" #120602
This is quite an important bug fix, affecting all pups. I will need to bring out a Service Pack for Precise soon.
Comments:Posted on 27 Jan 2013, 9:28 by BarryK
Of course, my fix is going to stuff things up if someone has drives /dev/sdr0+.
Possible, but pretty unlikely. It would be an extreme system with that many drives.
Posted on 27 Jan 2013, 19:38 by 01micko
I notice the comment in /sbin/probepart script
"(tested 184.108.40.206 and 3.2.29+, so not sure exact version this difference came in(tested 220.127.116.11 and 3.2.29+, so not sure exact version this difference came in(tested 18.104.22.168 and 3.2.29+, so not sure exact version this difference came in)"
A lot changed in 3.2 series kernels and beyond, as old probepart worked fine in Slacko-5.3.3 with k3.1.10.
On another note, we have found a serious bug, which seems to be kernel related (again 3.2 plus). follow slacko discussion from the post linked, (affects precise too apparently). It is a severe slow down of IO under certain conditions, several members are affected.
Sorry, no link, forum is down for me, anyway, post is by forum member SFR on about page 8 of slacko-5.4 bugs reports, and discussion is ongoing. I'll link when I can access the forum.
Posted on 27 Jan 2013, 20:47 by BarryK
Yes, down for me too, last couple of hours.
Posted on 27 Jan 2013, 23:26 by Ted Dog
While you got the hood/bonnet open on probepart, could you review the forcing of iso format on udf identified discs, after viewing the horrific coding and patch on top of patch I gave up trying to fix this. UDF is backward compatible to ISO not vise-avers as forced in probepart.
Posted on 28 Jan 2013, 2:29 by GCMartin
UDF on DVD/CD processing
If I understand @TedDog, that might be key to issues seen with CD/DVD use, and writing.
Posted on 28 Jan 2013, 5:51 by ozsouth
sr0 & sr1
In Slacko 533, inserting a USB mobile broadband dongle, then a CD, sr0 & sr1 appear. Eject CD, then try another = not recognised, as /dev/cdrom disappears. Fixed in Slacko 540. I'm clueless.
Posted on 28 Jan 2013, 17:10 by BarryK
Yes, the udf problem has been around for a long time.
I have finally decided to fix it properly. Working on it now.
Posted on 28 Jan 2013, 22:44 by BarryK
Done, see later blog post:
Note, probepart has been modified again.