Alex wrote: > * Since I am working from a partimage backup of the Debian system > partition (S.O.E. that can be transferred from one machine to > another in case of emergency), it is not a problem to restore that > and start again, if you think that would be the best course and > then check the extra packages, circular dependencies and lint > etc.. I presume that all that would be done BEFORE adding the > DVD's to /etc/apt/sources.list. Hmm... Very interesting! I don't know but yes that /might/ be easiest. Because then you would have a completely working Lenny system and can resolve the issues there before the upgrade. But at the same time if I were doing it I would probably just work the current problem and push through it. If the problem is caused by obsolete packages left behind then I think it can be solved through judicious application of force using 'dpkg --force-depends' and 'apt-get -f install'. But restoring to the checkpoint before is a good idea! You will have to be the judge of things since you are handling the equipment. I would hit it for a bit first before giving up and going back to the checkpoint. > * The full distro. set, is as a result of "old habits die hard" ;-) :- > o From my old days in the industry working on DEC PDP's > (RSX/RT11/RSTS) & VAX's (VMS) and even the bad old days when > Novell Netware came on 5.15" 'floppy disks' - you just did > NOT start doing ANYTHING to the OS until you had the full > distro in your hand, in front of the machine Ah... Lots of memories there. But in those days one machine was all that was available. Screw it up and you were really in a world of hurt. But these days you probably have more than one computer available to you. So these days if you have a serious problem you can use the other one to help with the recovery. > o From days when we did not have any internet connectivity at > home These days I work out of my home and have better connectivity than the folks at big box corporations. :-) > o Proprietary Ethernet controllers that do not allow network > connectivity when SOE's from one machine are partimage > restored to new hardware NICs not working due to missing kernel firmware blobs? You could take an inventory of all possible network cards on your site and add into your standard image all of the needed combinations of firmware blobs. That won't help when you encounter a new card for the first time. But it will work among the set that have become known. apt-cache search firmware | grep ^firmware > Lastly, while having spent many fruitful and prosperous years in the > industry, times and circumstances change, and I am now just a 'user > of infotech' rather than a directly interested party. For this > reason, I have not kept up with this LSB and 'dependency based boot > system' stuff. The LSB headers for /etc/init.d scripts have been around for a while but not required in Debian previously. In the Squeeze 6.0 release they are now required for the dependency based booting. Starting with Squeeze Debian users are going to be hitting this more and more. However the fallback for the upgrade is that the system continues to use the hard coded start order numbers. Some people who like the previous hard coded ordering system feel that is the way it should continue. So for them it is a win even if for others it is a loss. The problems with the hard coded numbers is that when there are circular dependencies it allows maintainers to point fingers at other people. They want other packages to change instead of their package. Three maintainers with three packages all pointing fingers at the person to their side and no one owning up to taking responsibility to actually fixing the problem. That isn't helpful. I like the dependency based boot ordering because you define dependency relationships and circular dependencies are flagged as problems. You can't dodge the issue anymore. The boot sequence is getting cleaned up. However there is still more work to be done and there are still problems to be fixed in the current set of packages in Debian. The usual problem is bootstrapping the networking system. The problem usually involves a combination of networking and syslog and DNS. Everything wants networking. Everything wants logging. Everything wants DNS. But there is a bootstrapping problem among the core system services. DNS can't start until the networking is online. People often want to log remotely over the network. People often want to use hostnames instead of IP addresses. You can how easily someone can create a dependency loop there. With the hard coded number boot ordering trying to sort those out in the distribution packages was impossible. But the local admin could adjust the ordering and usually make it work. But it wasn't pretty. Now with the stated dependencies you can always file a proper bug against any package that isn't stating the dependencies correctly. And editing those locally I find easier. And the 'insserv' program that deals with it complains loudly when there is a problem which I think is good too so that they problem isn't hidden. > I have only recently started to get my head around all the > /dev/etc.etc. naming conventions. I am not sure if this is part of > this 'dependency based boot system', but when I get told that I have > to have something that looks like a hexadecimal version of > 'nameinternationaladdresspostcodeandinternationalphonenumber' as my > NEW device naming convention, I must admit that the old "acronym > phobia" that forced me from the industry in the end, starts to rear > its ugly head again and the questions start to arise "why do we want > to make life MORE complicated and LESS?". At that point just say > NO! Please just give me the /dev/etc.etc. naming convention that I > have just managed to get my head around. LSB is the Linux Standards Base and is a standard by the Linux Foundation to standardize the behavior between different GNU/Linux distributions. You remember that POSIX was the Portable Operating System Interface for Unix and an attempt to standardize the behavior between different Unix flavors? LSB is same thing for GNU/Linux distributions but with a different field of view. No need to recreate POSIX but there is a need to standardize on other parts of the system. LSB headers provide a way to declare boot time information. An example from the /etc/init.d/skeleton file: ### BEGIN INIT INFO # Provides: skeleton # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Example initscript # Description: This file should be used to construct scripts to be # placed in /etc/init.d. ### END INIT INFO The older /etc/init.d/ scripts did not have that declaration. If it is missing then insserv cannot work and the upgrade cannot convert to a dependency based boot system. > Any chance of a link to a "concise primer" / "idiots guide" to LSB > and 'dependency based boot system'? I don't know about good or concise but the Debian wiki page describes it and has further references. Since it is a wiki the community can edit and improve the documentation. At the least I would start here on these wiki pages: http://wiki.debian.org/LSBInitScripts http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot The above is probably a harsh introduction but I don't have a better suggestion. Ask questions. Bob
Attachment:
signature.asc
Description: Digital signature