pandorawiki.org заявки - Invitation to view

[via Google Docs]

I've shared an item with you:

pandorawiki.org заявки
https://docs.google.com/document/d/1BBb46DdtaOCeRSjh2BKI6Nm3OJQj6Cugo6oq_HZSFOI/edit?usp=sharing=CIKlwpoL=574e5c51

It's not an attachment -- it's stored online. To open this item, just click  
the link above.


pandorawiki.org
заявки

Re: LTS kernel in jessie-backports

[Nicholas D Steeves]

Hi Sebastian,

On 24 May 2016 at 23:35, Sebastian Kuzminsky  wrote:
> On 05/24/2016 08:23 PM, Ben Hutchings wrote:
>
> I maintain forks of debian kernels for the LinuxCNC project.  The workflow i
> use may be useful to you if you want to maintain your own fork, Nicholas.
> As Ben says, this would be a personal fork of yours that you would maintain,
> it would not become part of the debian backports repo.
>
>
> My work is in two parts, tracked in two git repos:
>
> The first is a build system that builds my custom debian-based linux image
> (plus a bunch of other packages that are important to me but that you
> probably don't care about): https://github.com/SebKuzminsky/linux-rtai-build
> (see the 3.4-wheezy branch).  This build system first makes a dsc, then
> builds the dsc in pbuilder into debs.
>
> The second is my fork of the debian linux kernel packaging repo.  The
> original debian repo is here:
> https://anonscm.debian.org/cgit/kernel/linux.git
>
> My fork is here: https://github.com/SebKuzminsky/linux-rtai-debian (see the
> 3.4.55-rtai branch)
>
>
> Feel free to ask me questions if any of that doesn't make sense.

Thank you for the links.  I'll look into and ask about anything that's
unclear to me.

Kind regards,
Nicholas

Re: LTS kernel in jessie-backports

[Nicholas D Steeves]

On 24 May 2016 at 22:23, Ben Hutchings  wrote:
> On Tue, 2016-05-24 at 21:51 -0400, Nicholas D Steeves wrote:
>> Dear Debian Kernel Team,
>>
>> My primary area of interest is btrfs on Debian.  The most reliable way
>> of limiting one's risk while using this experimental file system is to
>> run the most recent LTS kernel, and to minimize the use of exotic
>> features, or in some cases not use them at all (eg: RAID56 which
>> doesn't yet have proven scrub/self healing support).  In the interest
>> of providing the most stable btrfs experience to users of Debian
>> stable, would it be possible to fork the jessie-backport of src:linux
>> from 4.4.6-1, update it to 4.4.11-1, and then continue to maintain the
>> branch?
>>
>> I believe I am underqualified to maintain it myself, but if it would
>> be sufficient to learn the workflow of patch-level updates to the
>> src:linux-derived package, then I might be able to help with the
>> effort.
>
> That's not how Debian backports suites work, sorry.

Am I correct in understanding that it's also impossible to get
src:linux-4.4 and btrfs-progs-4.4 into jessie-updates?

Thanks,
Nicholas

Bug#814648: linux kernel backports broken

[Ben Hutchings]

On Tue, 2016-05-31 at 16:12 -0400, Antoine Beaupré wrote:
> Also, it seems impossible to rebuild the backport from source:
[...]
> with dpkg-buildpackage, it's a little better, but the dependency for
> kernel-wedge is off too.

The updated kernel-wedge is also in -backports.  Please assume at least
minimal competence on the part of your fellow developers before making
such claims.

Ben.

-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.


signature.asc
Description: This is a digitally signed message part

Bug#814648: linux kernel backports broken

[Ben Hutchings]

On Tue, 2016-05-31 at 16:15 -0400, Antoine Beaupré wrote:
> On 2016-05-31 16:01:46, Hector Oron wrote:
> > Hello,
> > 
> > El 31 may. 2016 9:56 p. m., "Antoine Beaupré"  escribió:
> > 
> > > Hi,
> > > 
> > > I still see this problem in debian jessie right now. I can't install the
> > > linux kernel backport.
> > > 
> > > cp: impossible d'évaluer « /boot/initrd.img-4.5.0-0.bpo.2-amd64 »: Aucun
> > fichier ou dossier de ce type
> > > 
> > > The initrd is simply not in the .deb:
> > 
> > Initramfs binary is usually generated by a hook that calls an initramfs
> > generator, from Debian, there is initramfs-tools or dracut.
> 
> I see. Well, that doesn't seem to be working correctly.
> 
> [1017]anarcat@angela:dist100$ sudo apt-get install
> [sudo] password for anarcat: 
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 1 not fully installed or removed.
> After this operation, 0 B of additional disk space will be used.
> Setting up linux-image-4.5.0-0.bpo.2-amd64 (4.5.4-1~bpo8+1) ...
> vmlinuz(/boot/vmlinuz-4.5.0-0.bpo.2-amd64
> ) points to /boot/vmlinuz-4.5.0-0.bpo.2-amd64
>  (/boot/vmlinuz-4.5.0-0.bpo.2-amd64) -- doing nothing at 
> /var/lib/dpkg/info/linux-image-4.5.0-0.bpo.2-amd64.postinst line 256.
> cp: cannot stat '/boot/initrd.img-4.5.0-0.bpo.2-amd64': No such file or 
> directory
> Failed to copy /boot/initrd.img-4.5.0-0.bpo.2-amd64 to /initrd.img .
[...]

Is your /boot directory on a VFAT filesystem or something else that
doesn't support symlinks?

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.


signature.asc
Description: This is a digitally signed message part

Bug#814648: marked as done (initrd missing from backport build (Failed to copy /boot/initrd.img-4.3.0-0.bpo.1-amd64 to /initrd.img))

[Debian Bug Tracking System]

Your message dated Tue, 31 May 2016 17:17:24 -0400
with message-id <87lh2qnd0b@angela.anarcat.ath.cx>
and subject line Re: linux kernel backports broken
has caused the Debian Bug report #814648,
regarding initrd missing from backport build (Failed to copy 
/boot/initrd.img-4.3.0-0.bpo.1-amd64 to /initrd.img)
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
814648: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814648
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-4.3.0-0.bpo.1-amd64
Version: 4.3.3-7~bpo8+1
Severity: normal

This version of the backport seems to fail to install properly:

$ sudo apt install -t jessie-backports linux-image-4.3.0-0.bpo.1-amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  linux-doc-4.3 debian-kernel-handbook
The following NEW packages will be installed:
  linux-image-4.3.0-0.bpo.1-amd64
0 upgraded, 1 newly installed, 0 to remove and 210 not upgraded.
Need to get 0 B/35.5 MB of archives.
After this operation, 173 MB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously unselected package linux-image-4.3.0-0.bpo.1-amd64.
(Reading database ... 447530 files and directories currently installed.)
Preparing to unpack 
.../linux-image-4.3.0-0.bpo.1-amd64_4.3.3-7~bpo8+1_amd64.deb ...
Unpacking linux-image-4.3.0-0.bpo.1-amd64 (4.3.3-7~bpo8+1) ...
Setting up linux-image-4.3.0-0.bpo.1-amd64 (4.3.3-7~bpo8+1) ...
cp: cannot stat '/boot/initrd.img-4.3.0-0.bpo.1-amd64': No such file or 
directory
Failed to copy /boot/initrd.img-4.3.0-0.bpo.1-amd64 to /initrd.img .
dpkg: error processing package linux-image-4.3.0-0.bpo.1-amd64 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 linux-image-4.3.0-0.bpo.1-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

and indeed, the initrd is not in /boot:

[1012]anarcat@angela:~100$ ls -al /boot/
total 73248K
drwxr-xr-x  5 root root 1024 Feb 13 12:26 .
drwxr-xr-x 26 root root 4096 Feb 13 12:26 ..
-rw-r--r--  1 root root  2676277 Jan 17 16:30 System.map-3.16.0-4-amd64
-rw-r--r--  1 root root  2889500 Dec 15 05:16 System.map-4.2.0-0.bpo.1-amd64
-rw-r--r--  1 root root  2949440 Jan 20 18:17 System.map-4.3.0-0.bpo.1-amd64
-rw-r--r--  1 root root   157726 Jan 17 16:30 config-3.16.0-4-amd64
-rw-r--r--  1 root root   169935 Dec 15 05:16 config-4.2.0-0.bpo.1-amd64
-rw-r--r--  1 root root   171928 Jan 20 18:17 config-4.3.0-0.bpo.1-amd64
drwxr-xr-x  5 root root 7168 Feb 13 12:24 grub
drwxr-xr-x  2 root root 1024 Sep 24 21:54 images
-rw-r--r--  1 root root 27164630 Jan 23 12:19 initrd.img-3.16.0-4-amd64
-rw-r--r--  1 root root 28134677 Jan 23 12:20 initrd.img-4.2.0-0.bpo.1-amd64
drwx--  2 root root12288 Mar 29  2010 lost+found
-rw-r--r--  1 root root25372 Sep 24 21:50 memdisk
-rw-r--r--  1 root root   182704 Sep 10  2014 memtest86+.bin
-rw-r--r--  1 root root   184840 Sep 10  2014 memtest86+_multiboot.bin
-rw-r--r--  1 root root98964 Mar 10  2015 memtest86.bin
-rw-r--r--  1 root root  3119888 Jan 17 16:27 vmlinuz-3.16.0-4-amd64
-rw-r--r--  1 root root  3480512 Dec 15 05:15 vmlinuz-4.2.0-0.bpo.1-amd64
-rw-r--r--  1 root root  3566064 Jan 20 18:14 vmlinuz-4.3.0-0.bpo.1-amd64

Heck, it's not even in the package itself:

$ dpkg -c 
/var/cache/apt/archives/linux-image-4.3.0-0.bpo.1-amd64_4.3.3-7~bpo8+1_amd64.deb
  | grep /boot/
drwxr-xr-x root/root 0 2016-01-20 18:17 ./boot/
-rw-r--r-- root/root   2949440 2016-01-20 18:17 
./boot/System.map-4.3.0-0.bpo.1-amd64
-rw-r--r-- root/root171928 2016-01-20 18:17 
./boot/config-4.3.0-0.bpo.1-amd64
-rw-r--r-- root/root   3566064 2016-01-20 18:14 
./boot/vmlinuz-4.3.0-0.bpo.1-amd64

Something really wrong happened when this backport was built...

a.

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (500, 'oldstable'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.3.0-0.bpo.1-amd64 depends on:
ii  debconf [debconf-2.0]   1.5.56
ii  initramfs-tools [linux-initramfs-tool]  0.120
ii  kmod18-3
ii  linux-base  3.5

Versions of packages 

Bug#814648: linux kernel backports broken

[Christian Seiler]

Hello,

On 05/31/2016 10:15 PM, Antoine Beaupré wrote:
> On 2016-05-31 16:01:46, Hector Oron wrote:
>> Hello,
>>
>> El 31 may. 2016 9:56 p. m., "Antoine Beaupré"  escribió:
>>
>>> Hi,
>>>
>>> I still see this problem in debian jessie right now. I can't install the
>>> linux kernel backport.
>>>
>>> cp: impossible d'évaluer « /boot/initrd.img-4.5.0-0.bpo.2-amd64 »: Aucun
>> fichier ou dossier de ce type
>>>
>>> The initrd is simply not in the .deb:
>>
>> Initramfs binary is usually generated by a hook that calls an initramfs
>> generator, from Debian, there is initramfs-tools or dracut.
> 
> I see. Well, that doesn't seem to be working correctly.
> 
> [1017]anarcat@angela:dist100$ sudo apt-get install
> [sudo] password for anarcat: 
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 1 not fully installed or removed.
> After this operation, 0 B of additional disk space will be used.
> Setting up linux-image-4.5.0-0.bpo.2-amd64 (4.5.4-1~bpo8+1) ...
> vmlinuz(/boot/vmlinuz-4.5.0-0.bpo.2-amd64
> ) points to /boot/vmlinuz-4.5.0-0.bpo.2-amd64
>  (/boot/vmlinuz-4.5.0-0.bpo.2-amd64) -- doing nothing at 
> /var/lib/dpkg/info/linux-image-4.5.0-0.bpo.2-amd64.postinst line 256.
> cp: cannot stat '/boot/initrd.img-4.5.0-0.bpo.2-amd64': No such file or 
> directory
> Failed to copy /boot/initrd.img-4.5.0-0.bpo.2-amd64 to /initrd.img .
> dpkg: error processing package linux-image-4.5.0-0.bpo.2-amd64 (--configure):
>  subprocess installed post-installation script returned error exit status 1
> Errors were encountered while processing:
>  linux-image-4.5.0-0.bpo.2-amd64
> needrestart is being skipped since dpkg has failed
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> iirc, there were problems with incompatible initramfs-tools in
> backports, and that was solved (in wheezy) by backporting
> initramfs-tools.
> 
> is that what is required here?

So I just tried this on my system (I actually just did an apt-get upgrade,
because I also run a backports kernel on my desktop, also amd64), and it
worked just fine here.

Are initramfs-tools installed? (dpkg -l initramfs-tools)
If so, could you do the following:

update-initramfs -k all -u

Does that work or give you an error?

How much space do you have left on your /boot partition?

As for your other problem:

> dpkg-deb: error: parsing file 
> '/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy/DEBIAN/control' 
> near line 8 package 'pbuilder-satisfydepends-dummy':
>  `Depends' field, syntax error after reference to package `cpio'

This is not an issue with the package build, but with pbuilder (and by
extension) cowbuilder only supprt the build profile syntax with
0.215+nmu4, whereas Jessie only has 0.215+nmu3. So if you either use
pbuilder from testing/sid, or manually install the required build
dependencies on your host system, you can indeed build the package on
a pure jessie + jessie-backports system. (Probably, takes a long time,
I haven't actually tried.)

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#824543: update-initramfs: cp: cannot stat '/etc/modprobe.d/*': No such file or directory

[Pedro Beja]

Hi,

just to say that I am having the same issue here.

...
Setting up ruby2.3 (2.3.1-2) ...
Processing triggers for initramfs-tools (0.125) ...
update-initramfs: Generating /boot/initrd.img-4.5.0-2-amd64
cp: cannot stat '/etc/modprobe.d/*': No such file or directory
Processing triggers for libc-bin (2.22-9) ...
...

having same version (0.125) of initramfs-tools.

thanks
regards
Pedro Beja

Bug#814648: linux kernel backports broken

[Antoine Beaupré]

Also, it seems impossible to rebuild the backport from source:

[1060]anarcat@angela:dist$ sudo DIST=jessie ARCH=amd64 cowbuilder --build  
linux_4.5.4-1~bpo8+1.dsc
 -> Copying COW directory
  forking: rm -rf /var/cache/pbuilder/build//cow.9542 
  forking: cp -al /var/cache/pbuilder/base-jessie-amd64.cow/ 
/var/cache/pbuilder/build//cow.9542 
I: removed stale ilistfile /var/cache/pbuilder/build//cow.9542/.ilist
  forking: chroot /var/cache/pbuilder/build//cow.9542 cowdancer-ilistcreate 
/.ilist find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a 
-links +1 -print0 \) | xargs -0 stat --format '%d %i ' 
 -> Invoking pbuilder
  forking: pbuilder build --buildplace /var/cache/pbuilder/build//cow.9542 
--buildresult /var/cache/pbuilder/jessie-amd64/result/ --debbuildopts  
--no-targz --internal-chrootexec chroot /var/cache/pbuilder/build//cow.9542 
cow-shell /home/anarcat/dist/linux_4.5.4-1~bpo8+1.dsc 
W: /root/.pbuilderrc does not exist
I: Running in no-targz mode
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Tue May 31 16:05:41 EDT 2016
I: pbuilder-time-stamp: 1464725141
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /var/cache/archive
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper, python3:any, quilt, cpio , xz-utils , 
kernel-wedge (>= 2.93~), kmod , bc , libssl-dev 
, openssl , asciidoc , 
xmlto , bison , 
flex , gcc-multilib , 
libaudit-dev , libdw-dev , libelf-dev , libiberty-dev 
, libnewt-dev , 
libnuma-dev , libperl-dev , libunwind8-dev , python-dev 
, autoconf , automake 
, libtool , 
libglib2.0-dev , libudev-dev , libwrap0-dev , libpci-dev 
, dh-python , dh-systemd , gcc-4.9, patchutils , xmlto 
dpkg-deb: error: parsing file 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy/DEBIAN/control' 
near line 8 package 'pbuilder-satisfydepends-dummy':
 `Depends' field, syntax error after reference to package `cpio'
E: pbuilder-satisfydepends failed.
I: Copying back the cached apt archive contents
I: unmounting /var/cache/archive filesystem
I: unmounting dev/pts filesystem
I: unmounting run/shm filesystem
I: unmounting proc filesystem
 -> Cleaning COW directory
  forking: rm -rf /var/cache/pbuilder/build//cow.9542 

with dpkg-buildpackage, it's a little better, but the dependency for
kernel-wedge is off too.

a.
-- 
Be yourself. Everyone else is already taken!
- Oscar Wilde

Bug#814648: linux kernel backports broken

[Hector Oron]

Hello,

El 31 may. 2016 9:56 p. m., "Antoine Beaupré"  escribió:

> Hi,
>
> I still see this problem in debian jessie right now. I can't install the
> linux kernel backport.
>
> cp: impossible d'évaluer « /boot/initrd.img-4.5.0-0.bpo.2-amd64 »: Aucun
fichier ou dossier de ce type
>
> The initrd is simply not in the .deb:

Initramfs binary is usually generated by a hook that calls an initramfs
generator, from Debian, there is initramfs-tools or dracut.

Regards

Bug#814648: linux kernel backports broken

[Antoine Beaupré]

Control: found -1 4.5.4-1~bpo8+1

Hi,

I still see this problem in debian jessie right now. I can't install the
linux kernel backport.

cp: impossible d'évaluer « /boot/initrd.img-4.5.0-0.bpo.2-amd64 »: Aucun 
fichier ou dossier de ce type

The initrd is simply not in the .deb:

[1043]anarcat@angela:~$ dpkg -c 
/var/cache/apt/archives/linux-image-4.5.0-0.bpo.2-amd64_4.5.4-1~bpo8+1_amd64.deb
 | grep initrd
[1044]anarcat@angela:~1$ 

In fact, it's not in any of the last uploads:

$ for image in /var/cache/apt/archives/linux-image-4.*bpo8+1_amd64.deb; do echo 
$image;  dpkg -c $image | grep initrd; done
/var/cache/apt/archives/linux-image-4.3.0-0.bpo.1-amd64_4.3.5-1~bpo8+1_amd64.deb
/var/cache/apt/archives/linux-image-4.4.0-0.bpo.1-amd64_4.4.6-1~bpo8+1_amd64.deb
/var/cache/apt/archives/linux-image-4.5.0-0.bpo.1-amd64_4.5.1-1~bpo8+1_amd64.deb
/var/cache/apt/archives/linux-image-4.5.0-0.bpo.2-amd64_4.5.4-1~bpo8+1_amd64.deb

I don't understand how anyone can use any of those backports without a
initrd.

Does *anyone* run linux backports on jessie right now?

A.
-- 
>From the age of uniformity, from the age of solitude, from the age of
Big Brother, from the age of doublethink - greetings!
- Winston Smith, 1984

Processed: linux kernel backports broken

[Debian Bug Tracking System]

Processing control commands:

> found -1 4.5.4-1~bpo8+1
Bug #814648 [src:linux] initrd missing from backport build (Failed to copy 
/boot/initrd.img-4.3.0-0.bpo.1-amd64 to /initrd.img)
Marked as found in versions linux/4.5.4-1~bpo8+1.

-- 
814648: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814648
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#819272: More details

[Eduard Bloch]

Hallo,
* Eduard Bloch [Fri, Mar 25 2016, 10:12:24PM]:

> I could try loading all regular modules one by one and look where it
> starts breakin - would it help?

Little update: loading known modules manually one by one did not break
it. Finally I used a custom-build kernel with system specific config and
that one works just fine.

Kernel log is not helpful, in case of failure none is stored.

Best regards,
Eduard.

Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color

[Milan Kupcevic]

On Tue, 31 May 2016 11:54:54 +0100 Ben Hutchings 
wrote:
> On Tue, 2016-05-31 at 07:23 +0200, Geert Stappers wrote:

[...]

> > I don't know what PowerPC hardware is available these days.
> [...]
> 
> Looking at who's participating in OpenPOWER, I think it's mostly
> servers now. (There are still low-end PowerPC chips going into
> embedded systems, but I don't believe Debian has ever supported them.
> We require Open Firmware.) It looks like a lot of those are custom-
> made for large HPC and cloud customers, but Tyan has some that are
> generally available, like this:
> http://www.tyan.com/campaign/openpower/
> 
> There are some PowerPC systems available for remote use by developers:
> http://developers.openpowerfoundation.org/explore
> 


This Tyan development reference platform offer looks interesting.

And still, the most appealing option for an individual Free software
developer to put their hands on a fully functional big-endian machine is
to get a PowerPC Mac, YDL PowerStation or Pegasos II from ebay and
install Debian on it.

IBM Power machines are mostly out of reach to individuals, price-wise
and formal-customer-agreement-requirement-wise.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color

[Mathieu Malaterre]

On Tue, May 31, 2016 at 6:22 PM, Ben Hutchings  wrote:
> On Tue, 2016-05-31 at 17:34 +0200, Mathieu Malaterre wrote:
>> On Mon, May 30, 2016 at 9:50 PM, Ben Hutchings  wrote:
>> > Control: reassign src:linux 4.5.4-1
>> > Control: tag -1 help
>> >
>> > On Mon, 2016-05-30 at 18:42 +0200, Mathieu Malaterre wrote:
>> > > Package: linux-image-4.5.0-2-powerpc
>> > > Version: 4.5.4-1
>> > >
>> > > During Debian installation the background color is inverted on PPC 
>> > > system.
>> > > At least on my Mac Mini G4, the default background color shows up as red
>> > > from begining to start (only the last screen turn blue).
>> > >
>> > > Looking at the module loaded during the installation I can see radeonfb,
>> > > which I suspect is the one responsible for handling of `/dev/fb0`.
>> > >
>> > > After installation I tried reproducing this color inversion without any
>> > > luck so far.
>> > >
>> > > It is non-trivial to `rmmod radeon`, so instead I used (and rebooted):
>> > >
>> > > $ cat /etc/modprobe.d/radeon.conf
>> > > blacklist radeon
>> > >
>> > > However upon reboot `/dev/fb0` is already setup.
>> >
>> > Of course, because there is no character-based display mode on Power
>> > Macs (in general).
>> >
>> > > But neither radeonfb nor
>> > > radeon module seems to be loaded (using lsmod) but lspci output is rather
>> > > confusing [*].
>> >
>> > lspci lists all kernel modules that match a particular PCI device's ID,
>> > and separately whether any kernel driver is currently bound to the
>> > device.
>> >
>> > > I can also see:
>> > >
>> > > $ cat /proc/fb
>> > > 0 OFfb ATY,RockHo
>> >
>> > As I would expect, the generic Open Firmware framebuffer driver is
>> > behind /dev/fb0.  If a hardware-specific driver is loaded, that will
>> > take over from it.
>>
>> Thank you ! Ok now I understand. d-i tried to modprobe `radeonfb` but
>> fails since framebuffer is already taken by Open Firmare, as can be
>> seen in the dmesg log:
> [...]
>
> That's *not* what I thought was happening.  I was expecting radeonfb to
> do something like this (in the radeon DRM driver):
> https://sources.debian.net/src/linux/4.5.4-1/drivers/gpu/drm/radeon/radeon_drv.c/?hl=336#L336
> and maybe to query offb about the existing framebuffer properties first.
>
> So the problem is simpler: offb gets the palette or pixel format wrong
> and loading radeonfb afterwards doesn't help because it doesn't take
> over from offb.

Ok.

Too bad offb is built into the kernel (not as module):

$ grep FB_OF /boot/config-4.5.0-2-powerpc
CONFIG_FB_OF=y

I'll see if I can reuse any of the existing hack [*] for my Mac Mini G4.

[*]
$ grep -i hack drivers/video/fbdev/offb.c
/* Supported palette hacks */
/* Definitions used by the Avivo palette hack */
static void offb_init_palette_hacks(struct fb_info *info, struct
device_node *dp,
offb_init_palette_hacks(info, dp, name, address);
/* Hack for when BootX is passing us */
* a display (just not the palette hacks).

Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color

[Ben Hutchings]

On Tue, 2016-05-31 at 17:34 +0200, Mathieu Malaterre wrote:
> On Mon, May 30, 2016 at 9:50 PM, Ben Hutchings  wrote:
> > Control: reassign src:linux 4.5.4-1
> > Control: tag -1 help
> > 
> > On Mon, 2016-05-30 at 18:42 +0200, Mathieu Malaterre wrote:
> > > Package: linux-image-4.5.0-2-powerpc
> > > Version: 4.5.4-1
> > > 
> > > During Debian installation the background color is inverted on PPC system.
> > > At least on my Mac Mini G4, the default background color shows up as red
> > > from begining to start (only the last screen turn blue).
> > > 
> > > Looking at the module loaded during the installation I can see radeonfb,
> > > which I suspect is the one responsible for handling of `/dev/fb0`.
> > > 
> > > After installation I tried reproducing this color inversion without any
> > > luck so far.
> > > 
> > > It is non-trivial to `rmmod radeon`, so instead I used (and rebooted):
> > > 
> > > $ cat /etc/modprobe.d/radeon.conf
> > > blacklist radeon
> > > 
> > > However upon reboot `/dev/fb0` is already setup.
> > 
> > Of course, because there is no character-based display mode on Power
> > Macs (in general).
> > 
> > > But neither radeonfb nor
> > > radeon module seems to be loaded (using lsmod) but lspci output is rather
> > > confusing [*].
> > 
> > lspci lists all kernel modules that match a particular PCI device's ID,
> > and separately whether any kernel driver is currently bound to the
> > device.
> > 
> > > I can also see:
> > > 
> > > $ cat /proc/fb
> > > 0 OFfb ATY,RockHo
> > 
> > As I would expect, the generic Open Firmware framebuffer driver is
> > behind /dev/fb0.  If a hardware-specific driver is loaded, that will
> > take over from it.
> 
> Thank you ! Ok now I understand. d-i tried to modprobe `radeonfb` but
> fails since framebuffer is already taken by Open Firmare, as can be
> seen in the dmesg log:
[...]

That's *not* what I thought was happening.  I was expecting radeonfb to
do something like this (in the radeon DRM driver):
https://sources.debian.net/src/linux/4.5.4-1/drivers/gpu/drm/radeon/radeon_drv.c/?hl=336#L336
and maybe to query offb about the existing framebuffer properties first.

So the problem is simpler: offb gets the palette or pixel format wrong
and loading radeonfb afterwards doesn't help because it doesn't take
over from offb.

On the installed system, the radeon driver is auto-loaded (although it
will still fail initialisation if the firmware is missing, except for
old ATI chips).  It can take over from offb and (presumably) gets the
colours right.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.

signature.asc
Description: This is a digitally signed message part

Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 825840 src:linux 4.5.4-1
Bug #825840 [debian-installer] [ppc] display inverted red and blue backgroud 
color
Bug reassigned from package 'debian-installer' to 'src:linux'.
No longer marked as found in versions debian-installer/20150422+deb8u3.
Ignoring request to alter fixed versions of bug #825840 to the same values 
previously set
Bug #825840 [src:linux] [ppc] display inverted red and blue backgroud color
Marked as found in versions linux/4.5.4-1.
> retitle 825840 0 OFfb ATY,RockHo: image display inverts red and blue color
Bug #825840 [src:linux] [ppc] display inverted red and blue backgroud color
Changed Bug title to '0 OFfb ATY,RockHo: image display inverts red and blue 
color' from '[ppc] display inverted red and blue backgroud color'.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
825840: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825840
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#825929: initramfs-tools-core - incorrect busybox relations

[Debian Bug Tracking System]

Processing control commands:

> tag -1 moreinfo
Bug #825929 [initramfs-tools-core] initramfs-tools-core - incorrect busybox 
relations
Added tag(s) moreinfo.

-- 
825929: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825929
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#825929: initramfs-tools-core - incorrect busybox relations

[Ben Hutchings]

Control: tag -1 moreinfo

On Tue, 2016-05-31 at 15:52 +0200, Bastian Blank wrote:
> Package: initramfs-tools-core
> Version: 0.125
> Severity: serious
> 
> Moin
> 
> update-initramfs fails if busybox is of a wrong version, however I see
> no breaks or conflicts to make sure the correct version is available.
>
> > Setting up linux-image-4.5.0-2-amd64 (4.5.4-1) ...
> > /etc/kernel/postinst.d/initramfs-tools:
> > update-initramfs: Generating /boot/initrd.img-4.5.0-2-amd64
> > E: busybox or busybox-static, version 1:1.22.0-17~ or later, is required 
> > but not installed
[...]

This only happens when there is a config file that sets BUSYBOX=y.  You
can find that config file with:

    grep -r BUSYBOX=y /etc/initramfs-tools/initramfs-tools.conf \
/usr/share/initramfs-tools/conf-hooks.d

If it's the one in /etc, that's user error, otherwise it's a bug in whichever 
package owns the file.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.


signature.asc
Description: This is a digitally signed message part

Bug#666021: more data

[Tomas Pospisek]

We were seeing the same problem, as reported here, often. Our logs would 
show something like this:


[301933.088794] swapper/3: page allocation failure: order:0, mode:0x20
[301933.088817] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 3.16.0-4-amd64 #1 
Debian 3.16.7-ckt25-2
[301933.088852] Hardware name: System manufacturer System Product Name/P8H67-M 
PRO, BIOS 1106 10/17/2011
[301933.06]   8150e835 0020 
88043fac3c80
[301933.088921]  81142d3f   
00310002
[301933.088955]  88043fdede68 88043fdeec00 88043fad5ee8 
88043fad5ed8
[301933.088990] Call Trace:
[301933.089004][] ? dump_stack+0x5d/0x78
[301933.089029]  [] ? warn_alloc_failed+0xdf/0x130
[301933.089051]  [] ? __alloc_pages_nodemask+0x8ca/0xb30
[301933.089074]  [] ? alloc_pages_current+0x9d/0x150
[301933.089095]  [] ? __netdev_alloc_frag+0x8b/0x140
[301933.089117]  [] ? __netdev_alloc_skb+0x6f/0xf0
[301933.089145]  [] ? rtl8169_poll+0x2b2/0x690 [r8169]
[301933.089169]  [] ? net_rx_action+0x140/0x240
[301933.089192]  [] ? __do_softirq+0xf1/0x290
[301933.089212]  [] ? irq_exit+0x95/0xa0
[301933.089232]  [] ? do_IRQ+0x52/0xe0
[301933.089252]  [] ? common_interrupt+0x6d/0x6d
[301933.089272][] ? 
__hrtimer_start_range_ns+0x1cd/0x390
[301933.089307]  [] ? cpuidle_enter_state+0x4f/0xc0
[301933.089329]  [] ? cpuidle_enter_state+0x48/0xc0
[301933.089351]  [] ? cpu_startup_entry+0x2f8/0x400
[301933.089372]  [] ? start_secondary+0x20f/0x2d0

The stack trace would *allways* cross at least partly network functions 
and in particular netdev_alloc, except ...


... except for one other group of failures that would be coming from the 
rbd/ceph driver and would look like this:


May 27 03:46:32 vil kernel: kworker/4:1: page allocation failure: order:1, 
mode:0x204020
May 27 03:46:32 vil kernel: CPU: 4 PID: 426028 Comm: kworker/4:1 Not tainted 
3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2
May 27 03:46:32 vil kernel: Hardware name: System manufacturer System Product 
Name/P8H67-M PRO, BIOS 1106 10/17/2011
May 27 03:46:32 vil kernel: Workqueue: rbd2 rbd_request_workfn [rbd]
May 27 03:46:32 vil kernel:   8150e835 00204020 
880233303a80
May 27 03:46:32 vil kernel:  81142d3f   
0002
May 27 03:46:32 vil kernel:  00013fdede00 88043fdeec00 0046 
0001
May 27 03:46:32 vil kernel: Call Trace:
May 27 03:46:32 vil kernel:  [] ? dump_stack+0x5d/0x78
May 27 03:46:32 vil kernel:  [] ? warn_alloc_failed+0xdf/0x130
May 27 03:46:32 vil kernel:  [] ? 
__alloc_pages_nodemask+0x8ca/0xb30
May 27 03:46:32 vil kernel:  [] ? kmem_getpages+0x5b/0x110
May 27 03:46:32 vil kernel:  [] ? fallback_alloc+0x1cf/0x210
May 27 03:46:32 vil kernel:  [] ? kmem_cache_alloc+0x1f0/0x450
May 27 03:46:32 vil kernel:  [] ? 
ceph_osdc_alloc_request+0x53/0x2f0 [libceph]
May 27 03:46:32 vil kernel:  [] ? 
rbd_osd_req_create.isra.25+0x6f/0x170 [rbd]
May 27 03:46:32 vil kernel:  [] ? 
rbd_img_request_fill+0x2b6/0x910 [rbd]
May 27 03:46:32 vil kernel:  [] ? 
rbd_request_workfn+0x24b/0x390 [rbd]
May 27 03:46:32 vil kernel:  [] ? process_one_work+0x172/0x420
May 27 03:46:32 vil kernel:  [] ? worker_thread+0x113/0x4f0
May 27 03:46:32 vil kernel:  [] ? __schedule+0x2b1/0x700
May 27 03:46:32 vil kernel:  [] ? rescuer_thread+0x2d0/0x2d0
May 27 03:46:32 vil kernel:  [] ? kthread+0xbd/0xe0
May 27 03:46:32 vil kernel:  [] ? 
kthread_create_on_node+0x180/0x180
May 27 03:46:32 vil kernel:  [] ? ret_from_fork+0x58/0x90
May 27 03:46:32 vil kernel:  [] ? 
kthread_create_on_node+0x180/0x180

We have now set:

  # cat /etc/sysctl.conf
  ...
  vm.min_free_kbytes = 65536
  ...
  # sysctl -p /etc/sysctl.conf

Since Ben Hutchings' explanation in [1] in this bug report makes very much 
sense, and matches quite closely with what we are seeing I am assuming 
that the setting above will fix our problem. If not I'll report back here.


Note that from what I can see our system is *NOT* under memory pressure.

I think that this problem is fundamentaly a *kernel bug*:

I don't think that an admin should be required to have intricate knowledge 
about memory allocation procedures in the network stack in order to be 
able to operate a server.


On the contrary it's the network stack that should be able to communicate 
to the virtual memory subsystem that it needs memory pages badly, and the 
virtual memory subsystem should tale that criticality into account and 
swap out pages or call the OOM subsystem to kill stuff.


Also there doesn't seem to be sufficient info coming along with the error 
message "swapper/3: page allocation failure: order:0, mode:0x20" to 
enable a sysadmin to figure out why there was an allocation failure.


Note that the original reason why I ended up in this bug report here was, 
that some *VM*'s filesystem would be mounted read-only for no apparent 
reason.


The course of events that would lead up to 

Bug#825929: initramfs-tools-core - incorrect busybox relations

[Bastian Blank]

Package: initramfs-tools-core
Version: 0.125
Severity: serious

Moin

update-initramfs fails if busybox is of a wrong version, however I see
no breaks or conflicts to make sure the correct version is available.

| Setting up linux-image-4.5.0-2-amd64 (4.5.4-1) ...
| /etc/kernel/postinst.d/initramfs-tools:
| update-initramfs: Generating /boot/initrd.img-4.5.0-2-amd64
| E: busybox or busybox-static, version 1:1.22.0-17~ or later, is required but 
not installed
| update-initramfs: failed for /boot/initrd.img-4.5.0-2-amd64 with 1.
| run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
| Failed to process /etc/kernel/postinst.d at 
/var/lib/dpkg/info/linux-image-4.5.0-2-amd64.postinst line 525.
| dpkg: error processing package linux-image-4.5.0-2-amd64 (--configure):
|  subprocess installed post-installation script returned error exit status 1
| dpkg: dependency problems prevent configuration of linux-image-amd64:
|  linux-image-amd64 depends on linux-image-4.5.0-2-amd64; however:
|   Package linux-image-4.5.0-2-amd64 is not configured yet.
| 
| dpkg: error processing package linux-image-amd64 (--configure):
|  dependency problems - leaving unconfigured

Regards,
Bastian

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages initramfs-tools depends on:
ii  initramfs-tools-core  0.125
ii  linux-base4.0

initramfs-tools recommends no packages.

Versions of packages initramfs-tools suggests:
pn  bash-completion  

-- no debconf information

Processed: bug present in current jessie kernel

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 666021 3.16.7-ckt25-2
Bug #666021 [src:linux] linux-image-3.2.0-2-powerpc64: Kernel reports page 
allocation failure: order:1, mode:0x20
Marked as found in versions linux/3.16.7-ckt25-2.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
666021: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666021
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#666021: bug present in current jessie kernel

[Tomas Pospisek]

found 666021 3.16.7-ckt25-2

Processed: reassign 822804 to rpcbind, forcibly merging 806336 822804

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 822804 rpcbind
Bug #822804 [nfs-common] nfs-common: rpcbind.service not started on boot before 
nfs-common
Bug reassigned from package 'nfs-common' to 'rpcbind'.
No longer marked as found in versions nfs-utils/1:1.2.8-9.
Ignoring request to alter fixed versions of bug #822804 to the same values 
previously set
> forcemerge 806336 822804
Bug #806336 [rpcbind] rpcbind: socket activation miss DefauiltDependencies=no - 
systemd detected sysinit cycle
Bug #822804 [rpcbind] nfs-common: rpcbind.service not started on boot before 
nfs-common
Severity set to 'important' from 'normal'
Added indication that 822804 affects console-setup,kbd,nfs-common
Marked as found in versions rpcbind/0.2.3-0.2.
Merged 806336 822804
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
806336: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806336
822804: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822804
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems