• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1] 2
Author Topic: 2.6.30.5 new release  (Read 8615 times)
cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« on: August 16, 2009, 07:40:12 PM »

2.6.30.5 is now available.

.5 fixes a kernel vulnerability that existed in all previous kernel versions (although .3 and .4 were relatively safe when vm.mmap_min_addr was not set to zero.

Due to changes in vm security a change must be made in /etc/sysctl.d/10-process-security.conf if the file exists.  vm.mmap_min_addr should be set to 32768 (This change is safe for any kernel version).  If this is not done it is likely that you will not be able to login remotely.  Although you should still be able to login as root on the main console.

Kernel and modules are available from the following locations:

IPV4: http://sheeva.with-linux.com/sheeva/

IPV6: http://sheeva6.with-linux.com/sheeva/

Features IPV6, CIFS, NFS4, EXT3, EXT4, JFS, XFS, FUSE(for ntfs-3g), UBIFS, usb-serial, uvcvideo, iptables, appletalk, bluetooth, v4l and ppp.
Logged

calamari
Newbie
*

Karma: 0
Posts: 23


View Profile
« Reply #1 on: August 18, 2009, 11:23:09 AM »

Thank you very much for your precompiled kernels, cbxbiker61! This is very much appreciated.

I installed the 2.6.30.5 kernel using the HowTo in the Wiki and it worked flawlessly.

However I'm now getting a segfault when running cryptsetup on a partition of a USB stick. This has worked without problems before when using the original (very old) kernel of the SheevaPlug. I've attached the according part of the kernel messages. Do you have any idea what this is caused by / how to fix this?

* cryptsetup-segfault.txt (10.15 KB - downloaded 235 times.)
Logged

calamari
Newbie
*

Karma: 0
Posts: 23


View Profile
« Reply #2 on: August 18, 2009, 11:42:15 AM »

Just found this post, which might be related.
Logged

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #3 on: August 18, 2009, 12:43:45 PM »

If it could be said that the original kernel had any advantage, it was that it came with a dm_crypt that utilized the Plug's hardware DES/AES engine.  The 2.6.30.X releases here do not, and as far as I can tell in these otherwise excellent kernels, the dm_crypt has never worked correctly for some reason.
« Last Edit: August 18, 2009, 02:21:42 PM by restamp » Logged

mgillespie
Full Member
***

Karma: 8
Posts: 239



View Profile
« Reply #4 on: August 18, 2009, 01:58:58 PM »

Thanks installed it effortly (after commenting out the IPV6 entry due to OpenDNS problems).
Logged

Deviant0ne
Newbie
*

Karma: 0
Posts: 30



View Profile
« Reply #5 on: August 19, 2009, 06:04:16 PM »

I am trying to get a VPN up and running, but this kernel doesn't have IPSec support...? Do I need to compile a custom kernel to get IPSec working? Is this even possible with this kernel?
« Last Edit: August 19, 2009, 06:29:06 PM by Deviant0ne » Logged

CqCn
Full Member
***

Karma: 0
Posts: 169



View Profile
« Reply #6 on: August 19, 2009, 07:31:17 PM »

If one has already installed a previous version, say 2.6.30.4, is there a shorter or different upgrade sequence?  Is it described anywhere?
Logged

Cordially, CqCn

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #7 on: August 19, 2009, 08:09:20 PM »

Not sure what your precise setup is, Cq, but cbxbiker61 has made it very easy to upgrade if you boot the kernel from NAND.  Essentially, you just "wget http://sheeva.with-linux.com/sheeva/README-2.6.30.5" (or whatever the latest version is), make the file executable, and then execute the README as a command.

If you boot the kernel from the SDcard, you'll have to make a few minor changes to the bash script.

(Or, do I misunderstand what you are asking?)
Logged

iambvk
Newbie
*

Karma: 0
Posts: 13


View Profile
« Reply #8 on: August 19, 2009, 08:51:07 PM »

Does this 2.6.30.5 kernel has inbuilt support for USB disks?

Can i do root=/dev/sda1 without any initrd image setup with this kernel?  IMO I need this to boot directly from USB instead of mtd.


BTW, i find this is the most easiest kernel upgrade procedure among all.  Thanks for your efforts  Smiley

Logged

CqCn
Full Member
***

Karma: 0
Posts: 169



View Profile
« Reply #9 on: August 19, 2009, 09:30:40 PM »

Not sure what your precise setup is, Cq, but cbxbiker61 has made it very easy to upgrade if you boot the kernel from NAND.  Essentially, you just "wget http://sheeva.with-linux.com/sheeva/README-2.6.30.5" (or whatever the latest version is), make the file executable, and then execute the README as a command.

If you boot the kernel from the SDcard, you'll have to make a few minor changes to the bash script.

(Or, do I misunderstand what you are asking?)
You got my question correctly.  I think I have seen the procedure for nand-boot-update somehwhere earlier, and it looked easy. If I take that path, then I have to rebuild my sdcard from scratch again right?  Is there is any disadvantage in leaving the nand as it was after my Alpha-6 upgrade, and just do the sdcard update only from now on?  Is there a detailed howto for that somewhere?  Thanks.
Logged

Cordially, CqCn

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #10 on: August 19, 2009, 09:53:27 PM »

No, I don't think you'd need to rebuild your sdcard again, at least for the point releases.  I've not had to rebuild mine.

Remember, the original Linux was 2.6.22, and built with Marvell-specific patches.  The kernels that cbxbiker61 are providing are all 2.6.30 kernels.

You would need to make sure you are running on your SDcard when you apply the upgrade, because you'll want it to apply the /lib/modules data to the sdcard.  And you should be aware that if you update the kernel on NAND, but the root fs on the sdcard, then the root fs on the NAND will be out of date.  And, frankly, I'd ask myself if I actually needed the newest kernel.  Depending on what you are using your Plug for, an older one may run just fine.

For me, I set up my Plug to boot from the SDcard and use it for the root fs.  I've retained the NAND with the original alpha-6 kernel and root fs for emergencies.  Another reason for booting off the SDcard is that if the new kernel introduces a problem, I can flip back to the older kernel quite easily (provided the new kernel will boot!).

Also, bear in mind that Ubuntu is also updating their packages regularly, and an occasional "apt-get upgrade" will keep the packages you have loaded up-to-date.  (You can do an "apt-get -s upgrade" to see what is out of date.)  But I'd make a backup before doing this, as nothing is guaranteed!

As with everything here, it is likely you'll have to modify some of what I say to suit your own purposes.  Good luck!
Logged

Deviant0ne
Newbie
*

Karma: 0
Posts: 30



View Profile
« Reply #11 on: August 21, 2009, 06:12:15 AM »

IPSec == impossible? I would be interested in building a custom kernel based on 2.6.30.5 with IPSec if someone could point me in the right direction...
Logged

iambvk
Newbie
*

Karma: 0
Posts: 13


View Profile
« Reply #12 on: August 22, 2009, 09:26:08 AM »

Does this 2.6.30.5 kernel has inbuilt support for USB disks?

Can i do root=/dev/sda1 without any initrd image setup with this kernel?  IMO I need this to boot directly from USB instead of mtd.


BTW, i find this is the most easiest kernel upgrade procedure among all.  Thanks for your efforts  Smiley




OK, i got it working with root=/dev/sda1 by adding rootdelay=10 to the command line  Smiley
Logged

CqCn
Full Member
***

Karma: 0
Posts: 169



View Profile
« Reply #13 on: August 22, 2009, 10:14:50 AM »

OK, i got it working with root=/dev/sda1 by adding rootdelay=10 to the command line  Smiley
What was your exact full command line, for future easy reference?
Logged

Cordially, CqCn

iambvk
Newbie
*

Karma: 0
Posts: 13


View Profile
« Reply #14 on: August 22, 2009, 07:03:57 PM »

What was your exact full command line, for future easy reference?

rootfstype=jffs2 console=ttyS0,115200 mtdparts=orion_nand:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) root=/dev/mtdblock1 rw rootfstype=ext3 rootdelay=10 root=/dev/sda1 rw


some keys are repeated in the command line because, i used "setenv bootargs $(bootargs) rootfstype=ext3 rootdelay=10 root=/dev/sda1 rw", which is kind of recursive definition, but easier on eyes Smiley  Only last key=value pair seems to be considered by the kernel, which is what i wanted.


Logged

Pages: [1] 2
Print
Jump to: