Moving Linux kernel to 4.9

[dom]

D'oh, me again, now I'm having the same problem on my Pi3. The problem is I did a apt-get update/dist-upgrade and it downgraded the kernel. Then rpi-update still thinks it's updated to 4.9 (which I guess it's not) so rpi-update isn't allowing it reinstall:

/boot/.firmware_revision stores the hash of the last rpi-update which allows it to skip an update if it believes it is up to date.
So:

Code: Select all

sudo rm /boot/.firmware_revision

before runnnig rpi-update will ensure it is not skipped.

[DougieLawson]

It would help if the apt-get raspberrypi-kernel package always deleted /boot/.firmware_revision that way the loonies running with a non-standard kernel wouldn't keep getting the wrong results from rpi-update when apt-get had sneaked a regressed kernel on to their system.

I've got four out of eleven raspberries running 4.9.0+ or 4.9.0-v7+ and a little script that uses ssh round each one to remove that /boot/.firmware_revision file to avoid the apt-get struggle.

[holywen]

Cann't enable BBR as the tcp_congestion_control algorithm.

Code: Select all

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf

Code: Select all

sudo sysctl -p
sysctl: setting key "net.core.default_qdisc": No such file or directory
net.core.default_qdisc = fq
sysctl: setting key "net.ipv4.tcp_congestion_control": No such file or directory

[dom]

Cann't enable BBR as the tcp_congestion_control algorithm.

Does this work on the current 4.4 kernel?

[Penthux]

It would help if the apt-get raspberrypi-kernel package always deleted /boot/.firmware_revision that way the loonies running with a non-standard kernel wouldn't keep getting the wrong results from rpi-update when apt-get had sneaked a regressed kernel on to their system.

Loonies? Some of us don't rely on 'apt-get -y install' type tools to upgrade our kernel/modules. Some of us actually build our own custom kernels because we know what we're doing and don't have to depend on tools such as rpi-update to do it for us. There's nothing wrong with using rpi-update, if that's the limit of your knowledge/experience with upgrading the kernel and firmware. There's every thing wrong with labelling people as 'loonies' who do it the conventional and established way. It's highly inappropriate and very much ignorant!

[DougieLawson]

Welcome to the "bleeding edge loonies club". Membership is free, you just have to run BRANCH=next rpi-update or build and deploy your own kernel.

[PhilE]

We appreciate the fact that some people are prepared to try life on the cutting edge because they multiply our testing facilities - they get the cool new features first, and occasionally they get the bugs first too, which keeps everybody else safer.

This thread is here to support the brave; questioning their presence here is off-topic noise.

[kmedcalf]

cd /boot
rm .firmware_revision

run rpi-update again

[DougieLawson]

We appreciate the fact that some people are prepared to try life on the cutting edge because they multiply our testing facilities - they get the cool new features first, and occasionally they get the bugs first too, which keeps everybody else safer.

This thread is here to support the brave; questioning their presence here is off-topic noise.

I'm not questioning the presense, I'm asking that the apt-get stuff does the right stuff for the friendly loonies as that will make everyone's life a bunch easier.

Eight of my eleven raspberries are now running 4.9.0. Seven got updated to it yesterday. My 3B has been running that kernel for two weeks (because it's also doing the USB booting stuff). All eight of those are now getting rpi-update run every day at 4:00am.

The other three are running old (with a very long uptime on a 1B) or specialised kernel (Wolfson on a 1B) or my public web server (B+ which needs 24/7 availability).

[rpdom]

I'm asking that the apt-get stuff does the right stuff for the friendly loonies as that will make everyone's life a bunch easier.

You're asking that apt goes outside its domain to handle "fringe" cases.

The official Debian policy for apt has been that if you step outside of the apt controlled environment you are on your own, because you believe that you know how to manage you system beyond what apt is aware of and any problems you get is your own responsibility.

If anything it is rpi-update that should mark the rpi-bootloader package as "held" to prevent the updated files from being overwritten.

[Penthux]

We appreciate the fact that some people are prepared to try life on the cutting edge because they multiply our testing facilities - they get the cool new features first, and occasionally they get the bugs first too, which keeps everybody else safer.

This thread is here to support the brave; questioning their presence here is off-topic noise.

I'm not questioning the presense, I'm asking that the apt-get stuff does the right stuff for the friendly loonies as that will make everyone's life a bunch easier.

Eight of my eleven raspberries are now running 4.9.0. Seven got updated to it yesterday. My 3B has been running that kernel for two weeks (because it's also doing the USB booting stuff). All eight of those are now getting rpi-update run every day at 4:00am.

The other three are running old (with a very long uptime on a 1B) or specialised kernel (Wolfson on a 1B) or my public web server (B+ which needs 24/7 availability).

@DougieLawson: and what I'm saying is that one of my Raspberry Pi 3 devices has been running an aarch64 (armv8) kernel 4.9.0 for about 3 weeks... but I didn't manage that by using 'BRANCH=next rpi-update' commands! I'm also running an armv8 kernel 4.10 in the same fashion. The move to a kernel 4.9 for the Raspberry Pi platform might be considered as a great step forward for users such as yourself, but for some of us it's old news. Spare a thought for those users who might take exception to how you refer to them because they don't use, or depend on, rpi-update to make them feel like they have achieved something. You can rave about your awesomeness, or the multitude of Raspberry Pi's you have and what your doing with them, all you like but my point is, you didn't build those kernels/modules yourself, or configure your system to accept or accommodate any changes. Anybody can type 'dah-dee-dah' at the command prompt and achieve what you've done. I've done it myself a dozen times or more. That's not the bleeding edge, it's the bleeding results of using the 'BRANCH=next rpi-update' command and nothing more.

@PhilE: I'm quite interested in what you guys are doing right now and how you're moving ever closer towards kernel 4.9.x, with a special interest in the Raspberry Pi firmware and if there's any support planned for the aarch64 (arm64/armv8.1) architecture. My chosen Linux distro is Slackware ARM so it's not really relevant here. I put a great deal of time and effort into supporting Slackware ARM on all of your devices (except the Zero) and have done for well over 4 (four) years! The installers I create, along with the kernels/modules/DTBs, are entirely custom-built using conventional methods. Using rpi-update to upgrade your kernel/modules/firmware works very well 99.999% of the time and is a very convenient way of doing it. There's no shame in doing it that way! It's not the best way to learn exactly what's going on during the process or which files are being modified/changed/created/overwritten/etc. Incidentally, I do take exception to Raspbian n00bz referring to other users due to their subjective choices or methods, in whatever context, as 'loonies' because at the end of the day the work I'm involved in is far in advance of your regular Raspberry Pi user utilising the rpi-update command/options. Yet, you don't see me going around patting myself on the back for it, or wanting the spotlight to be pointing at me with much adulation and fanfare. I sometimes wonder if rpi-update wasn't available just how many of these 'Linux gurus' would be running anything other than the stock kernel/modules/firmware. Probably not the majority. From personal experience, Linux users in general these days don't want to work at achieving something, they much prefer to be handed the work of others on a plate for them to use (i.e. the easy way to achieving greatness) and then somehow justify themselves as having done something notable and/or remarkable. Linux distros like Raspbian make it easy for people to get involved in something other than MS Windows, which can only be a good thing.

However, as I've already stated, I am focussing on the kernel 4.9/4.10 and aarch64/arm64. I'll be keeping a close eye on any and all related developments from the RPi Foundation regarding the move to 4.9.x. I wish you well in all your endeavours, PhilE.

[DougieLawson]

The official Debian policy for apt has been that if you step outside of the apt controlled environment you are on your own, because you believe that you know how to manage you system beyond what apt is aware of and any problems you get is your own responsibility.

If anything it is rpi-update that should mark the rpi-bootloader package as "held" to prevent the updated files from being overwritten.

I think we all agree that the DebIan policy lacks agility compared to things like Ubuntu and Arch.

rpi-update marking packages as held is certain to screw up the random general users who continue to run it without knowing how much closer to the bleeding edge it's taking them, so that's not a good idea.

[holywen]

Cann't enable BBR as the tcp_congestion_control algorithm.

Does this work on the current 4.4 kernel?

BBR is a new feature of the 4.9 kernel.

[dom]

BBR is a new feature of the 4.9 kernel.

In general we don't enable every kernel config option (that default to disabled).
Open an issue explaining why you think it is useful for RPi and we'll consider adding it.

[Penthux]

In general we don't enable every kernel config option (that default to disabled).
Open an issue explaining why you think it is useful for RPi and we'll consider adding it.

@dom: Do you have any kind of timeframe or E.T.A. for upgrading to kernel 4.9.x?

<edit> After 3 days and in the absence of any form of response, perhaps "No" is too much to expect ...

[holywen]

BBR is a new feature of the 4.9 kernel.

In general we don't enable every kernel config option (that default to disabled).
Open an issue explaining why you think it is useful for RPi and we'll consider adding it.

issue created: https://github.com/raspberrypi/linux/issues/1784

[dom]

@dom: Do you have any kind of timeframe or E.T.A. for upgrading to kernel 4.9.x?

The decision hasn't been made yet. I'm imagining we'll move mast rpi-update to 4.9 within the next few weeks.
Ideally we'll push a fix for Chromium before then.
Then it depends on feedback. It may appear in the next raspbian/apt update if there are few problems or it may be the subsequent one if there are still issues to resolve.

[cjan]

one question
when rpi-update or NEXT_BRANCH, where can fine kernel-headers?

[Gavinmc42]

Some people don't understand "bleeding edge".
For example, try explaining to the kid why he cannot watch youtube on the TV any more cause Daddy upgraded the kernel to 4.9
Talk about meltdown. Try also explaining why screaming at computers don't fix them

Hopefully the next Chromium fix fixes this issue.
Or it can "stay" broken until the YT addiction wears off?
Hopefully someone will come up with an AR system that gets kids outside again instead of sitting in front of Pi's.
Er, that might get me burnt at the RPF stake

Big, Big mistake showing the kid youtube on the big screen
How was I to know it would work? Really the Pi OS is just getting too good.
Secret code to add lag? RFID tag that enables youtube for 1 hour/day?

[asavah]

Some people don't understand "bleeding edge".
Secret code to add lag? RFID tag that enables youtube for 1 hour/day?

rpicam + face recognition + logging amount of time spent watching TV + denying youtube if time quota exceeded

Heh, that would be a good idea for a project.

[Penthux]

@dom: Do you have any kind of timeframe or E.T.A. for upgrading to kernel 4.9.x?

The decision hasn't been made yet. I'm imagining we'll move mast rpi-update to 4.9 within the next few weeks.
Ideally we'll push a fix for Chromium before then.
Then it depends on feedback. It may appear in the next raspbian/apt update if there are few problems or it may be the subsequent one if there are still issues to resolve.

Ok, good to know. Thanks for that.

The only issues I've encountered so far is with loading an initrd ramfsfile. That's on the Raspberry Pi 1, 2 and 3. It started working on the RPi 1 last weekend but it's still borked on the Rpi2 and RPi3. This is with the rpi4.9.y Linux kernel branch and next firmware branch from the RPi repository on GitHub.

[dom]

The only issues I've encountered so far is with loading an initrd ramfsfile. That's on the Raspberry Pi 1, 2 and 3. It started working on the RPi 1 last weekend but it's still borked on the Rpi2 and RPi3. This is with the rpi4.9.y Linux kernel branch and next firmware branch from the RPi repository on GitHub.

Are you saying initrd is working on 4.4 kernel and not on 4.9 kenrel? But only on Pi2/Pi3?

[Penthux]

Are you saying initrd is working on 4.4 kernel and not on 4.9 kenrel? But only on Pi2/Pi3?

@dom : No, what I'm saying is... I'm ONLY working with the 'next' firmware branch and Linux kernel 'rpi-4.9.y' branch from the RPi repository.

Before last weekend, through trial and error, the code I found that worked on a RPi1 to load the initrd was this:

Code: Select all

------------
config.txt file: (only showing the code for loading the initrd)
------------
ramfsfile initrd.gz 0xa00000

--------------
cmdline.txt file:
--------------
dwc_otg.lpm_enable=0 console=tty1 nofont root=/dev/mmcblk0p3 rootfstype=ext4 rootwait ro initrd=0xa00000,0x399da3c

Then it stopped working (on Sunday) after I updated the boot firmware and then, through trial and error, the code I found which worked was now this:

Code: Select all

------------
config.txt file: (only showing the code for loading the initrd)
------------
ramfsfile=initrd.gz 
ramfsaddr=0xa00000

--------------
cmdline.txt file:
--------------
dwc_otg.lpm_enable=0 console=tty1 nofont root=/dev/mmcblk0p3 rootfstype=ext4 rootwait ro initrd=0xa00000,0x399da3c

Neither implementation of this code, or any variation of it, seems to work on the RPi2 and RPi3 to load the initrd. I've yet to find a working solution which successfully loads the initrd on a Rpi2 and RPi3. Yes, I've made sure the rootfs is /dev/mmcblk0p3 and made extra sure it was prepared and formatted ext4.

The error message I'm getting with the Rpi2 and Rpi3 is that the initrd cannot be mounted on an unknown filesystem with additional advice that I should "pass initrd= boot parameter to the kernel". As you can see, it already *has* been passed to the kernel by the cmdline.txt file. The same code to load the initrd works as intended on the RPi1.

<edit> forgot to say... if I use the 'master' firmware branch this code and the initrd mounts, loads, and runs like a charm on the Rpi 1, 2 and 3!

[asavah]

@Penthux
Which start.elf and fixup.dat are you using?
I'm currently having massive problems with "_x" versions of the blobs, while standard versions work like a charm.
https://github.com/raspberrypi/firmware/issues/715

If you are using start_x.elf and fixup_x.dat could you try "standard" start.elf and fixup.dat?

[PhilE]

Unless you know what you are doing and have very good reason to, you are better off letting the firmware decide where to load the initrd:

Code: Select all

initramfs initrd.gz followkernel

Note also the new, preferred syntax ("initramfs <file> <addr>"), although the old version is still supported.