Linode Forum
Linode Community Forums
 FAQFAQ    SearchSearch    MembersMembers      Register Register 
 LoginLogin [ Anonymous ] 
Post new topic  Reply to topic
Author Message
 Post subject: Updated kernel source?
PostPosted: Wed Oct 05, 2011 5:55 pm 
Offline
Newbie

Joined: Mon Feb 15, 2010 6:42 pm
Posts: 4
Website: http://www.kormoc.com
AOL: kormoc
Location: Seattle, WA
Hey guys,

The kernel source hosted at:
http://linode.com/src/
is year out of date and a major version behind. Can we get updated source?

Thanks!


Top
   
 Post subject:
PostPosted: Wed Oct 05, 2011 5:59 pm 
Offline
Linode Staff
User avatar

Joined: Tue Apr 15, 2003 6:24 pm
Posts: 3090
Website: http://www.linode.com/
Location: Galloway, NJ
Our kernels are built straight from mainline now, so there is no need to supply the source.

You can grab the .config from zcat /proc/config.gz

-Chris


Top
   
 Post subject:
PostPosted: Wed Oct 05, 2011 6:03 pm 
Offline
Newbie

Joined: Mon Feb 15, 2010 6:42 pm
Posts: 4
Website: http://www.kormoc.com
AOL: kormoc
Location: Seattle, WA
Ahh! Glad to hear it. Thanks much for the quick reply!


Top
   
 Post subject:
PostPosted: Wed Oct 05, 2011 7:48 pm 
Offline
Senior Member
User avatar

Joined: Thu Jun 16, 2011 8:24 am
Posts: 412
Location: Cyberspace
caker wrote:
Our kernels are built straight from mainline now, so there is no need to supply the source.

You can grab the .config from zcat /proc/config.gz

-Chris


I'd recommend putting a readme file stating this along with a link to the kernel.org download page. The GPLv2 requires that you either provide the source code, or tell people where to get the source code (and provide any relevent patches if you modify the code). If Linode isn't going to be hosting the kernel source, providing a link to the kernel.org download page in a place that is obvious (putting it in linode.com/src should be fine) is good enough as per the GPLv2.

(edited to correct a sentence)

_________________
Kris the Piki Geeker


Top
   
 Post subject:
PostPosted: Wed Oct 05, 2011 8:46 pm 
Offline
Linode Staff
User avatar

Joined: Tue Apr 15, 2003 6:24 pm
Posts: 3090
Website: http://www.linode.com/
Location: Galloway, NJ
I believe the GPL states that since we're not distributing the kernel we do not need to publish the source code.

I'll add a note to the index.

-Chris


Top
   
 Post subject:
PostPosted: Wed Oct 05, 2011 9:00 pm 
Offline
Senior Member
User avatar

Joined: Thu Jun 16, 2011 8:24 am
Posts: 412
Location: Cyberspace
I think providing a Linode-compiled kernel counts as distribution. Since the Linode-compiled kernel is used by default when us users deploy our Linodes, the kernel is effectively being distributed to us, and we can easily setup an rsync, ftp, etc. to copy it to our local computers. I know this isn't the intent, but there's nothing stopping us from doing that.

It's possible I passed over a loophole in the GPLv2, but I doubt it.

_________________
Kris the Piki Geeker


Top
   
 Post subject:
PostPosted: Wed Oct 05, 2011 9:05 pm 
Offline
Linode Staff
User avatar

Joined: Tue Apr 15, 2003 6:24 pm
Posts: 3090
Website: http://www.linode.com/
Location: Galloway, NJ
You actually don't have access to the kernel binary - it's stored on the host machine.

-Chris


Top
   
 Post subject:
PostPosted: Wed Oct 05, 2011 9:55 pm 
Offline
Senior Member
User avatar

Joined: Thu Jun 16, 2011 8:24 am
Posts: 412
Location: Cyberspace
Never heard of the kernel operating outside the VM. But that brings up a question: are the kernel modules stored inside the VM, or on the host machine? If it's in the VM, you still need to provide the code to the kernel since most of the modules will come with the kernel, as well as any other modules used by Linode (as per the licensing of those modules).

If the kernel and all kernel-related binaries are stored on and loaded from the physical host such that we users have no access outside of modprobe/rmmod, then there is no obligation to Linode to provide a way to obtain the source since that isn't covered by the GPL. I'd still recommended posting the link in the linode.com/src (including a note that the kernel is on the physical host as opposed to the VM), but legally, there's no obligation to do so in this situation.

_________________
Kris the Piki Geeker


Top
   
 Post subject:
PostPosted: Wed Oct 05, 2011 10:22 pm 
Offline
Senior Member
User avatar

Joined: Sat Aug 30, 2008 1:55 pm
Posts: 1739
Location: Rochester, New York
There are no kernel modules provided by Linode.


Top
   
 Post subject:
PostPosted: Wed Oct 05, 2011 10:27 pm 
Offline
Senior Member
User avatar

Joined: Thu Jun 16, 2011 8:24 am
Posts: 412
Location: Cyberspace
Ok, so Linode isn't in trouble for grand theft of the Linux kernel :lol:

This would honestly be my first experience with a kernel that isn't directly run from inside the kernel. Hence my thinking that the link to the source was needed. I'm sure a lot of other new comers would be thinking the same thing, too, so putting this somewhere (the two places I can think of are in the features list or in the general description) would help clear up the confusion.

_________________
Kris the Piki Geeker


Top
   
 Post subject: Re:
PostPosted: Sun Oct 21, 2012 4:34 pm 
Offline
Junior Member

Joined: Sun Oct 21, 2012 4:00 pm
Posts: 28
This actually breaks things for gentoo, and possibly other linux distributions as well:

According to the Official Gentoo Kernel install specifications / guide:

"Gentoo requires that the /usr/src/linux symbolic link points to the sources of the kernel you are running."

As you can see, this causes problems:

gentoo running: sudo emerge world --update wrote:
* Messages for package sys-fs/udev-171-r8:

* Unable to find kernel sources at /usr/src/linux
* Unable to calculate Linux Kernel version for build, attempting to use running version
* CONFIG_SYSFS_DEPRECATED: should not be set. But it is.
* CONFIG_BLK_DEV_BSG: is not set when it should be.
* Please check to make sure these options are set correctly.
* Failure to do so may cause unexpected problems.
*
* udev-171 does not support Linux kernel before version 2.6.32!
*
* You need to add udev-mount to the sysinit runlevel.
* If you do not do this,
* your system will not be able to boot!
* Run this command:
* rc-update add udev-mount sysinit
*
* persistent-net does assigning fixed names to network devices.
* If you have problems with the persistent-net rules,
* just delete the rules file
* rm /etc/udev/rules.d/70-persistent-net.rules
* and then reboot.
*
* This may however number your devices in a different way than they are now.
*
* If you build an initramfs including udev, then please
* make sure that the /sbin/udevadm binary gets included,
* and your scripts changed to use it,as it replaces the
* old helper apps udevinfo, udevtrigger, ...
*
* mount options for directory /dev are no longer
* set in /etc/udev/udev.conf, but in /etc/fstab
* as for other directories.
*
* If you use /dev/md/*, /dev/loop/* or /dev/rd/*,
* then please migrate over to using the device names
* /dev/md*, /dev/loop* and /dev/ram*.
* The devfs-compat rules have been removed.
* For reference see Bug #269359.
*
* Rules for /dev/hd* devices have been removed
* Please migrate to libata.
*
* For more information on udev on Gentoo, writing udev rules, and
* fixing known issues visit:
* http://www.gentoo.org/doc/en/udev-guide.xml






I could actually workaround if the kernel was more recent. For instance:

Currently available "mainline linux.org" kernels for gentoo-type distributions.

If it was one of those, let's say 3.6.2, I could simply do this:

Code:
$ echo =sys-kernel/vanilla-sources-3.6.2 symlink >> /etc/portage/package.use
$ echo =sys-kernel/vanilla-sources-3.6.2 ~x86 >> /etc/portage/package.accept_keywords
$ emerge =sys-kernel/vanilla-sources-3.6.2


Unfortunately, 3.5.2 is old enough to not be treated by the most common gentoo-type distributions as being acceptable.

sys-kernel/vanilla-sources-3.3.8 would be acceptable though. I wouldn't even need to use an accept_keywords bypass flag to permit testing / unstable packages.

This has been going on for a while now:

Similar post from gentoo's forums in 2011


Top
   
 Post subject: Re: Re:
PostPosted: Mon Oct 22, 2012 3:54 am 
Offline
Senior Member

Joined: Sun Mar 07, 2010 7:47 pm
Posts: 1970
Website: http://www.rwky.net
Location: Earth
kuzetsa wrote:
This actually breaks things for gentoo, and possibly other linux distributions as well


Use pv_grub instead and run your distro's kernel if you have problems.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue


Top
   
 Post subject: Re: Re:
PostPosted: Tue Oct 23, 2012 2:14 pm 
Offline
Junior Member

Joined: Sun Oct 21, 2012 4:00 pm
Posts: 28
obs wrote:
kuzetsa wrote:
This actually breaks things for gentoo, and possibly other linux distributions as well


Use pv_grub instead and run your distro's kernel if you have problems.


Indeed, that is the workaround I'm currently exploring:

Main delay is due to the impact analysis I'm doing on the subject.

Switching from Fully Virtualized (HVM) to para-virtualized (PV) kernel on xen will impact the clocksources available for my linode, as well as use of the "independent_wallclock" setting

mainly:

Code:
echo 1 > /proc/sys/xen/independent_wallclock


and making it stick with:

Quote:
echo "xen.independent_wallclock = 1" >> /etc/sysctl.conf


or, depending on the distro running on a linode / xen instance:

Code:
echo "echo 1 > /proc/sys/xen/independent_wallclock" >> /etc/conf.d/local.start 


This applies to PV but not HVM... After the impact analysis for my linode is completed, I'll be testing this all out, and updating documentation on gentoo and/or linode wiki. The difference in needing independent_wallclock toggled or not will be important for my use, as the affected linode operates as an NTP peer for ... whatever I'm using it for (irrelevant in this case)

---

Outdated info (doesn't make distinction between HVM, and the PV xen instances) for NTP on linode... If it hasn't been updated by the time I'm done with kernel migration / upgrade, I'll likely update this:

http://www.linode.com/wiki/index.php/NTP

Also of note, this page references the "yum" package manager exclusively (among other distribution-specific sections)


Top
   
PostPosted: Tue Oct 23, 2012 4:09 pm 
Offline
Senior Member
User avatar

Joined: Sat Aug 30, 2008 1:55 pm
Posts: 1739
Location: Rochester, New York
The good news is that you aren't running a HVM kernel right now, as Linode only does PV. The independent_wallclock setting is not a part of the Xen support in the mainline kernel, either; guests are expected to maintain their own clock. You should be OK, particularly if you build from the existing /proc/config.gz.

_________________
Code:
/* TODO: need to add signature to posts */


Top
   
PostPosted: Wed Oct 24, 2012 5:08 pm 
Offline
Junior Member

Joined: Sun Oct 21, 2012 4:00 pm
Posts: 28
hoopycat wrote:
The good news is that you aren't running a HVM kernel right now, as Linode only does PV. The independent_wallclock setting is not a part of the Xen support in the mainline kernel, either; guests are expected to maintain their own clock. You should be OK, particularly if you build from the existing /proc/config.gz.


Ah, ok. thanks.

I had simply (erroneously) inferred that I was using HVM kernel based on this information:

http://www.vr.org/kb/161/My-server-clock-or-date-and-time-is-wrong-or-drifts.html

I was mistaken though. Hadn't thought I was running a PV-type kernel because at first, I had erroneously presumed that because the "pvgrub" wasn't installed under my domu instance, it must just be using a different type of kernel. Today however, finally got done reading up on the subject and found out it will be in the dom0 / host, and I don't need to do anything special.

So now that I know what all I'm looking at, I'm quite close to simply building a kernel which gentoo will fully considers as being kosher. Rather happy to know that things don't break too badly for the multiple packages which are expecting to be able to inspect or otherwise use the kernel source during their own build process.

Pretty sure that I want to use a 3.6.x (latest LTS branch) kernel so I'll just compare the /proc/config.gz under my linode-supplied 3.5.x kernel against a 3.6.x config from my own preferences.

... And then I figure just need to (more or less) drop my menu.lst, kernel, etc. in /boot/ after installing grub as normal, and click on any relevant setting(s) in the linode manager before rebooting?


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
RSS

Powered by phpBB® Forum Software © phpBB Group