Moving Linux kernel to 4.9


279 posts   Page 9 of 12   1 ... 6, 7, 8, 9, 10, 11, 12
by Siewert308SW » Wed Mar 22, 2017 12:49 pm
Try this by adding i2c_arm_baudrate=10000 to your /boot/config.txt
Before the firmware fix this solved some.
Don't know if the PIco 1.0 and 1.1 have the same behaviour.
And i would advice you to get info from the pico dev has he is the one to solve this for older pico aswell.
It aint a kernel but firmware issue.
Setup:
1x RPi3 - PIco hv3.0A Plus / Domoticz / RFXtrx433E
1x RPi3 - PiHole / logging gas,elec
3x FI9803P Cam
2x Youless Elec/Gas
4x KD101 detectors
a lot of KaKu/CoCo stuff

My Domoticz scripts: https://github.com/Siewert308SW
User avatar
Posts: 33
Joined: Fri Feb 27, 2015 1:31 pm
Location: The Netherlands
by g8gkq » Thu Mar 30, 2017 10:44 am
I am using a Waveshare 3.5inch RPi LCD (A) touchscreen display on an RPi3. It has worked perfectly with Jessie Lite 2016-11-25 and rpi-update until the kernel was bumped to 4.9.y (about 21 Feb 17). After the kernel update, the display does not get loaded during boot, although the touch sensor still works.

dmesg fragment when working (before):
Code: Select all
[    2.918893] spi_master spi0: spi_device register error /soc/spi@7e204000/waveshare35a-ts@1
[    2.918971] spi_master spi0: Failed to create SPI device for /soc/spi@7e204000/waveshare35a-ts@1
[    2.920678] bcm2835-wdt 3f100000.watchdog: Broadcom BCM2835 watchdog timer
[    2.924949] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[    3.075332] ads7846 spi0.1: touchscreen, irq 183
[    3.076062] input: ADS7846 Touchscreen as /devices/platform/soc/3f204000.spi/ spi_master/spi0/spi0.1/input/input0
[    3.156998] fbtft: module is from the staging directory, the quality is unknown, you have been warned.
[    3.187938] fb_ili9486: module is from the staging directory, the quality is unknown, you have been warned.
[    3.188758] pinctrl-bcm2835 3f200000.gpio: pin gpio17 already requested by spi0.1; cannot claim for spi0.0
[    3.188779] pinctrl-bcm2835 3f200000.gpio: pin-17 (spi0.0) status -22
[    3.188796] pinctrl-bcm2835 3f200000.gpio: could not request pin 17 (gpio17) from group gpio17  on device pinctrl-bcm2835
[    3.188809] fb_ili9486 spi0.0: Error applying setting, reverse things back
[    3.188883] fbtft_of_value: regwidth = 16
[    3.188895] fbtft_of_value: buswidth = 8
[    3.188907] fbtft_of_value: debug = 0
[    3.188916] fbtft_of_value: rotate = 90
[    3.188926] fbtft_of_value: fps = 30
[    3.188936] fbtft_of_value: txbuflen = 32768
dmesg fragment now (not working):
Code: Select all
spi-bcm2835 3f204000.spi: chipselect 1 already in use
[    2.851422] spi_master spi0: spi_device register error /soc/spi@7e204000/waveshare35a-ts@1
[    2.851447] spi_master spi0: Failed to create SPI device for /soc/spi@7e204000/waveshare35a-ts@1
[    3.090330] spi0.1 supply vcc not found, using dummy regulator
[    3.090839] ads7846 spi0.1: touchscreen, irq 183
[    3.091471] input: ADS7846 Touchscreen as /devices/platform/soc/3f204000.spi/spi_master/spi0/spi0.1/input/input0
[    3.150061] fbtft: module is from the staging directory, the quality is unknown, you have been warned.
[    3.161890] fb_ili9486: module is from the staging directory, the quality is unknown, you have been warned.
[    3.163198] pinctrl-bcm2835 3f200000.gpio: pin gpio17 already requested by spi0.1; cannot claim for spi0.0
[    3.163217] pinctrl-bcm2835 3f200000.gpio: pin-17 (spi0.0) status -22
[    3.163230] pinctrl-bcm2835 3f200000.gpio: could not request pin 17 (gpio17) from group gpio17  on device pinctrl-bcm2835
[    3.163239] fb_ili9486 spi0.0: Error applying setting, reverse things back
[    3.163265] fb_ili9486: probe of spi0.0 failed with error -22
So, the display seems to have some problem communicating with spi. It works perfectly again after a kernel rollback to 4.4.50.

Is there anything else I can look at to work out what's going wrong as I really want to make sure that the display will continue to work in the future?

Thanks

Dave
Posts: 6
Joined: Thu Mar 30, 2017 10:25 am
Location: Southampton
by allfox » Fri Mar 31, 2017 2:21 pm
On Pi 3, /bin/echo none > /sys/class/leds/led1/trigger is not working now. Red PWR led stay lit.

Firmware reversion edd3e6c00078c2a8c28196030a7f2dd151c277e7 and f9c1f6aab19cb827acb4e654f363014c0edfece6 neither is working.

Not a big problem though.
User avatar
Posts: 331
Joined: Sat Jun 22, 2013 1:36 pm
Location: Guang Dong, China
by DougieLawson » Sat Apr 01, 2017 6:33 am
https://github.com/Hexxeh/rpi-firmware/ ... d151c277e7 is BROKEN. You need to move forward to https://github.com/Hexxeh/rpi-firmware/ ... 4c0edfece6 to get the 4.9.19 kernel and bootcode (that doesn't break on a RPiZero).
Microprocessor, Raspberry Pi & Arduino Hacker
Mainframe database troubleshooter
MQTT Evangelist
Twitter: @DougieLawson

Since 2012: 1B*5, 2B*2, B+, A+, Zero*2, 3B*3

Please post ALL technical questions on the forum. Do not send private messages.
User avatar
Posts: 28160
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
by PhilE » Sat Apr 01, 2017 6:52 am
@g8gkq Even the working kernel doesn't look very happy. What do you have in config.txt? And do you have any other hardware attached?
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1151
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge
by g8gkq » Sat Apr 01, 2017 9:14 am
@PhilE

Thanks for looking. Yes, I was worried about the original installation, but it worked so I left it alone. No other hardware attached for this test - just network and power (although complete installation can include PiCam, USB Video capture and RTL-SDR). /boot/config.txt:
Code: Select all
# For more options and information see
# http://www.raspberrypi.org/documentation/configuration/config-txt.md
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

## Begin LCD Driver
dtparam=spi=on
dtoverlay=waveshare35a
dtoverlay=ads7846,cs=1,penirq=17,penirq_pull=2,speed=1000000,keep_vref_on=1,swapxy=1,pmax=255,xohms=60,xmin=200,xmax=3900,ymin=200,ymax=3900
## End LCD Driver

##Enable Pi Camera

gpu_mem=128
start_x=1
File waveshare35a.dtbo is in /boot/overlays

Thanks, Dave
Posts: 6
Joined: Thu Mar 30, 2017 10:25 am
Location: Southampton
by PhilE » Sat Apr 01, 2017 11:16 am
This error message is a big clue as to what is going wrong:
Code: Select all
[    3.163198] pinctrl-bcm2835 3f200000.gpio: pin gpio17 already requested by spi0.1; cannot claim for spi0.0

You have two overlays loaded:
Code: Select all
dtoverlay=waveshare35a
dtoverlay=ads7846,cs=1,penirq=17,penirq_pull=2,speed=1000000,keep_vref_on=1,swapxy=1,pmax=255,xohms=60,xmin=200,xmax=3900,ymin=200,ymax=3900
The waveshare35a overlay (not one of the standard ones, but I found it here: https://github.com/swkim01/waveshare-dt ... verlay.dts) declares an ilitek screen on spi0.0 and an ads7846 touchscreen on spi0.1, while the ads7846 overlay also declares an ads7846 on spi0.1. The actual error is caused by the declaration of the GPIO interrupt line used by the touchscreen - GPIO 17 (although the IRQ is for the touchscreen, the waveshare overlay reserves it on behalf of the display (not a problem), hence the spi0.0 vs spi0.1 contention.

I suspect the kernel upgrade has altered the device loading order for some reason - I've seen something similar elsewhere but not identified the precise cause yet - so the other overlay is winning. Try commenting out the dtoverlay=ads7846 line - you shouldn't need both. If you are relying on the extra customisation of the ads7846 overlay, there's no reason why we can't take the parameters from the ad7846 overlay and graft them onto the waveshare35a overlay - I'd even add it to the standard kernel image.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1151
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge
by g8gkq » Sat Apr 01, 2017 12:14 pm
@PhilE

Thanks! I commented out the dtoverlay=ads7846 line and both the display and touchscreen now work perfectly in my system. No need for customisation. dmesg also looks tidy now! I'll amend my install script to remove that line.

There are over 100 enthusiasts using my build to generate and then transmit digital amateur television signals, so I'm really pleased that I'm going to be able to continue to support them with the latest kernel. Details here if you're interested: https://wiki.batc.tv/The_Portsdown_Transmitter and https://github.com/BritishAmateurTelevisionClub/rpidatv

I'm really grateful for your time.

Dave
Posts: 6
Joined: Thu Mar 30, 2017 10:25 am
Location: Southampton
by kofler » Fri Apr 07, 2017 5:45 am
I stumbled across two problems with Kernel 4.9:

Mathematica: GPIO-Functions no longer work (error code 6 was returned during the initialization of the library /opt/Wolfram/WolframEngine/11.0/SystemFiles/Components/MRAALink/LibraryResources/Linux-ARM/MRAALink.so etc.), for more details see: http://community.wolfram.com/groups/-/m/t/1055614

Java + Pi4J: Also GPIO problems (BCM2835 error), see https://github.com/Pi4J/pi4j/issues/319

In the end, I reverted back to 4.4. This should be addressed before 4.9 gets available via apt-get dist-upgrade.

Best wishes,

Michael Kofler
Posts: 1
Joined: Wed Aug 06, 2014 8:29 am
by gordon@drogon.net » Fri Apr 07, 2017 11:29 am
kofler wrote:I stumbled across two problems with Kernel 4.9:

Mathematica: GPIO-Functions no longer work (error code 6 was returned during the initialization of the library /opt/Wolfram/WolframEngine/11.0/SystemFiles/Components/MRAALink/LibraryResources/Linux-ARM/MRAALink.so etc.), for more details see: http://community.wolfram.com/groups/-/m/t/1055614

Java + Pi4J: Also GPIO problems (BCM2835 error), see https://github.com/Pi4J/pi4j/issues/319

In the end, I reverted back to 4.4. This should be addressed before 4.9 gets available via apt-get dist-upgrade.

Best wishes,

Michael Kofler


I am unable to decode the stuff on the wolfram site. Is it using wiringPI?

If so, then simply apt-get update/upgrade to get the latest wiringPi.

However I have been getting many emails about the pi4j stuff. I do not understand why people will upgrade their kernels to the bleeding edge using rpi-update and not bother to upgrade the rest of it. I fixed wiringPi for the 4.8/4.9 kernels back in December 2016.

Sadly even after apt-get update/upgrade (to get wiringPi version 2.44) I still get emails from pi4j users - it seems that pi4j my have compiled in a static version of wiringPi (violating the LGPL) and simply upgrading wiringPi does not seem to fix this, however I am not a Pi4J user so really have no clue about how it's bound in.

If you are a Pi4j user and gpio stops working then either stay away from the bleeding edge kernel and wait until the foundation release the 4.9 kernel properly, or complain LOUDLY at the people who put pi4j together to make the use the packaged version of wiringPi and not build it into the system.

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1944
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by axlslak » Mon Apr 10, 2017 4:52 pm
gordon@drogon.net wrote:stay away from the bleeding edge kernel and wait until the foundation release the 4.9 kernel properly


just for my own curiosity... when you run rpi-update (without any parameters) you will get a warning, and then a 4.9 series kernel. 4.9.20 to be exact. and these kernels, are released by the same foundation? right?

and as far as I can see, on kernel.org the 4.9 line is marked as long term.

where and what points to bleeding edge?
Posts: 5
Joined: Sun Dec 08, 2013 8:28 pm
by gordon@drogon.net » Mon Apr 10, 2017 5:05 pm
axlslak wrote:
gordon@drogon.net wrote:stay away from the bleeding edge kernel and wait until the foundation release the 4.9 kernel properly


just for my own curiosity... when you run rpi-update (without any parameters) you will get a warning, and then a 4.9 series kernel. 4.9.20 to be exact. and these kernels, are released by the same foundation? right?

and as far as I can see, on kernel.org the 4.9 line is marked as long term.

where and what points to bleeding edge?


My understanding is that rpi-update gets you a kernel that's a "work in progress" and that when the powers that be are happy with it, then it gets moved into the apt-get update/upgrade system. This hasn't happened yet as far as I can tell (however I've been away for a week, so not checked).

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1944
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by bensimmo » Mon Apr 10, 2017 5:19 pm
axlslak wrote:
gordon@drogon.net wrote:stay away from the bleeding edge kernel and wait until the foundation release the 4.9 kernel properly


just for my own curiosity... when you run rpi-update (without any parameters) you will get a warning, and then a 4.9 series kernel. 4.9.20 to be exact. and these kernels, are released by the same foundation? right?

and as far as I can see, on kernel.org the 4.9 line is marked as long term.

where and what points to bleeding edge?


I believe some people use the term 'bleeding edge' to represent testing/beta software that is not released to the mainstream and used by people who wish to adopt a setup early.
W.r.t. Raspian that is still at 4.4, the 4.9 is being tested in beta or with early adopters to get it all working smoothly with everything else in Raspian as it should.
It is not w.r.t. Linux or anything else.

(that not my terminology of bleeding edge though,to me it is something pushing the boundaries, not been done before and pushing into new technology, solutions. Each to their own)
Posts: 1290
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire
by axlslak » Mon Apr 10, 2017 7:51 pm
but ultimately the foundation needs you guys to test stuff. so... maybe be nice to the testers. just sayin...

PS if you weren't there, don't just apply "bleeding edge" to things. u don't know. nothing has been bleeding edge since like a decade ago. there's no such thing.
Posts: 5
Joined: Sun Dec 08, 2013 8:28 pm
by underwhelmd » Tue Apr 11, 2017 3:12 am
I've done something wrong here. Not sure how to fix it so I have to ask:

I've been running "4.9.13+ #974 Wed Mar 1" on a Zero. It's been running fine. I went to check for updates tonight because it's been a while. Like so:
Code: Select all
uname -a
Linux zero2 4.9.13+ #974 Wed Mar 1 20:04:40 GMT 2017 armv6l GNU/Linux

sudo apt-get update
...edited...

sudo apt-get upgrade
...edited...
The following packages will be upgraded:
  libjasper1 libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc
  libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel realvnc-vnc-server
  realvnc-vnc-viewer
I chose yes


So after that and a reboot-
Code: Select all
uname -a
Linux zero2 4.4.50+ #970 Mon Feb 20 19:12:50 GMT 2017 armv6l GNU/Linux


It rolled back to 4.4.x

Code: Select all
sudo BRANCH=next rpi-update
...edited...
*** Your firmware is already up to date


How can I get back to 4.9.x ? Thank you in advance.
User avatar
Posts: 46
Joined: Fri Jul 08, 2016 10:05 pm
Location: East Coast, Canada
by MrEngman » Tue Apr 11, 2017 3:51 am
To get back to where you were edit and change the value in file /boot/.firmware_revision or delete it. Then run
Code: Select all
sudo BRANCH=next rpi-update
again.

Or if you do not change file /boot/.firmware_revision and run
Code: Select all
sudo rpi-update
without BRANCH=next you will get updated to kernel 4.9.20+ #985.

Using rpi-update is generally regarded as not a good thing unless you understand what can happen as it will install a kernel under development and can cause problems with things not working sometimes.



MrEngman
Simplicity is a prerequisite for reliability. Edsger W. Dijkstra

Please post ALL technical questions on the forum. Please Do Not send private messages.
Posts: 3475
Joined: Fri Feb 03, 2012 2:17 pm
Location: Southampton, UK
by underwhelmd » Tue Apr 11, 2017 4:14 am
Thanks. Sorted.

I'd kinda like to know why "apt-get upgrade" thought that installing a kernel of a lesser numerical value was a good thing.
User avatar
Posts: 46
Joined: Fri Jul 08, 2016 10:05 pm
Location: East Coast, Canada
by MrEngman » Tue Apr 11, 2017 4:33 am
apt-get upgrade will install the latest stable kernel if available in the list of packages loaded by apt-get-update regardless of the current kernel you are running. This currently happens to be 4.4.50.



MrEngman
Simplicity is a prerequisite for reliability. Edsger W. Dijkstra

Please post ALL technical questions on the forum. Please Do Not send private messages.
Posts: 3475
Joined: Fri Feb 03, 2012 2:17 pm
Location: Southampton, UK
by gordon@drogon.net » Tue Apr 11, 2017 5:41 am
underwhelmd wrote:Thanks. Sorted.

I'd kinda like to know why "apt-get upgrade" thought that installing a kernel of a lesser numerical value was a good thing.


Maybe spending a few moments reading the rest of this thread would be a good thing

In essence, the recommended way to get updates to the system including kernel for the vast majority of users is to use apt-get update/upgrade.

If you are interested in helping the folks who work on the kernel to test the latest kernel and are prepared to report back issues to them, or you strongly feel that you need 4.9 features then you use rpi-update.

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1944
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by mfa298 » Tue Apr 11, 2017 6:46 am
underwhelmd wrote:Thanks. Sorted.

I'd kinda like to know why "apt-get upgrade" thought that installing a kernel of a lesser numerical value was a good thing.


apt-get works from the package versions in it's database. The most recent package is from last week
Code: Select all
pi@pi2:~ $ apt-cache show raspberrypi-kernel
Package: raspberrypi-kernel
Source: raspberrypi-firmware
Version: 1.20170405-1
...
Filename: pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20170405-1_armhf.deb
...


When you use rpi-update that upgrades the kernel by overwriting the files managed by the kernel and firmware packages, however apt isn't aware of that. So when a new kernel is provided via apt it thinks there's and update and applies it.

Generally you should use apt-get upgrade or rpi-update to install the kernel not both. Leave it with apt-get if you want to stay on something stable and well tested, move to rpi-update if you want the latest and greatest but less tested (possibly buggy) option.
Posts: 949
Joined: Tue Apr 22, 2014 11:18 am
by bensimmo » Tue Apr 11, 2017 7:12 am
Since I don't know...
Why is 'rpi-update' used and not 'apt' for these testing branches?
I.e. Why not just have a new repository to test them from, add the source link to apt source making it easy to know what you are using and obvious you are doing it.

Or is that something apt cannot actually do?

Thanks.
(and i know there are the testing and unstable debian branches, but that was.r.t. the main debian not a Raspian branch)
Posts: 1290
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire
by DougieLawson » Tue Apr 11, 2017 9:00 am
bensimmo wrote:Since I don't know...
Why is 'rpi-update' used and not 'apt' for these testing branches?
I.e. Why not just have a new repository to test them from, add the source link to apt source making it easy to know what you are using and obvious you are doing it.

Or is that something apt cannot actually do?

Thanks.
(and i know there are the testing and unstable debian branches, but that was.r.t. the main debian not a Raspian branch)


If you do it with apt-get then EVERY user who runs apt-get update && apt-get upgrade gets the testing kernel. That is entirely undesirable due to things like https://github.com/raspberrypi/firmware/issues/725 https://github.com/raspberrypi/firmware/issues/730 and https://github.com/raspberrypi/linux/issues/1937 (which are just three of the kernel/bootcode bugs I've found).

rpi-update (which currently gets 4.9.20+ #985 from April 3rd) and that's the absolute latest development kernel/bootcode which may be full of undiscovered bugs (as far as I can tell with twelve of my Raspberries running it, it isn't). The folks running rpi-update a) understand exactly what rpi-update does b) know how to recover a system that won't boot in minutes (rather than hours) and c) are willing to work through the bugs with the RPF folks (by creating issues on Github). That's not the general population, most folks should NEVER need to run rpi-update (and IMNHO it shouldn't be installed as part of standard Raspbian).

The general population needs a stable kernel, so apt-get ships a well tested, stable, old 4.4.50 kernel and for 99.99% of folks that will "just work" and will work well. The folks who have strange hardware may need to run with a non-standard kernel, they need to work out for themselves how to get their "custom" kernel/bootcode on to their SDCard.

If folks are going to run rpi-update then most of them should be staying on the leading edge of development by running it frequently, when their feature that needs a special kernel gets into the mainstream stable kernel that's the time to stop running it. Going back to 4.9.13 #974 is an exceedingly bad idea as that's never going to be released as the stable kernel. The future stable 4.9.?? kernel will be at least 4.9.20+ or later.
Microprocessor, Raspberry Pi & Arduino Hacker
Mainframe database troubleshooter
MQTT Evangelist
Twitter: @DougieLawson

Since 2012: 1B*5, 2B*2, B+, A+, Zero*2, 3B*3

Please post ALL technical questions on the forum. Do not send private messages.
User avatar
Posts: 28160
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
by mfa298 » Tue Apr 11, 2017 9:22 am
DougieLawson wrote:
bensimmo wrote:Since I don't know...
Why is 'rpi-update' used and not 'apt' for these testing branches?
I.e. Why not just have a new repository to test them from, add the source link to apt source making it easy to know what you are using and obvious you are doing it.


If you do it with apt-get then EVERY user who runs apt-get update && apt-get upgrade gets the testing kernel. That is entirely undesirable due to things like https://github.com/raspberrypi/firmware/issues/725 https://github.com/raspberrypi/firmware/issues/730 and https://github.com/raspberrypi/linux/issues/1937 (which are just three of the kernel/bootcode bugs I've found).


You could have alternate kernels delivered via apt that have to specifically be requested, however I think that would require a change to how the raspbian kernels and firmware are currently packaged. Ubuntu does this, for instance searching for the linux-image packages in trusty I get:
linux-image-generic-lts-utopic - Generic Linux kernel image
linux-image-generic-lts-vivid - Generic Linux kernel image
linux-image-generic-lts-wily - Generic Linux kernel image
linux-image-generic-lts-xenial - Generic Linux kernel image


The downside to this is you only really get the latest version in each stream, if you want to revert to a previous build that becomes harder - rpi-update can manage that more easily.

Looking at my raspbian installs (rpi-update doesn't look to be installed by default) so assuming most people install it via apt I wonder if there should be some updates to that package. One obvious change might be to pin the current apt kernel packages so they don't get later updates. Another thing I've seen is displaying a warning that needed more than just a yes/no answer when installing - I saw this when changing wheezy from sysvinit to using upstart and you had to type something like 'I UNDERSTAND' to continue.
Posts: 949
Joined: Tue Apr 22, 2014 11:18 am
by DougieLawson » Tue Apr 11, 2017 10:14 am
mfa298 wrote:Looking at my raspbian installs (rpi-update doesn't look to be installed by default) so assuming most people install it via apt ...


It's there in the 2017-03-02-rasbian-jessie.img so it is installed by default on current Raspbian.

sudo -i
losetup /dev/loop0 -o $((137216 * 512)) 2017-03-02-raspbian-jessie.img
mount /dev/loop0 /mnt
cd /mnt/usr/bin
ls -la rpi-update
cd /
umount /mnt
losetup -d /dev/loop0
exit


Code: Select all
root@challenger:/mnt/usr/bin# ls -la rpi-update
-rwxr-xr-x 1 root root 7037 Jul  8  2014 rpi-update
root@challenger:/mnt/usr/bin#
Microprocessor, Raspberry Pi & Arduino Hacker
Mainframe database troubleshooter
MQTT Evangelist
Twitter: @DougieLawson

Since 2012: 1B*5, 2B*2, B+, A+, Zero*2, 3B*3

Please post ALL technical questions on the forum. Do not send private messages.
User avatar
Posts: 28160
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
by bensimmo » Tue Apr 11, 2017 1:17 pm
Thanks Dougie, but I was meaning, you add an entry into the apt sources yourself, (or it there and you just uncommented). At which point apt switches to that, a bit like people wanting to run or test squeeze or sid, but a specific Raspian testing source.
Posts: 1290
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire