make -f debian/rules build - does not correctly rebuild files- why?

[Andrew Worsley]

I found that rebuilding the kernel package does NOT rebuild  the .o
files which I found very surprising.
In fact after much painful experimenting I was forced do a clean to
get my modified .c files to be compiled!

Basically I was trying to build a new kernel in order to debug
   bug844788 "hibernate: suspends ok but hangs on restore after
decompressing with stretch kernel on macbook pro"

when I found the kernel was *unchanged* from the original version no
matter how I rebuilt the kernel. My confusion wasn't helped by the
fact the the timestamp in the kernel is based on the debian/changelog
:-(

After much painful building packages/installing and getting *NO*
change just got more desperate and in the end I just removed a .o

  rm linux-4.8.5/debian/build/build_amd64_none_amd64/kernel/power/swap.o

Then I found nothing would rebuild that .o - even though it spend much
time generating packages and so forth!
I was using dpkg-buildpackage with -nc (no clean)

Then tried plain make more and more make targets to see if any of them
would regenerate the file:

fakeroot make -n -f debian/rules.gen binary-arch_amd64_none_amd64
make  -f debian/rules.gen build-arch_amd64_none_amd64
make  -f debian/rules.gen build-arch_amd64
make  -f debian/rules build-arch
make  -f debian/rules build

Then finally I did this and then it was rebuilt - correctly with my
changes (which I verified with strings command on the binary):
 make  -f debian/rules clean

Now this works
 make  -f debian/rules.gen build-arch_amd64_none_amd64

Surely no one can work under these painful conditions - being forced
to rebuild all the code from scratch for the kernel to test a change?

Could some one point me to a way or documentation to easily - rebuild
(rather the clean and rebuild) the kernel for another test?

It takes a long time to build the kernel packages from scratch...

Thanks in advance

Andrew

Bug#845422: [PATCH] Please add BCM2835 MMC driver for Raspberry Pi 3

[Aurelien Jarno]

On 2016-11-23 09:43, Michael Stapelberg wrote:
> Source: linux
> Severity: wishlist
> Tags: patch
> 
> Thank you for your work on maintaining the Linux kernel in Debian, I really
> appreciate it!
> 
> I am interested in running Debian on the Raspberry Pi 3.
> 
> As per https://github.com/anholt/linux/wiki/Raspberry-Pi-3, the mainline Linux
> kernel in version 4.8 includes support for the Raspberry Pi 3, so we are in
> pretty good shape already.
> 
> However, when trying to boot linux-image-4.8.0-1-arm64 version 4.8.5-1, I
> noticed that the kernel can’t find any block devices (and hence no root file
> system). This is because the bcm2835-sdhost MMC driver has not actually made 
> it
> into Linux 4.8; it is still under review:
> https://www.spinics.net/lists/arm-kernel/msg513433.html

While this is correct, please note that the BCM2835 has two sdhost
controller, one that can be used for the wireless card and one for the
sdcard. The 4.8 kernel already has support for the other sdhost
controller, namely the iProc one. You can use this one for your root
filesystem as it is built in the Debian kernel.

I guess you have a problem somewhere, maybe in the device tree that
causes the wrong SD controller to be used. I use the device tree that is
provided by the kernel:

|sdhci: sdhci@7e30 {
|compatible = "brcm,bcm2835-sdhci";
|reg = <0x7e30 0x100>;
|interrupts = <2 30>;
|clocks = < BCM2835_CLOCK_EMMC>;
|status = "disabled";
|};

This work since at least kernel 4.8.4-1~exp1.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#845611: linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL)

[Ryan Tandy]

On Fri, Nov 25, 2016 at 05:02:06PM +, Ian Campbell wrote:

Oh, so the issue is not that you are missing a second disk, but rather
that the one disk you do have seems to not be detected? You theory is
that it is actually only the second port which is connected to anything
in this hw?


Yes, exactly.

Bug#845611: linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL)

[Ian Campbell]

On Fri, 2016-11-25 at 08:56 -0800, Ryan Tandy wrote:
> On Fri, Nov 25, 2016 at 04:24:31PM +, Ian Campbell wrote:
> > 
> > Is it possible that there are multiple variants of this one with
> > differing numbers of disks?
> > 
> > It's a little tricky to google for but all the LS-GL's I can see
> > _look_
> > like they are single disk (see [*] below). Or maybe the naming is
> > just
> > confusing?
> 
> 
> [...snip...]

Thanks for all that.

> Mine has zero mods though, totally stock hardware-wise.

Oh, so the issue is not that you are missing a second disk, but rather
that the one disk you do have seems to not be detected? You theory is
that it is actually only the second port which is connected to anything
in this hw?

Sorry, took me a while to grok what you were saying in your original
mail!

Ian.

Bug#845611: linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL)

[Ryan Tandy]

On Fri, Nov 25, 2016 at 04:24:31PM +, Ian Campbell wrote:

Is it possible that there are multiple variants of this one with
differing numbers of disks?

It's a little tricky to google for but all the LS-GL's I can see _look_
like they are single disk (see [*] below). Or maybe the naming is just
confusing?


I don't believe there is anything called LS-GL that supports more than 
one disk. Now that you mention it though, there are two hardware 
revisions out there:


http://buffalo.nas-central.org/wiki/LinkstationProLiveDifferences

I have the older (v1) hardware.

I will crack the box open this weekend and confirm, but as far as I 
remember there was only one SATA connector.


Aha, there was a guide for wiring up the second port, though:

http://buffalo.nas-central.org/wiki/Add_a_Second_Hard_Drive_to_Your_LS_Pro_v1/LS_Live_v1

Mine has zero mods though, totally stock hardware-wise.

Bug#845611: linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL)

[Ian Campbell]

On Fri, 2016-11-25 at 08:10 -0800, Ryan Tandy wrote:
> On Fri, Nov 25, 2016 at 07:42:37AM +, Ian Campbell wrote:
> > 
> > Assuming orion5x-linkstation.dtsi is correctly relating to your
> > platform you would appear to want one of:
> >    $ git grep orion5x-linkstation.dtsi arch/arm/boot/dts/*.dts
> >    arch/arm/boot/dts/orion5x-kuroboxpro.dts:#include "orion5x-
> > linkstation.dtsi"
> >    arch/arm/boot/dts/orion5x-linkstation-lsgl.dts:#include
> > "orion5x-linkstation.dtsi"
> >    arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts:#include
> > "orion5x-linkstation.dtsi"
> > 
> > (Or something else not yet present in the kernel tree.)
> 
> Mine is an LS-GL, so orion5x-linkstation-lsgl.dts should be the one. 

Is it possible that there are multiple variants of this one with
differing numbers of disks?

It's a little tricky to google for but all the LS-GL's I can see _look_
like they are single disk (see [*] below). Or maybe the naming is just
confusing?

Ian.

[0] http://www.gkspk.com/view/techie/upgrade-hdd-buffalo-linkstation-ls
-gl-nas/
[1] http://buffalo.nas-central.org/wiki/Category:LSPro reached from th
"LS-GL v1" or "v2" link at  http://buffalo.nas-central.org/wiki/Main_Pa
ge
[2] http://buffalo.nas-central.org/wiki/Information/LSPROOverview which
is the result of searching for "LS-GL" on that site
[3] http://buffalo.nas-central.org/wiki/Disassemble_the_LS_Pro_v1/LS_Li
ve_v1

Bug#845611: linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL)

[Ryan Tandy]

On Fri, Nov 25, 2016 at 07:42:37AM +, Ian Campbell wrote:

Assuming orion5x-linkstation.dtsi is correctly relating to your
platform you would appear to want one of:
   $ git grep orion5x-linkstation.dtsi arch/arm/boot/dts/*.dts
   arch/arm/boot/dts/orion5x-kuroboxpro.dts:#include "orion5x-linkstation.dtsi"
   arch/arm/boot/dts/orion5x-linkstation-lsgl.dts:#include 
"orion5x-linkstation.dtsi"
   arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts:#include 
"orion5x-linkstation.dtsi"

(Or something else not yet present in the kernel tree.)


Mine is an LS-GL, so orion5x-linkstation-lsgl.dts should be the one. 
(The model string in there is the same one I see at runtime, too.)



Of the three above orion5x-kuroboxpro.dts and orion5x-linkstation-
lswtgl both set ports to 2 using:

{
   nr-ports = <2>;
   };

which overrides the defaults from the dtsi. You mentioned kurobox_pro-
setup.c so perhaps orion5x-kuroboxpro.dts is the one you want?


Exactly - orion5x-linkstation-lsgl.dts is missing this chunk. So my 
suspicion is it needs the same override (or, if they all end up using 
the same value, maybe the dtsi can change - Roger would know better than 
I would). Sorry for the lack of clarity.


kurobox_pro-setup.c, AFAIK, used to be used on several related 
platforms. The kurobox pro and LS-GL are nearly identical.


thanks
Ryan

Bug#787326: Toshiba NB500 is also affected.

[Roberto Ríos Gallardo]

If I plug in a USB WiFi stick with a different brand of chip (Atheros) it
(the Atheros) works.

[ 1288.500070] usb 3-5: new high-speed USB device number 8 using ehci-pci
[ 1288.648969] usb 3-5: New USB device found, idVendor=0cf3, idProduct=9271
[ 1288.648984] usb 3-5: New USB device strings: Mfr=16, Product=32,
SerialNumber=48
[ 1288.648995] usb 3-5: Product: USB2.0 WLAN
[ 1288.649003] usb 3-5: Manufacturer: ATHEROS
[ 1288.649011] usb 3-5: SerialNumber: 12345
[ 1288.649994] usb 3-5: ath9k_htc: Firmware htc_9271.fw requested
[ 1288.650254] usb 3-5: firmware: direct-loading firmware htc_9271.fw
[ 1288.930988] usb 3-5: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
[ 1289.168861] ath9k_htc 3-5:1.0: ath9k_htc: HTC initialized with 33 credits
[ 1289.437866] ath9k_htc 3-5:1.0: ath9k_htc: FW Version: 1.3
[ 1289.437879] ath: EEPROM regdomain: 0x809c
[ 1289.437886] ath: EEPROM indicates we should expect a country code
[ 1289.437892] ath: doing EEPROM country->regdmn map search
[ 1289.437898] ath: country maps to regdmn code: 0x52
[ 1289.437910] ath: Country alpha2 being used: CN
[ 1289.437913] ath: Regpair used: 0x52
[ 1289.467835] ieee80211 phy0: Atheros AR9271 Rev:1
[ 1289.467927] cfg80211: Calling CRDA for country: CN
[ 1289.477069] cfg80211: Regulatory domain changed to country: CN
[ 1289.477079] cfg80211:  DFS Master region: FCC
[ 1289.477083] cfg80211:   (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp), (dfs_cac_time)
[ 1289.477090] cfg80211:   (2402000 KHz - 2482000 KHz @ 4 KHz), (N/A,
2000 mBm), (N/A)
[ 1289.477096] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16
KHz AUTO), (N/A, 2300 mBm), (N/A)
[ 1289.477102] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16
KHz AUTO), (N/A, 2300 mBm), (0 s)
[ 1289.477107] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A,
3000 mBm), (N/A)
[ 1289.477112] cfg80211:   (5724 KHz - 5940 KHz @ 216 KHz),
(N/A, 2800 mBm), (N/A)
[ 1289.477118] cfg80211:   (5940 KHz - 6372 KHz @ 216 KHz),
(N/A, 4400 mBm), (N/A)
[ 1289.477123] cfg80211:   (6372 KHz - 6588 KHz @ 216 KHz),
(N/A, 2800 mBm), (N/A)
[ 1289.816610] systemd-udevd[1542]: renamed network interface wlan0 to wlan1
[ 1290.143509] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready


2016-11-24 18:21 GMT+01:00 Roberto Ríos Gallardo :

> It also happens on Toshiba NB500 on a fresh install performed today with
> the stable netinstall iso.
> Previously it was working, on the same version of debian, last upgraded
> about a month ago.
>
> I am using the latest version on stable, obviously, it was just installed
> from the repos after apt-get update.
>
> root@libroverde:/home/usuario# lsusb
> Bus 005 Device 002: ID 04f2:b1d6 Chicony Electronics Co., Ltd CNF9055
> Toshiba Webcam
> Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> root@libroverde:/home/usuario#
>
> root@libroverde:/home/usuario# rfkill list
> root@libroverde:/home/usuario#
>
>
> Output of dmesg:
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.
> org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.36-1+deb8u2
> (2016-10-19)
> [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64
> root=/dev/mapper/libroverde--vg-root ro quiet
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009dbff]
> usable
> [0.00] BIOS-e820: [mem 0x0009dc00-0x0009]
> reserved
> [0.00] BIOS-e820: [mem 0x000dc000-0x000d]
> reserved
> [0.00] BIOS-e820: [mem 0x000e4000-0x000f]
> reserved
> [0.00] BIOS-e820: [mem 0x0010-0x7f5c]
> usable
> [0.00] BIOS-e820: [mem 0x7f5d-0x7f5d]
> ACPI data
> [0.00] BIOS-e820: [mem 0x7f5e-0x7f5e2fff]
> ACPI NVS
> [0.00] BIOS-e820: [mem 0x7f5e3000-0x7fff]
> reserved
> [0.00] BIOS-e820: [mem 0xe000-0xefff]
> reserved
> [0.00] BIOS-e820: [mem 0xfec0-0xfec0]
> reserved
> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff]
> reserved
> [0.00] BIOS-e820: [mem 0xff00-0x]
> reserved
> [0.00] NX (Execute Disable) protection: active
> [0.00] SMBIOS 2.5 present.
> [0.00] DMI: TOSHIBA TOSHIBA NB500/PBU00, BIOS V1.9A 07/28/2011
> [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
> [ 

[PATCH] builddeb: add make fastdeb-pkg target

[riku . voipio]

From: Riku Voipio 

Currently, the deb-pkg and bindeb-pkg targets create multiple packages
for the kernel binaries, headers, userspace headers and firmware.

For developers who generate Debian packages as part of their development
workflows, it's often not necessary to generate all these packages.

Introduce new target, fastdeb-pkg, which only generates kernel packages.
Re-order package build order so that kernel binary package is created
first and we can exit cleanly unless generating rest packages with the
old bindeb-pkg and deb-pkg targets.

Cc: Jim Davis 
Cc: Andrew Donnellan 
Signed-off-by: Riku Voipio 
---
 scripts/package/Makefile |  7 ++-
 scripts/package/builddeb | 49 +---
 2 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/scripts/package/Makefile b/scripts/package/Makefile
index 71b4a8a..c858366 100644
--- a/scripts/package/Makefile
+++ b/scripts/package/Makefile
@@ -97,6 +97,10 @@ bindeb-pkg: FORCE
$(MAKE) KBUILD_SRC=
+$(call cmd,builddeb)
 
+fastdeb-pkg: FORCE
+   $(MAKE) KBUILD_SRC=
+   +$(call cmd,builddeb)
+
 clean-dirs += $(objtree)/debian/
 
 
@@ -142,7 +146,8 @@ help: FORCE
@echo '  rpm-pkg - Build both source and binary RPM kernel 
packages'
@echo '  binrpm-pkg  - Build only the binary kernel RPM package'
@echo '  deb-pkg - Build both source and binary deb kernel 
packages'
-   @echo '  bindeb-pkg  - Build only the binary kernel deb package'
+   @echo '  bindeb-pkg  - Build all binary kernel deb packages'
+   @echo '  fastdeb-pkg - Build only the binary kernel deb package'
@echo '  tar-pkg - Build the kernel as an uncompressed 
tarball'
@echo '  targz-pkg   - Build the kernel as a gzip compressed 
tarball'
@echo '  tarbz2-pkg  - Build the kernel as a bzip2 compressed 
tarball'
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 8ea9fd2..5035f57 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -185,11 +185,6 @@ if grep -q '^CONFIG_MODULES=y' $KCONFIG_CONFIG ; then
fi
 fi
 
-if [ "$ARCH" != "um" ]; then
-   $MAKE headers_check KBUILD_SRC=
-   $MAKE headers_install KBUILD_SRC= 
INSTALL_HDR_PATH="$libc_headers_dir/usr"
-fi
-
 # Install the maintainer scripts
 # Note: hook scripts under /etc/kernel are also executed by official Debian
 # kernel packages, as well as kernel packages built using make-kpkg.
@@ -323,6 +318,32 @@ EOF
 
 fi
 
+# Do we have firmware? Move it out of the way and build it into a package.
+if [ -e "$tmpdir/lib/firmware" ]; then
+   mv "$tmpdir/lib/firmware"/* "$fwdir/lib/firmware/$version/"
+   rmdir "$tmpdir/lib/firmware"
+fi
+
+create_package "$packagename" "$tmpdir"
+[ "x$1" = "xfastdeb-pkg" ] && exit 0
+
+if [ -e "$fwdir/lib/firmware/$version" ]; then
+   cat <> debian/control
+
+Package: $fwpackagename
+Architecture: all
+Description: Linux kernel firmware, version $version
+ This package contains firmware from the Linux kernel, version $version.
+EOF
+
+   create_package "$fwpackagename" "$fwdir"
+fi
+
+if [ "$ARCH" != "um" ]; then
+   $MAKE headers_check KBUILD_SRC=
+   $MAKE headers_install KBUILD_SRC= 
INSTALL_HDR_PATH="$libc_headers_dir/usr"
+fi
+
 # Build kernel header package
 (cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name \*.pl) > 
"$objtree/debian/hdrsrcfiles"
 (cd $srctree; find arch/*/include include scripts -type f) >> 
"$objtree/debian/hdrsrcfiles"
@@ -354,22 +375,6 @@ Description: Linux kernel headers for $KERNELRELEASE on 
\${kernel:debarch}
  This is useful for people who need to build external modules
 EOF
 
-# Do we have firmware? Move it out of the way and build it into a package.
-if [ -e "$tmpdir/lib/firmware" ]; then
-   mv "$tmpdir/lib/firmware"/* "$fwdir/lib/firmware/$version/"
-   rmdir "$tmpdir/lib/firmware"
-
-   cat <> debian/control
-
-Package: $fwpackagename
-Architecture: all
-Description: Linux kernel firmware, version $version
- This package contains firmware from the Linux kernel, version $version.
-EOF
-
-   create_package "$fwpackagename" "$fwdir"
-fi
-
 cat <> debian/control
 
 Package: $libc_headers_packagename
@@ -386,8 +391,6 @@ if [ "$ARCH" != "um" ]; then
create_package "$libc_headers_packagename" "$libc_headers_dir"
 fi
 
-create_package "$packagename" "$tmpdir"
-
 if [ -n "$BUILD_DEBUG" ] ; then
# Build debug package
# Different tools want the image in different locations
-- 
2.10.2

Bug#845302: systemd: 232-6:Failed to boot, makes kernel panic when starting /sbin/init.

[Michael Biebl]

Am 25.11.2016 um 08:48 schrieb K.Ohta:
> Dear Michael,
> 
> On Fri, 25 Nov 2016 07:49:55 +0100
> Michael Biebl  wrote:
> 
>> How did you apply the patch? If you do it via "patch < $patch", you'll
>> need to chmod +x hooks/mounts. The lintian warning should have been a
>> clue.
> 
> Thanks. I missed this, re-check now.
> Then, I re-built these packages, and re-build initramfs and reboot.
> But, with "auto" parameter of /usr entry at fstab, not booted due to not 
> mounting /usr.

The patch works fine here and without an error message it's hard to say
why it is failing for you.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#845302: systemd: 232-6:Failed to boot, makes kernel panic when starting /sbin/init.

[K.Ohta]

Dear Michael,

On Fri, 25 Nov 2016 07:49:55 +0100
Michael Biebl  wrote:

> How did you apply the patch? If you do it via "patch < $patch", you'll
> need to chmod +x hooks/mounts. The lintian warning should have been a
> clue.

Thanks. I missed this, re-check now.
Then, I re-built these packages, and re-build initramfs and reboot.
But, with "auto" parameter of /usr entry at fstab, not booted due to not 
mounting /usr.
Then I checked initramfs.conf at /etc/initramfs-tools/ ,and edit "BUSYBOX=" 
entry
both "yes" , "no" and "auto". Any parameters don't make mounting /usr and 
not booting with fstab's entry.

I checked contents of /boot/initrd.img-${KernelVersion==4.8.0-1-amd64}, mount 
and libmount seems to
replace mount package (neither klibc or busybox).
And, when building package , still lintian said:
>E: initramfs-tools-core: depends-on-essential-package-without-using-version 
>depends: mount

Regards,
Ohta.

On Fri, 25 Nov 2016 07:49:55 +0100
Michael Biebl  wrote:

> Am 25.11.2016 um 05:18 schrieb K.Ohta:
> > Dear Michel,
> > Sorry for very later.
> > I test your patch of initramfs-tools, but, don't mount /usr with
> > auto at entry of fstab.
> > 
> > I tested below:
> > 1.debuild initramfs after applying that patch and install
> > packages.  
> 
> >> W: initramfs-tools-core: script-not-executable  
> usr/share/initramfs-tools/hooks/mount
> 
> How did you apply the patch? If you do it via "patch < $patch", you'll
> need to chmod +x hooks/mounts. The lintian warning should have been a
> clue.
> 
> If you use "git am $patch", then this will be done automatically:
> 
> diff --git a/hooks/mount b/hooks/mount
> new file mode 100755
> index 000..1464533
> --- /dev/null
> +++ b/hooks/mount
> 
> The patch was supposed to be applied using git am.
> 
> >> E: initramfs-tools-core:
> >> depends-on-essential-package-without-using-version depends: mount  
> 
> That's a fair point. I'm not sure if we need a specific version, so
> this explicit dependency can likely be dropped.
> 
> 



pgpH6nyYBL326.pgp
Description: OpenPGP digital signature