wheezy packages problems
Hello, I have a wheezy installation (itself upgraded from previous versions) that I now want to upgrade to jessie. I was following the instructions for the preparation to the upgrade to jessie, and I got this: # dpkg --audit The following packages are missing the md5sums control file in the database, they need to be reinstalled: java-gcj-compat Java runtime environment using GIJ However, reinstalling this package seems impossible, as it apparently does not exist anymore: # apt-get install --reinstall java-gcj-compat Reading package lists... Done Building dependency tree Reading state information... Done Reinstallation of java-gcj-compat is not possible, it cannot be downloaded. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. There are other strange things. For example, gcj-jre is not installed on this system (?), but if I try to install it, I get: # apt-get install gcj-jre Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: gcj-jre : Depends: gcj-jre-headless (>= 4:4.7.2-1) but it is not going to be installed E: Unable to correct problems, you have held broken packages. Apart from this the systems seem up to date. I have tried apt-get clean, apt-get dist-upgrade and aptitude, and none of them complain. I have no idea what to do next, in order to have a trouble-free system that I can safely upgrade to jessie. Suggestions? Thanks Giovanni
Re: Re: wheezy packages problems
Cindy-Sue Causey wrote: Did you run "apt-get update"? Sure. Also... I used to get that message a lot about holding packages back.. People talk about "pinning" packages here. I've never done that but it might be one answer if you've ever actively done that yourself. I *a-sume* you'd have to unpin something to correct that, but I have no firsthand experience to base that on. I don't think I ever did that. For the record, here is my whole /etc/apt/sources.list: deb http://ftp.it.debian.org/debian wheezy main contrib non-free deb-src http://ftp.it.debian.org/debian wheezy main contrib non-free deb http://security.debian.org/ wheezy/updates main contrib non-free Also I have never used unstable or testing, just a long string of stable debians. gg
Re: wheezy packages problems
Sven Joachim wrote: Apparently java-gcj-compat depends on java-gcj-compat-headless, on which gcj-jre-headless conflicts. Now why apt-get refuses to uninstall java-gcj-compat-headless in favor of gcj-jre-headless is unclear, but apt-get *never* tells _why_ some package "is not going to be installed", so you have to figure that out yourself. It seems that doing it in two steps worked: first "apt-get install gcj-jre-headless" (which removed all java-gcj- things) and then "apt-get install gcj-jre". I still have no clear idea of what happened, but now "dpkg --audit" seems satisfied. Thanks everybody! gg
reasons to ditch LILO before upgrading to jessie?
Hello, I am preparing my system for the upgrade from wheezy to jessie. Since ancient ages, this system has been using LILO as the bootloader, because, long ago, it was the only bootloader that was recommended for my setup: this machine has two SATA disks in a software RAID 1 & LVM; that is, in /etc/lilo.conf I have: boot=/dev/md0 root=/dev/mapper/vg00-rootlv raid-extra-boot = mbr My doubt is that I have read that LILO, besides being very old, is now unmantained. However, I see that the jessie installation manual still mentions it, so it does not seem deprecated yet. So the question is: is there any serious reason to switch the system to GRUB before upgrading, or can I just keep my current setup and proceed to jessie? Thanks Giovanni
Re: reasons to ditch LILO before upgrading to jessie?
Brian wrote: Giovanni Gigante seems happy enough with LiLo and there appears to be no definite indication that it would fail to boot an upgraded machine. He could consider leaving it in place, reading the bug reports and having a plan to install GRUB should something go wrong afterwards. At the end, I decided to try the upgrade to jessie with LiLo (24.1) in place. I thought that the probability of hitting some bug caused by the interaction between LiLo and the upgraded distribution was less than the probabily of causing some damage by switching the bootloader (for example, by messing up the RAID configuration) since I've never configured Grub before. Also, the golden heuristic of "if it ain't broke, don't fix it", and the fact that this particular Debian upgrade is also switching from the init scripts to systemd, so I did not want to introduce even more changes in the boot process for the moment. Apparently, it worked. Perhaps, in the future, I'll also upgrade the bootloader, one rainy afternoon :-) gg
cups wants to remove the kernel
I have a Sarge machine: a standard install with default kernel. Now I want to install CUPS to use it as a print server. Following the "Debian and Windows Shared Printing mini-HOWTO", I tried to install CUPS (apt-get install cupsys). The installation begins, and among other things it says: The following packages will be REMOVED: initrd-tools kernel-image-2.4.27-1-386 and then: You are running a kernel (version 2.4.27-1-386) and attempting to remove the same version. This is a potentially disastrous action. Not only will /boot/vmlinuz-2.4.27-1-386 be removed, making it impossible to boot it, (you will have to take action to change your boot loader to boot a new kernel), it will also remove all modules under the directory /lib/modules/2.4.27-1-386. Just having a copy of the kernel image is not enough, you will have to replace the modules too. I repeat, this is very dangerous. If at all in doubt, answer no. If you know exactly what you are doing, and are prepared to hose your system, then answer Yes. Remove the running kernel image (not recommended) [No]? Of course I am now scared enought and I reply "no", thus getting: dpkg: error processing kernel-image-2.4.27-1-386 (--remove): subprocess pre-removal script returned error exit status 1 dpkg: initrd-tools: dependency problems, but removing anyway as you request: kernel-image-2.4.27-1-386 depends on initrd-tools (>= 0.1.48). Removing initrd-tools ... Errors were encountered while processing: kernel-image-2.4.27-1-386 E: Sub-process /usr/bin/dpkg returned an error code (1) And CUPS is not installed. Can anybody explain to me what's the meaning of this? If I reply "yes" instead, does my kernel get zapped? What is the correct way to install CUPS without destroying the system? Thanks, Giovanni. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
