• Home
  • Help
  • Search
  • Login
  • Register
Pages: 1 [2]
Author Topic: 2.6.30.5 new release  (Read 8260 times)
CqCn
Full Member
***

Karma: 0
Posts: 169



View Profile
« Reply #15 on: August 23, 2009, 03:27:36 PM »

Though it may not matter, since it works for you, most of the old part of the env line is not needed.  Your env could be just:
console=ttyS0,115200 rootfstype=ext3 rootdelay=10 root=/dev/sda1 rw
Logged

Cordially, CqCn

CqCn
Full Member
***

Karma: 0
Posts: 169



View Profile
« Reply #16 on: August 24, 2009, 11:55:40 AM »

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!
restamp,  I believe my setup is as you describe yours.  With your encouragement and help, I have done the alpha-rc6 upgrade, moved the root to the sdcard, and finally have redone all the customizations I had done previously [ on my out of the box w/ sdcard rootfs].  Than you!

I have apt installed a few more; and have done the apt-get upgrade.  It took a while, but I am there. Hopefully I can do incrementally from here for a long time; with full sdcard backups.

So I must have the alpha-rc6 kernel on the nand, and the updated ubuntu on my external SDCard -- is that the correct terminology?

Now I need a couple of clarifications. It seems from the above, you have also copied the kernal from the nand to your sdcard (I assume to a new small boot partion at the beginning of your 16G SDcard.).  Correct?  So with that, when running from SDCard rootfs, if you upgrade the kernel as esribed in the quick upgrade process, the SDCard would be upgraded, leaving he nand one the old one?  Is that what you have done?  Or you have not upgraded to the .5 or .6 kernel at all?  I prefer to follow the setup of somebody like you who is trail blazing, so I have something precise to compare against should I run into problems in the future.

Or, are you suggesting, I simply don't have anything to do anymore, but just continue customization and development to go to a small production server?

I like the idea of the kernel also on the SDCard, in that I can make some minor setups (customizations, such as the server name change) on the SDCard, without touching the nand at all.  I know in my current setup 100's of files are modified on the nand -- I do not how often-- , after a week+ multiple reboots after moving the rootfs to the SDCard.  I am assuming even those writes would be minimized if the kernel is also modified, correct?

Also,with the kernel+rootfs on SDCard, I have real full backups of everything I would be ever modifying during experimentation and customization.  Clarifications from you are most welcome! 
Logged

Cordially, CqCn

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #17 on: August 24, 2009, 03:04:43 PM »

So I must have the alpha-rc6 kernel on the nand, and the updated ubuntu on my external SDCard -- is that the correct terminology?
I think so.
Quote
Now I need a couple of clarifications. It seems from the above, you have also copied the kernal from the nand to your sdcard (I assume to a new small boot partion at the beginning of your 16G SDcard.).  Correct?  So with that, when running from SDCard rootfs, if you upgrade the kernel as esribed in the quick upgrade process, the SDCard would be upgraded, leaving he nand one the old one?  Is that what you have done?  Or you have not upgraded to the .5 or .6 kernel at all?  I prefer to follow the setup of somebody like you who is trail blazing, so I have something precise to compare against should I run into problems in the future.
Essentially correct.  First, I didn't copy the rc6 kernel; I just booted from NAND until upgrading to one of cbxbiker61's kernels.  When I did that, I altered his install script to install the kernel on my root fs (and bypassed his NAND writes) and changed my Uboot parameters to boot from the SDcard.  Also, I don't use a separate boot partition.  The alpha-6's Uboot can (with some glitches, which are manageable once you understand them) boot a kernel from an ext2 fs, so I just put the Uimage on my root fs.  (I'm certainly not trail-blazing here; I'm just pulling together some tidbits that others have previously published here.)
Quote
I like the idea of the kernel also on the SDCard, in that I can make some minor setups (customizations, such as the server name change) on the SDCard, without touching the nand at all.  I know in my current setup 100's of files are modified on the nand -- I do not how often-- after a week+ multiple reboots after moving the rootfs to the SDCard.  I am assuming even those writes would be minimized if the kernel is also modified, correct?
In the mode I currently run my Plug, the NAND is essentially unused.  Zero reads and zero writes, with the exception of reading the Uboot and its environment on each boot.  For me, the NAND exists only as a backup boot device.

BTW, you can find out how much read/write activity your Plug is generating with:
Code:
$ cat /proc/diskstats
...
  31       0 mtdblock0 0 0 0 0 0 0 0 0 0 0 0
  31       1 mtdblock1 0 0 0 0 0 0 0 0 0 0 0
 179       0 mmcblk0 2849 1034 113622 14440 12402 3391 150528 5305040 0 1381360 5320740
 179       1 mmcblk0p1 2794 206 111436 14210 12402 3391 150528 5305040 0 1381330 5320510
 179       2 mmcblk0p2 13 258 542 60 0 0 0 0 0 40 60
 179       3 mmcblk0p3 28 515 1092 130 0 0 0 0 0 80 130
The above are what I just got from my Plug.  Note that the NAND devices (mtdblock0 and 1) are all zero.  My root fs is mmcblk0p1.  It shows 2794 reads and 12402 writes since my Plug was last booted.  My plug has been booted for 8.25 days, so I've been averaging 1500 root fs disk writes/day, or a little over one write per minute, which is quite typical of what I've seen for a largely quiescent Plug.

Hope this answers your questions.
Logged

CqCn
Full Member
***

Karma: 0
Posts: 169



View Profile
« Reply #18 on: August 24, 2009, 04:09:43 PM »

resrtamp,
Mine, rebooted in the last hour, shows:
Code:
  31       0 mtdblock0 0 0 0 0 0 0 0 0 0 0 0
  31       1 mtdblock1 0 0 0 0 0 0 0 0 0 0 0
 179       0 mmcblk0 1501 150 56372 10530 168 41 1808 161970 0 28830 172500
 179       1 mmcblk0p1 1491 140 56212 10520 168 41 1808 161970 0 28820 172490
   8       0 sda 52 1159 2170 200 0 0 0 0 0 110 200
   8       1 sda1 47 1139 1970 180 0 0 0 0 0 110 180
  Since I have the kernel still in the NAND, I wonder if the first two lines are really valid!  Perhaps this is after the kernel boot is completed, so the initial read/writes to the kernel is not shown ?
Logged

Cordially, CqCn

CqCn
Full Member
***

Karma: 0
Posts: 169



View Profile
« Reply #19 on: August 24, 2009, 04:51:30 PM »

Quote
Also, I don't use a separate boot partition.  The alpha-6's Uboot can (with some glitches, which are manageable once you understand them) boot a kernel from an ext2 fs, so I just put the Uimage on my root fs.
restamp, I like this even better than the method I thouhght I would do below.  Is there any downside to this for future upgrades of the kernel?  Is there a howto with specifics at a Wiki?  The info may be distributed in many posts across may threads...  If not already there, may I suggest a Wiki page please?
Logged

Cordially, CqCn

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #20 on: August 24, 2009, 10:27:36 PM »

With regard to your first post, you are correct:  The kernel is read into memory by the Uboot (it can't read itself in), so these accesses would not be indicated by the /proc/diskstats entry.

With respect to your last post, it's been covered, more or less, in the forum here.  Take a look at:  http://plugcomputer.org/plugforum/index.php?topic=183.msg3467#msg3467
Logged

CqCn
Full Member
***

Karma: 0
Posts: 169



View Profile
« Reply #21 on: August 26, 2009, 03:36:22 PM »

With regard to your first post, you are correct:  The kernel is read into memory by the Uboot (it can't read itself in), so these accesses would not be indicated by the /proc/diskstats entry.
restamp, One way to get that part of the info is to use rsync in the -n mode (nochange, but compare), against another SDCard you had backed up at somepoint.  It will tell files that were modified.
Logged

Cordially, CqCn

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #22 on: August 26, 2009, 07:50:27 PM »

The rsync program is quite useful for many purposes -- I use it regularly -- but I don't see the the correlation to /proc/diskstats.  The latter gives you some indication of how hard you are hitting our SDcard.  You really don't need to know where you are hitting it for this purpose.

Bear in mind that, for all intents and purposes, the Uboot reading the kernel into memory does not stress the NAND -- either on the Plug or on the SDcard, depending on the source -- at all:  First, it is a read operation, not a write, and in any event, the additional i/o associated with this infrequent operation is hardly worth taking into account.
« Last Edit: August 26, 2009, 07:53:23 PM by restamp » Logged

CqCn
Full Member
***

Karma: 0
Posts: 169



View Profile
« Reply #23 on: August 26, 2009, 08:30:35 PM »

restamp,  I agree with everything you say.  But we know /proc/distats erase whatever might happen before the current boot, including the uboot related, if any.  While rsync does not give anywhere near the amount of relevant info for this purpose, it still provide more than 0! By comparing the Nand to a copy on an SDCard, which not used afterwards, after many reboots when compared gives an idea of how many files are getting changed on the Nand system.  I agree that the destructive effective may be trivially small.
Logged

Cordially, CqCn

jwilker2
Newbie
*

Karma: 0
Posts: 2


View Profile
« Reply #24 on: August 28, 2009, 10:30:35 AM »

Hello,

First of all I'd like to thank you all for the contribution of time and grey-matter required to make and distribute 2.6.30.+...

I've been successful at installing  2.6.30.5 onto MMC and USB stick etc. with lots of help from cbxbiker61's instructions.

What I'd like to know is where one might obtain the linux headers for 2.6.30.5? apt-get install linux-headers-2.6.30.5 etc. have failed to locate them. I was wondering if perhaps I was missing something in sources.list or some other obvious place on the net :0).

Any input would be appreciated
Logged

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #25 on: August 28, 2009, 12:46:21 PM »

For convenience I've added sheeva-2.6.30.5-KernelHeaders.tar.gz at http://sheeva.with-linux.com/sheeva/2.6.30.5.  Just untar it in the root directory and you'll be good to go.
Logged

jwilker2
Newbie
*

Karma: 0
Posts: 2


View Profile
« Reply #26 on: August 28, 2009, 01:28:35 PM »

Superb! Thanks again for all the time and the effort...
Logged

calamari
Newbie
*

Karma: 0
Posts: 23


View Profile
« Reply #27 on: August 30, 2009, 06:56:44 AM »

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.

With 2.6.31 it seems to work again, also see the post here.
Logged

riel
Newbie
*

Karma: -2
Posts: 22


View Profile
« Reply #28 on: September 03, 2009, 02:56:14 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...

Don't know if it's of any help but pptp just works, only thing is this kernel is not having MPPE encryption so you should disable it.
Logged

Pages: 1 [2]
Print
Jump to: