Bug#375088: acknowledged by developer (Fixed)
Debian Bug Tracking System wrote: It has been marked as closed by one of the developers, namely Filipus Klutiero [EMAIL PROTECTED]. Are you sure? $ sudo apt-get install linux-image-2.6-686 Reading package lists... Done Building dependency tree... 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. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: linux-image-2.6-686: Depends: linux-image-2.6.16-2-686 (= 2.6.16-14) but 2.6.16-15 is to be installed E: Broken packages -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374145: adding lp to /etc/modules worked for me...
Perhaps this could be set up as an install option that is asked. -- Ken Foskey FOSS developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
G5 fan control and official debian kernels.
Hi all, I have been experimenting with 2.6.16 and 2.6.17 and builtin or modular THERM_PM72 on my XServer G5. The result is as follows : 2.6.16 + modular fan control - airplan noise level. 2.6.17 + modular fan control - still noisy, but orders of magnitude lower. 2.6.17 + builtin fan control - noisy, but acceptable noise level. So, i believe that the choice for the debian kernel is to have builtin both the I2C_POWERMAC and the THERM_PM72 modules. Of the other therm control modules, we have : CONFIG_WINDFARM CONFIG_WINDFARM_PM81 CONFIG_WINDFARM_PM91 CONFIG_WINDFARM_PM112 I suppose they also will all benefit from being builtin, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337939: marked as done (linux-image-2.6.14-1-powerpc64: [powerpc64] linux-image-2.6.14-1 fails to install)
Your message dated Sun, 25 Jun 2006 12:42:39 +0200 with message-id [EMAIL PROTECTED] and subject line linux-image-2.6.1[567]-[12]-powerpc64 images install fine on Apple XServer G5 and IBM JS21 blades, closing has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: linux-image-2.6.14-1-powerpc64 Version: 2.6.14-2 Severity: important Trying to install linux-image-2.6.14-1-powerpc64 from unstable yields the following error: You already have a NoLOADER configuration in /etc/.conf Install a boot block using the existing /etc/.conf? [Yes] There was an error with running , a log file is available in file /var/log/_log.7153. Please edit /etc/.conf manually and re-run , or make other arrangements to boot your machine. Please hit return to continue The file mentioned above has just one line saying: sh: line 1: /sbin/: is a directory I tried not installing the boot block and generating it again, but I get the same error. The package can be installed by saying no to using existing /etc/.conf and to wipe out your old NoLOADER ... -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: powerpc (ppc64) Kernel: Linux 2.6.12-1-powerpc64 Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1) Versions of packages linux-image-2.6.14-1-powerpc64 depends on: ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo ii yaird 0.0.11-3 Yet Another mkInitRD -- no debconf information ---End Message--- ---BeginMessage--- Hi, We believe that more recent debian kernels work fine on powerpc 64bit hardware, i just recently made installs of it on IBM JS21 blades and an Apple XServe G5, without any of the problems you reported. I am thus closing this bug, if you see it still with recent kernels, please reopen it with more information. Friendly, Sven Luther ---End Message---
Processed: found 375342 in 0.53c
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.20 found 375342 0.53c Bug#375342: generated initramfs image includes dm-snapshot module but does not load it when necessary Bug marked as found in version 0.53c. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375342: Additional regression in version 0.60
With initramfs-tools 0.53c the error message is fairly straightforward: Begin: Running /scripts/local-top ... device-mapper: 4.4.0-ioctl (2005-01-12) initialised: [EMAIL PROTECTED] cdrom: open failed. /dev/cdrom: open failed: No medium found Can't expand LV: Snapshot support missing from kernel? 0 logical volume(s) in volume group main now active Done. ALERT! /dev/mapper/main-root does not exist. Dropping to a shell! # modprobe dm-snapshot vgchange -ay exit An admin with access to the console can hopefully work out the commands to run without too much difficulty. With version 0.60, however, the errors are much more verbose and less helpful: Begin: Running /scripts/local-top ... device-mapper: 4.4.0-ioctl (2005-01-12) initialised: [EMAIL PROTECTED] cdrom: open failed. device-mapper: unknown target type device-mapper: error adding target to table device-mapper: reload ioctl failed: Invalid argument 1 logical volumes(s) in volume group main now active Done. stdin: error 0 Begin: Running /scripts/local-premount ... Done. Usage: modprobe [-v] [-V] [-C config-file] [-n] [-i] [-q] [-b] [-o modname] modname [parameters...] modprobe -r [-n] [-i] [-v] modulename ... modprobe -l -t dirname [ -a modulename ...] mount: Cannot read /etc/fstab: No such file or directory Begin: Running /scripts/log-bottom ... Done. Done. Begin: Running /scripts/init-bottom ... mount: Mounting /root/dev on /dev/.static failed: No such file or directory Done. mount: Mounting /sys on /root/sys failed: No such file or directory mount: Mounting /proc on /root/proc failed: No such file or directory Target filesystem doesn't have /sbin/init The system is now in some weird state where devices such as /dev/mapper/main-root and /dev/mapper/main-root-real exist, however reading from them immediately results in an EOF. # modprobe dm-snapshot vgchange -ay exit Target filesystem doesn't have /sbin/init # mount /dev/main/root /root exit The boot then continues normally. So the regressions are that the messages displayed to the console are longer and less useful, and that there is no attempt to mount the root filesystem once the shell is exited. -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375432: One package is missing
Package: linux-headers-2.6.17-1-k7 Version: 2.6.17-1 Hello, I can't install the newest linux-headers, because the package linux-kbuild is missing: Die folgenden Pakete haben nichterfüllte Abhängigkeiten: linux-headers-2.6.17-1-k7: Hängt ab: linux-kbuild-2.6.17 ist aber nicht installierbar
Bug#375418: marked as done (linux-image-2.6-k7: unmet dependency causes package to be removed)
Your message dated Mon, 26 Jun 2006 00:56:13 +0200
with message-id [EMAIL PROTECTED]
and subject line Bug#375418: linux-image-2.6-k7: unmet dependency causes
package to be removed
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
---BeginMessage---
Package: linux-image-2.6-k7
Severity: normal
During a dist-upgrade, the linux-{image,headers}-2.6-k7 virtual packages are
removed because of an unmet dependency:
# apt-get -s install linux-image-2.6-k7
Reading package lists... Done
Building dependency tree... 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.
Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
linux-image-2.6-k7: Depends: linux-image-2.6.16-2-k7 (= 2.6.16-14) but
2.6.16-15 is to be installed
Please let me know if you require additional information.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
---End Message---
---BeginMessage---
Version: 2.6.17-1
On Sun, Jun 25, 2006 at 04:44:20PM -0500, Moshe Yudkowsky wrote:
During a dist-upgrade, the linux-{image,headers}-2.6-k7 virtual packages are
removed because of an unmet dependency:
Already fixed. Also is dist-upgrade for upgrading dists, not unstable.
Bastian
--
Dammit Jim, I'm an actor, not a doctor.
---End Message---
Re: SMP PReP (was Re: The powerpc port should be removed from etch release candidates ...)
On Thu, May 25, 2006 at 01:41:30PM -0500, Troy Benjegerdes wrote: On Thu, May 25, 2006 at 09:50:57AM +0200, Sven Luther wrote: On Wed, May 24, 2006 at 11:14:33PM -0500, Troy Benjegerdes wrote: SMP never worked under Linux on those machines because the AIX boot sequence to enable it was never successfully reverse-engineered. Ah, ok, then it makes no sense to build a special kernel for those, until more information is found about the above. I have a Motorola MTX PreP system with dual 604e's that I can test this on. But you never managed to get SMP working on it, right ? SMP works but I was having problems where it would crash after 3 or 4 months of uptime in the software raid1 code. This was with 2.4 kernels though.. I have not tried a recent 2.6 kernel yet. FYI, linux-image-2.6.15-1-powerpc-smp version 2.6.15-8 works on my MTX board. kalmia:~# cat /proc/cpuinfo processor : 0 cpu : 604ev clock : 300MHz revision: 1.0 (pvr 000a 0100) bogomips: 297.98 processor : 1 cpu : 604ev clock : 300MHz revision: 1.0 (pvr 000a 0100) bogomips: 297.98 total bogomips : 595.96 machine : PReP Dual MTX w/ Parallel Port l2 cache: none simms : -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dropping the amd64-generic flavour
On Sat, Jun 24, 2006 at 08:06:39PM +0200, Christoph Hellwig wrote: On Sat, Jun 24, 2006 at 08:20:56AM +0200, Florian Weimer wrote: * Frederik Schueler: -generic is odd and too long. I am considering to change the naming scheme completely, and call the flavours 2.6.x-y-amd64 and 2.6.x-y-em64t respectively. Newer GCCs produce AMD64 code which is supposed to be closed to optimal to what GCC can produce on EM64T. Does it still make sense to distinguish between them? Or has it got something to do with the way the kernel sets up its data structures? The officially recommended way to build a distro kernel is to build the generic one. It's as fast as the specific ones because it uses some binary patching during bootup. The only thing you save with the specific options is a tiny little bit of space. I'm going to second this suggestion. The time I spend waiting for both a -k8 and -emt64 version to download and install when I'm upgrading a few machines is going to be far longer than any time saved by some optimizations that aren't already done by the generic kernel. Just make a 'amd64-generic' kernel and be done with it, unless you have benchmarks showing a real performance difference. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
