Thanks for making smxi -- I used it to upgrade lenny to squeeze.
Overall it was a pleasanter experience that before but there are still some hiccups.

I got some messages that dependency based init is not properly set up.

Which package do I need to look at in greater detail for this?
Whatever I could figure out is that there is upstart in ubuntu and insserv in debian but what is their mutual relation I cannot get

Thanks
Back to top

thanks for the feedback, over the next months ideally we can get any hiccups automated or at least information provided. Insserv is the new init system for Debian, and you have to get your system working with it. However, the insserv package contains an unusually robust and well thought out set of feedback informations on failure, that really do a good job letting you know how to fix it.

Unfortunately, with the switch to insserv, what happens is not scriptable, because the packages that catch and fail to upgrade and block the insserv full switchover tend to be a variety of random packages introduced into user systems, especially non debian core repo packages.

So what will be needed is an alert to stable users that this upgrade will involve, unfortunately, some manual tweaks.

Basically, the error messages from the insserv update are quite clear and tell you what file is blocking the upgrade. Once you have the file, just run: dpkg -S /full/blocking/file/path
to get the file package owner name, then aptitude/apt-get purge <package>. Some will be orphaned files from packages removed but not purged, then you have to just delete those files manually.

Debian Insserv Wiki

then you need to run the command:

which will show you a list of the blocking files. Make sure you have fully upgraded the system to squeeze first, to let all packages that can, upgrade their init stuff to insserv. Any remaining files/packages that block this must be cleaned up manually.

I suggest removing one package/file at a time until you get a clear:


If you have any concrete suggestions about how smxi could have presented this information more clearly to end users, feel free to make a suggestion, most of my updates to insserv required manual intervention, which is why I didn't add any automated type support in smxi.

Also, if you noticed any other hiccups on the lenny -> squeeze update re smxi, let me know while they are still fresh in your mind.
Back to top

Thanks for the heads up.
I know what the problem is -- my canon printer has a driver which was an rpm that was alienized. Those rc scripts dont have the dependency comments as required. But as of now I have a working printer so I dont want to fiddle with that right now.


Ok here are some thoughts:

1. My total download 1.2 G or so took a couple of days (many hours per day with breaks). Finally when the downloads were over it was 3 AM and I groggily pressed some answers to questions not sure what!! [The dependency based stuff was part of that]
   
   It would be nice if smxi understood the need for 'download but dont install' (and maybe optionally shutdown the machine)
   
2. First when I started using smxi it gave me a choice of apt-get or aptitude. Later on (even after removing /etc/smxi.conf) it did not. So I put aptitude by hand
   
3. There was a large list of packages that were orphaned that I wanted to clean out. [This is one of the nice features of smxi] I was asked to select them. How to select in the console? Theres no mouse in the console that I could use. I guess one could use gpm or some such but half way through a dist upgrade seems hardly an auspicious time for that :-) So it would be nice if this went into a file.
   
4. More generally smxi allows us to scroll up to see what flew past but it does not go all the way to the beginning.
   

PS
I ran dpkg-recongifure insserv it came out without error.
But now starting the printer driver with
/ect/init.d/ccpd start gives me

Back to top

The choice to use aptitude/apt-get should always be offered if no selection was made. You can change this choice in misc tweaks, advanced tweaks. If you removed smxi.conf and then restarted smxi and it did not ask you that question but you did have aptitude and apt-get installed, then that's a bug, but I suspect you may have missed something.

Generally, for large downloads, simply do this, if you have a slow connection:

aptitude / apt-get update
then: aptitude full-upgrade -d

see what it's going to do, usually it doesn't change that much, but you never know on major upgrades such as lenny -> squeeze.

The orphaned list is in: /var/log/smxi.log
search for: 'orphans:' (no ' just the orphans:)

Scrolling up is a function of bash history, not smxi. The average is only 6 screens up, I don't know if that can be increased, and don't know how you would do that if if it can, but it's not related to smxi itself, that's just how bash is.

sounds like your canon rpm failed, I suggest you try reinstalling it, it looks like insserv is up and running now.
Back to top

techAdmin

Suggestion:

Maybe give an option for more logs to remain in /var/log?

The default would be current log and one old one.

----
The option to opt in....would be for smxi to search for old logs and gunzip and rename them....just like logrotate for syslog/messages

That way if Rustom were to do smxi over a number of reboots, he/she can see each log when they are more awake?

regards
Back to top

the smxi.log is massive, set to rotate at 100kB. smxi rotates its own logs, I don't remember how many, I think 2 back ones, numbered smxi.1.log and smxi.2.log I think.

ls /var/log/smxi*
/var/log/smxi.log /var/log/smxi.log.1 /var/log/smxi.log.2

believe me, that's a LOT of logs, 300kB worth.
Back to top