Blocked packages during upgrade Lenny to Squeeze

[hugin0]

i upgraded to the one that was in testing at the time, i think it was 2.6.30. so yes, it was a non-lenny kernel, it was the squeeze one. I know i followed roughly the same pattern he did, but i thought it was worth mentioning the path i took, as i didn't make use of smxi.

[h2]

I came across this thread by accident, and find this problem fairly interesting, as well as a fairly serious issue for the forthcoming lenny -> squeeze upgrade, which clearly, if I understand the posts above, will require a kernel upgrade + reboot prior to the full-upgrade process.

I can add support and udev version testing to smxi to let users know, and I will, ie: if udev version = 0.125 or thereabouts, and if new udev version in apt > 145 then show kernel install pre full-upgrade/dist-upgrade and alert user to fact they must install kernel and reboot prior to dist-upgrade.

smxi already has a fairly heavily tested kde 3 to kde 4 upgrade component that activates automatically when kdm 4 is detected in apt, unless you choose to skip it, so in most ways it's ready for squeeze. I need to add in a few small tweaks to get rid of some bugs in the kde4 upgrade, but overall it's reasonably solid.

Good to see people testing the squeeze upgrade process from lenny now, best to catch major gotchas early, and the udev/kernel version problem is certainly a major gotcha.

[refracta]

I used aptitude and if I recall correctly I was informed about the kernel/udev issue when I tried to upgrade. I have done a couple upgrades this past week and did not really consider it difficult although it was more involved than usual.

[h2]

craigevil let me know about the trick with adding /etc/udev/kernel-update pre upgrade, that's probably how I'll handle it, that seems easy enough to do.

[michapma]

I came across this thread by accident, and find this problem fairly interesting, as well as a fairly serious issue for the forthcoming lenny -> squeeze upgrade, which clearly, if I understand the posts above, will require a kernel upgrade + reboot prior to the full-upgrade process.

Hi h2, glad you did find this thread. I would expect the problem to be resolved by the time squeeze goes stable, but the earlier it's detected, the better. I need to take the time to search the Debian bug tracker to see if it exists and add my two cents, or file a bug if not. (Never done that before though.) After reading messages from the udev install script a dozen times I'm still not sure from exactly which version of udev the conflict occurs. Good if you implement a workaround if the problem persists, but I would rather hope to see it resolved by the package maintainer(s). I'll try to keep an eye on the bug list and inform you on the smxi forum when it gets resolved.

The kde3 to kde4 upgrade part of smxi worked great and was intuitive for me to use, kudos. It would've been a very positive experience if I hadn't got stuck in that loop thanks to the udev bug. In fact, I found myself wishing and looking for a gnome update component when I was trying with the laptop (first post), because gnome got removed when I was ripping packages out experimenting with the dependencies.

[h2]

The udev issue is pretty easy to handle with simple logic: if running kernel less than 2.6.28 say, and if udev less than 130, and if new udev greater than 145, then: touch the /etc file, show message telling person to install a new kernel, full/dist-upgrade, and reboot. I'll modify the pre upgrade kernel install section to allow kernel install in that case even though it's an old kernel.

Re kde4, glad that's working, that was the result of a lot of group collaboration and debugging, huge amount of user feedback and data was involved, still a few little things to iron out for closer to perfect, just added on to it today that I'd forgotten.

Re gnome, I don't run it, and I don't have any real access to a user base that does that wants to provide debugging and data feedback, it takes a lot of people to make these things work, exceptions, weird configurations, after a while it smooths out.

I thought gnome upgrades tended to be fairly easy because they haven't changed the core system apis like kde3->4 did? But I don't follow gnome so I can't say.

It's fairly easy to create a clone of the kde4 tool, but it requires a lot of information about gnome packages, what is gone, what remains, what is changed, what gets a new name. Hard to do though for me since I don't use gnome anywhere.

[h2]

The lenny -> squeeze udev/kernel 26 fix has been added to smxi now, if there are any issues please post them in the script forums, and they'll get fixed, thanks. If this fix becomes unnecessary, ie, no user action at all is required, even without a new kernel, let me know and I'll disable it. Full information is given with old udev/kernel + new udev in apt to let users know what choices they have to handle the matter, including mostly automated via script.

[refracta]

Is smxi in the debian repos?

[h2]

No. See my sig links for manual/install info. Since I just do these scripts as a (time consuming) hobby I'm not very interested in anything that would add to my time load, and I think the scripts work better as outsider tools anyway. At least that's my feeling. Since its free software, anyone is free to do whatever they like with the scripts, but sometimes this stuff changes very fast, very frequently, so any maintainer would have to be really on the ball to track it, it must always have the latest version to do its tasks properly.

Now inxi, that should be a debian package, anyone want to sponsor it? It's crying to be in Debian, increasingly popular tool, already in Mint, AntiX, and just added to default Arch release, I'd love to see Debian have it before Ubuntu does. Inxi, having dependencies, and also several recommends, would work great in apt as a deb.

[stevepusser]

I made an attempt to backport the Squeeze xorg packages into Lenny recently, and while it bogged down due to the sheer number of interlinked dependencies (may as well just upgrade to Squeeze), it appeared that the sticking point for udev and older kernels is linked to the Squeeze libdrm2 package, which is depending on the drm (direct rendering manager) built into kernels >= 2.6.29. Since xorg, udev and hal are also linked to libdrm2, the whole upgrade process gets broken. Once you have a newer kernel, the upgrade process should work.

[zenlord]

AT YOUR OWN RISK, you can force the installation of this version of udev
WHICH DOES NOT WORK WITH YOUR RUNNING KERNEL AND WILL BREAK YOUR SYSTEM
AT THE NEXT REBOOT by creating the /etc/udev/kernel-upgrade file.

sounds like it would be valid for others too.

Stumbling across this thread, maybe how I got around this can help some people trying to upgrade to squeeze:

# touch /etc/udev/kernel-upgrade
# aptitude install udev (will bring more updates with it)
# aptitude safe-upgrade (I had to repeat this several times until there were no more updates, probably because the dist-upgrade was interrupted)

Make sure you have the latest kernel and udev before rebooting, or your system will be unbootable, as the warning states...

This way I was able to complete the upgrade to squeeze relatively easy.

Zl.

[bestchai]

I found a different, and what I think is a simpler, way of getting around the udev-kernel dependency.

The following blog post contains the details:
http://devplant.net/2010/03/26/linux-up ... v-package/

[Nick Plus]

AT YOUR OWN RISK, you can force the installation of this version of udev
WHICH DOES NOT WORK WITH YOUR RUNNING KERNEL AND WILL BREAK YOUR SYSTEM
AT THE NEXT REBOOT by creating the /etc/udev/kernel-upgrade file.

sounds like it would be valid for others too.

Yeeeeeeeeeeeaaaaaaaaaaahhhhhhh! This worked!
Then I simply installed new linux-image-... and uninstalled the old one.