thelinuxlink.net

So, who can figure this one out? KDE 3.5.1, latest arch everything, using udev and hal to deal with removable devices. I'm planning on hitting the mailing list or filing a bug unless I can figure out that I'M doing something dumb here. This was working perfectly before the new big fun udev upgrade.


** plugged the ipod in - no hal joy
Feb 28 23:42:59 pinkwater sbp2: $Rev: 1306 $ Ben Collins <bcollins@debian.org>
Feb 28 23:42:59 pinkwater ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)
Feb 28 23:42:59 pinkwater ieee1394: sbp2: Try serialize_io=0 for better performance
Feb 28 23:42:59 pinkwater scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices
Feb 28 23:43:00 pinkwater ieee1394: sbp2: Logged into SBP-2 device
Feb 28 23:43:00 pinkwater Vendor: Apple Model: iPod Rev: 1.53
Feb 28 23:43:00 pinkwater Type: Direct-Access-RBC ANSI SCSI revision: 02
Feb 28 23:43:04 pinkwater sdb: Spinning up disk.....ready
Feb 28 23:43:04 pinkwater SCSI device sdb: 29297520 512-byte hdwr sectors (15000 MB)
Feb 28 23:43:04 pinkwater sdb: test WP failed, assume Write Enabled
Feb 28 23:43:04 pinkwater SCSI device sdb: 29297520 512-byte hdwr sectors (15000 MB)
Feb 28 23:43:04 pinkwater sdb: test WP failed, assume Write Enabled
Feb 28 23:43:04 pinkwater sdb: sdb1 sdb2
Feb 28 23:43:04 pinkwater sd 1:0:0:0: Attached scsi removable disk sdb

** restarted udev (/etc/start_udev) - WTF??
** there is no cdrom in the drive. This is reproducible.
Feb 28 23:46:47 pinkwater cdrom: open failed.
Feb 28 23:46:47 pinkwater cdrom: open failed.
Feb 28 23:46:47 pinkwater cdrom: open failed.
Feb 28 23:46:47 pinkwater cdrom: open failed.
Feb 28 23:46:49 pinkwater cdrom: open failed.
Feb 28 23:46:51 pinkwater cdrom: open failed.
Feb 28 23:46:53 pinkwater cdrom: open failed.
...snip...


**restarted udev again - this time hal placed an icon on my desktop
Feb 28 23:47:36 pinkwater scsi3 : SCSI emulation for IEEE-1394 SBP-2 Devices
Feb 28 23:47:38 pinkwater ieee1394: sbp2: Logged into SBP-2 device
Feb 28 23:47:38 pinkwater Vendor: Apple Model: iPod Rev: 1.53
Feb 28 23:47:38 pinkwater Type: Direct-Access-RBC ANSI SCSI revision: 02
Feb 28 23:47:41 pinkwater sdb: Spinning up disk.....ready
Feb 28 23:47:41 pinkwater SCSI device sdb: 29297520 512-byte hdwr sectors (15000 MB)
Feb 28 23:47:41 pinkwater sdb: test WP failed, assume Write Enabled
Feb 28 23:47:41 pinkwater SCSI device sdb: 29297520 512-byte hdwr sectors (15000 MB)
Feb 28 23:47:41 pinkwater sdb: test WP failed, assume Write Enabled
Feb 28 23:47:41 pinkwater sdb: sdb1 sdb2
Feb 28 23:47:41 pinkwater sd 3:0:0:0: Attached scsi removable disk sdb

** double-clicked icon to mount, mounts fine - wtf, again?
Feb 28 23:48:22 pinkwater UDF-fs: No VRS found
Feb 28 23:48:22 pinkwater Unable to identify CD-ROM format.

*** "safely removed" ipod, and unplugged it
*** This doesn't happen if hal doesn't handle the ipod
Feb 28 23:49:08 pinkwater sdb: Spinning up disk.......<7>ieee1394: Node changed: 0-01:1023 -> 0-00:1023
Feb 28 23:49:09 pinkwater .<3> 3:0:0:0: rejecting I/O to dead device
Feb 28 23:49:09 pinkwater ready
Feb 28 23:49:09 pinkwater sdb : READ CAPACITY failed.
Feb 28 23:49:09 pinkwater sdb : status=0, message=00, host=1, driver=00
Feb 28 23:49:09 pinkwater sdb : sense not available.
Feb 28 23:49:09 pinkwater sdb: Write Protect is off
Feb 28 23:49:09 pinkwater sdb : READ CAPACITY failed.
Feb 28 23:49:09 pinkwater sdb : status=0, message=00, host=1, driver=00
Feb 28 23:49:09 pinkwater sdb : sense not available.
Feb 28 23:49:09 pinkwater sdb: Write Protect is off
Feb 28 23:49:09 pinkwater sdb:<3> 3:0:0:0: rejecting I/O to dead device
Feb 28 23:49:09 pinkwater unable to read partition table

I am probably not going to be much help here, but I'll brainstorm...

On my Arch test box I also had trouble with udev/hal. Turned out I also needed to have portmap and fam installed and starting up as a daemon in /etc/rc.conf. You might want to try that.

Also, is your ipod an hfs+ formatted ipod or a vfat formatted ipod (i.e. do you also connect it to a mac or windows pc)? If it's the former, then part of the problem is that, from my understanding, the hfsplus module has poor write support (although it has worked OK for me in writing to a HFS+ firewire hard drive). Don't know if there is a fix for that other than reformatting.

Do you have any custom udev rules? I believe the udev rule format changed slightly recently. If you have upgraded Arch to the latest udev, you may want to try disabling your custom rules and restart udev and see if that makes a difference.

Sorry I can' t be more help. Udev/hal etc. is a PITA to be sure.

As recently as three days ago this worked perfectly, so unless there are new requirements, I can't imagine installing more software is going to change things. I could be wrong though, and am certainly willing to give it a shot.

The ipod is fat32 - I didn't want to deal with rolling my own kernel with hfsplus support, and the default arch kernel doesn't have it.

No custom udev rules - it took me forever to get my ipod working since all of the documentation I'd read was wrong. I'd been using udev rules and fstab entries, and even created a static mount icon on my desktop, which mostly worked. It turns out that all I needed to do (before the last upgrade) was add hal to my disk group. After removing all rules and fstab entries dealing with the ipod, I was good to go.

Thanks for helping me brainstorm! I don't really mind fixing issues like these *once* but goddamnit I JUST fixed this problem before the flippin update. Ugh - "bleeding edge." Honestly, this was my biggest fear, and it came to pass.

I hacked around this issue by reverting to how things were done 18 months ago - I added a udev rule, fstab rule, and a mount-point. I also made a static icon on my desktop. Mmmm....sweet progress.

The problem is that every 5 or 6 times I insert the ipod, it get's detected by hal, and I have from 2 to 4 icons on my desktop all of a sudden. In these cases "sdb2" fails to unmount at all, and I have to hit the command line to unmount the damned thing.

Fun. I know I should have waited to upgrade this garbage. Too many packages I wanted to install "depended" on this new stuff though. I'm starting to see where deps can be a bad thing, for sure.

Ahhhhhhhh.

Now I'm back to insanely slow transfer speeds to the ipod too. Like slower than transfer over ethernet slow. Meaning 3-5 min per podcast.

http://lwn.net/Articles/172306/: scroll down to the sysfs discussion. Could it be something related to that?

404ed! That link takes me to a not found page.

There is a colon at the end of his link. Just remove it and it will work.

Well, it might have something to do with it, but arch is still on 2.6.15, not 16. Maybe my problem is hal and dbus, not udev? I don't even know what other reasonable options are at this point. Pmount and ivman?

What the f.uck is wrong with me? Why can't I find a linux distro to stick with that doesn't end up turning on me? Is slack really the answer? I'm awfully nervous about no dep checking to be honest.

OK, poking around a little more I've discovered that the usb_storage module still plays nice with hal and dbus - it pops a nice icon right on my desktop. The transfer speeds are ungodly slow though, just like with the firewire module. Something sis seriously fscked here. I've even removed and reinstalled hal, dbus and udev. No change at all. I guess I'll just need to start my sync the night before...

Snarkout wrote:Well, it might have something to do with it, but arch is still on 2.6.15, not 16. Maybe my problem is hal and dbus, not udev? I don't even know what other reasonable options are at this point. Pmount and ivman?

What the f.uck is wrong with me? Why can't I find a linux distro to stick with that doesn't end up turning on me? Is slack really the answer? I'm awfully nervous about no dep checking to be honest.

Don't let people scare you about the dependency checking issues in Slackware. Mostly people that never ran Slackware complain about that. What most people don't know is that most package creators for Slackware actually fulfill all the dependencies inside the package. On the occasion that that isn't true and you don't already have the necessary dependencies filled, it really isn't that hard to find what you need.

Linc wrote:Don't let people scare you about the dependency checking issues in Slackware. Mostly people that never ran Slackware complain about that. What most people don't know is that most package creators for Slackware actually fulfill all the dependencies inside the package. On the occasion that that isn't true and you don't already have the necessary dependencies filled, it really isn't that hard to find what you need.

I agree with Linc. Here is what I tell my friends who are trying Slackware:

1. Do a full install when installing Slackware. You only need disks 1 and 2 to do a full install (and really Disk 1 contains 99% of the base system. Disk 2 contains KDE and other desktop environments). Disks 3 and 4 contain /extra, /testing, /pasture, source code, and docs. You can get those from the net later on if necessary.

2. Stick with the stable branch. Upgrade packages from -current on a selective or as-needed basis, but be sure to read Pat V's -current changelog before doing so. He will tell you when there are problems with a particular package in -current.

3. If you want to use a tool to do automatic updates, use slackpkg. Be sure to blacklist certain things like the kernel, the aaa_base, aaa_elflibs, and alsa before doing an update. It is important to blacklist those 4, especially the two aaa_ packages -- those are meta type packages that PV says should never be uninstalled or upgraded. Browse the LinuxQuestions.org Slackware forum for "slackpkg" and there are good tips for what else to blacklist.

4. If you do a full iinstall, then compiling anything you need that is not included is very, very simple. It will just work. I promise.

5. Use "checkinstall" to actually install your compiled binaries. Checkinstall will add the package to the pkgtool-maintained list thereby making it easy to remove later on if necessary.

6. If you want to use GNOME, try Freerock or Gware.

7. Read Pat's -stable and -current changelogs on a regular basis. They are the keys to maintaining a stable system.

8. Most packages in linuxpackages.net are ok. But, there are occasional issues so it's still better to compile your own.

9. The official Slackware forums at LQ are excellent. Also, http://www.slackbook.org and http://www.slackbasics.org are two excellent manuals.

10. Enjoy your new Slackness.

OK, thanks. I'm planning to get slackware up on my testing box this weekend, and to work with it some. I'd like to get grub configured w/o blowing my box up.

So, you don't use swaret or slapt-get? Does slackpkg offer the same type of functionality? I'm completely happy with the idea of compiling and using checkinstall - I did that for years using debian.

I really DO like arch, and recognize that recent issues I've been having are likely not the fault of the arch devs (well, other than they moved packeages from testing to current before they were ready for prime-time IMO). Pacman is brilliant, and for the most part, it has been a pleasure to work with a clean, lean system. I've never been interested in bleeding edge anything though. Frankly, it's pretty obvious that most people posting on the arch BBS are in their (teens|early 20s). Most of them are very, very smart. Most of them also have a LOT more spare time than I do, too. I've got a job that is more or less 24/7 on-call, a 3 year old, and a new one due in 6-8 weeks, and am attending school part time. I'm probably not a prime candidate for a bleeding edge distro any more.

Snarkout wrote:I really DO like arch, and recognize that recent issues I've been having are likely not the fault of the arch devs (well, other than they moved packeages from testing to current before they were ready for prime-time IMO). Pacman is brilliant, and for the most part, it has been a pleasure to work with a clean, lean system. I've never been interested in bleeding edge anything though. Frankly, it's pretty obvious that most people posting on the arch BBS are in their (teens|early 20s). Most of them are very, very smart. Most of them also have a LOT more spare time than I do, too. I've got a job that is more or less 24/7 on-call, a 3 year old, and a new one due in 6-8 weeks, and am attending school part time. I'm probably not a prime candidate for a bleeding edge distro any more.

I'm with you on this one. Arch is very promising but this 'upgrade' was a major clusterfuck! If my workstation upgrade doesn't go well either I might have to get it off my machine. I hope not.

Snarkout wrote:So, you don't use swaret or slapt-get? Does slackpkg offer the same type of functionality? I'm completely happy with the idea of compiling and using checkinstall - I did that for years using debian.

No, I don't use swaret or slapt-get but many do. Slackpkg offers more or less the same functionality but slackpkg does not update from 3rd party repositories. Swaret/slapt-get can update from linuxpackages.net and other 3rd party repos.

I use slackpkg to update my system when Pat V. and the Slack Sec Team issue security patches or bug fixes into the /patches directory. You can also point slackpkg to the -current tree and then use it to grab packages from -current. So, for example, 10.2 shipped with KDE 3.4.x. Pat V. put 3.5.1 into -current. If you keep slackpkg pointed at the 10.2 stable tree, then of course you won't get the updated kde packages. But, you can temporarily point slackpkg to -current to grab 3.5.1 and then change it back to -stable.

Other people point slackpkg to -current and just run -current all the time.

I like Arch a lot too. I have it on my secondary workstation. But I also have run into issues. Last night, I tried installing kde, and it grabbed all the kde packages but then when it tried to install them, there were a bunch of failed upgrade errors due to the fact that it looked like kde was looking for some xorg7 packages. I have not updated xorg to xorg7 but if xorg7 is a depencency of kde, then something seems wrong with that. I should be able to keep my xorg6.8 and update to kde 3.5.1. After hearing all the KDE talk on TLLTS, I wanted to try it out but couldn't install it. Arch is great, but there are definitely occasional issues with their repos and package selections. I ran into these types of issues when I first tried Arch 2 years ago and those issues are still there. It's a great distro and I sent them a donation (before their server donation drive, in fact) but I can't totally trust it 100% just yet.