Re: having high cpu problem related to kernel version
I found that this is a bug of kernel module "rtl8723ae" and it also happens on kernel 5.10 i wasn't able to pin it out because i updated packages right after i installed it i was able to find related thread on askubuntu https://askubuntu.com/questions/846830/irq-from-realtek-wifi-are-loading-cpu typed `modprobe -r rtl8723ae` and cpu gone back to normal i wasn't able to find any solution to this this one, i guess https://github.com/torvalds/linux/tree/master/drivers/net/wireless/realtek/rtlwifi/rtl8723ae 2022년 1월 3일 (월) 오전 3:29, Nicholas Geovanis 님이 작성: > > > On Fri, Dec 31, 2021, 4:27 PM _ djdisodo wrote: > >> note that i'm using debian sid and xfce4 >> >> it shows full of red bars on htop on one of the core between two(i >> have atom n455 cpu) >> iirc red bars means kernel threads >> >> i've tested using debian's boot menu so only thing changed is kernel >> version >> it was fine on kernel 5.10 it's happening on kernel 5.14 and 5.15 >> >> i don't know exactly how to represent, but it isn't hard to if i just >> do something like browsing or reading pdf it just starts to happen and >> never stops even after i close all apps or log out >> >> https://asciinema.org/a/xTXqyZhg06enfrcHbuhasGJrm >> https://asciinema.org/a/y0klCFDWSOsjjAQTUHlHM84mq >> >> 1st link is when it's fine(right after boot) >> >> 2nd link is when it happens >> >> there is no difference on application running between two >> >> xserver is unrelated it's high cpu usage is just because of more >> updates on htop screen >> > > And I think to get a better reading of the system state, you have to > reduce the frequency of htop updates. Say down to every 3 or 4 secs to > start. > > I don't see what you see in the video recordings you stored. Maybe because > the top of the screen image you recorded seems to get corrupted towards the > end of the video. But htop itself is taking 15% of a CPU by then. > > >> if i watch htop on ctrl+alt+f1 terminal xserver isn't even on the >> first page but htop still shows high cpu usage >> >> https://asciinema.org/a/l81ZO3hSHbA4jLm6fwLlIrfUS >> recorded on ctrl+alt+f1 terminal >> ran htop as root and enabled to show kernel threads >> tho cpu usage of kernel threads aren't being displayed >> >>
Re: having high cpu problem related to kernel version
On Fri, Dec 31, 2021, 4:27 PM _ djdisodo wrote: > note that i'm using debian sid and xfce4 > > it shows full of red bars on htop on one of the core between two(i > have atom n455 cpu) > iirc red bars means kernel threads > > i've tested using debian's boot menu so only thing changed is kernel > version > it was fine on kernel 5.10 it's happening on kernel 5.14 and 5.15 > > i don't know exactly how to represent, but it isn't hard to if i just > do something like browsing or reading pdf it just starts to happen and > never stops even after i close all apps or log out > > https://asciinema.org/a/xTXqyZhg06enfrcHbuhasGJrm > https://asciinema.org/a/y0klCFDWSOsjjAQTUHlHM84mq > > 1st link is when it's fine(right after boot) > > 2nd link is when it happens > > there is no difference on application running between two > > xserver is unrelated it's high cpu usage is just because of more > updates on htop screen > And I think to get a better reading of the system state, you have to reduce the frequency of htop updates. Say down to every 3 or 4 secs to start. I don't see what you see in the video recordings you stored. Maybe because the top of the screen image you recorded seems to get corrupted towards the end of the video. But htop itself is taking 15% of a CPU by then. > if i watch htop on ctrl+alt+f1 terminal xserver isn't even on the > first page but htop still shows high cpu usage > > https://asciinema.org/a/l81ZO3hSHbA4jLm6fwLlIrfUS > recorded on ctrl+alt+f1 terminal > ran htop as root and enabled to show kernel threads > tho cpu usage of kernel threads aren't being displayed > >
having high cpu problem related to kernel version
note that i'm using debian sid and xfce4 it shows full of red bars on htop on one of the core between two(i have atom n455 cpu) iirc red bars means kernel threads i've tested using debian's boot menu so only thing changed is kernel version it was fine on kernel 5.10 it's happening on kernel 5.14 and 5.15 i don't know exactly how to represent, but it isn't hard to if i just do something like browsing or reading pdf it just starts to happen and never stops even after i close all apps or log out https://asciinema.org/a/xTXqyZhg06enfrcHbuhasGJrm https://asciinema.org/a/y0klCFDWSOsjjAQTUHlHM84mq 1st link is when it's fine(right after boot) 2nd link is when it happens there is no difference on application running between two xserver is unrelated it's high cpu usage is just because of more updates on htop screen if i watch htop on ctrl+alt+f1 terminal xserver isn't even on the first page but htop still shows high cpu usage https://asciinema.org/a/l81ZO3hSHbA4jLm6fwLlIrfUS recorded on ctrl+alt+f1 terminal ran htop as root and enabled to show kernel threads tho cpu usage of kernel threads aren't being displayed
Re: 64bit ext4 and kernel version compatibility
On 1/9/20 2:02 AM, Klaus Singvogel wrote: R. Ramesh wrote: I want to make sure that my current kernel version does not have any limitation to support 64bit ext4. Please consult the Kernel Wiki regarding Ext4: https://ext4.wiki.kernel.org/index.php/Main_Page You will notice that Linux 2.6.28 was the first suppored kernel with ext4, which was released a quiet long time ago (around 2009). As your distribution is running 3.13.0-132-generic, the support of ext4 should be no problem (never tested it to be 100% sure). Another important information I was missing of: the machine architecture of your processor; whether you're running a 64bit kernel or 32bit kernel. "uname -m" will tell you, if you have 64bit, like in "x86_64", or not. I'm very unsure, if your processor is able to address such files. PAE extension (32 bit) of Intel architecture supports it, but not sure about other archs, like Raspberry Pi v1 has. Nevertheless, I stronlgy recommend to upgrade to 16.04 LTS or better, if this machine connects or is connectable from the internet, due to security reasons. Regards, Klaus. Klaus, Thanks for your help. The last time I tried to upgrade to 16.04, my mythtv broke. I am sure I made some mistakes. I will ry once 20.04 is released to do a fresh install rather than upgrade from 14.04. That way I will manually install mythtv and do a database backup and restore. I have been lazy and not doing it right. This time I will be more thorough. May be I should delay 64bit conversion until then. Let me see, if I can manage delaying it till summer. Regards Ramesh
Re: Re: 64bit ext4 and kernel version compatibility
On Thu, Jan 09, 2020 at 05:06:29PM +, Tixy wrote: > On Thu, 2020-01-09 at 14:35 +0300, Reco wrote: > > On Wed, Jan 08, 2020 at 06:08:16PM -0600, R. Ramesh wrote: > > > Before I get the source and build and update e2fsprogs and then the > > > file system, I want to make sure that my current kernel version does > > > not have any limitation to support 64bit ext4. > > > > You kernel should support the feature, as it was introduced back at the > > version 3.6 of the kernel - [1]. > > > > [1] https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums > > That web page is talking about metadata checksums I can't see anything > about '64-bit'. Let me read it for you (note kernel version): Install Linux 3.6+ and e2fsprogs 1.43-WIP. modprobe crc32c-intel mkfs.ext4 -O metadata_csum,64bit /dev/path/to/disk To enable "metadata_csum" in its full glory one needs to enable "64bit" fs feature: In a perfect world, one could simply enable metadata checksums ... Therefore, it is best to start by formatting a fresh filesystem with 64-bit support enabled ... >What I'm assuming the OP is interested is 64-bit block numbers because >they said they want to "convert ext4 fs on this server to 64bit so that >I can grow it past 16TB limit". Note from me, 4kB sized blocks * 2^32 = >16TB, so block numbers whould need to be more than 32-bit for bigger >drives. Same page says: Therefore, it is best to start by formatting a fresh filesystem with 64-bit support enabled, since it is not possible to upgrade a 32-bit filesystem to a 64-bit filesystem. So if "convert" = "mkfs", then OP is fully set. But then again, it's nothing that can't be solved by pre-existing backup. Reco Reco, Thanks for the details. I do not know why, for a moment I thought 3.6 > 3.13 (must have been treating version numbers as floating point numbers :-) No I do not plan to convert/grow in place. I have 2x8tb disks (and several other 4TB disks) for making backup. I will back up each md that is less than 16TB (separately) and make them 64bit first. After that I will grow them as needed. Regards Ramesh
Re: 64bit ext4 and kernel version compatibility
On Thu, Jan 09, 2020 at 05:06:29PM +, Tixy wrote: > On Thu, 2020-01-09 at 14:35 +0300, Reco wrote: > > On Wed, Jan 08, 2020 at 06:08:16PM -0600, R. Ramesh wrote: > > > Before I get the source and build and update e2fsprogs and then the > > > file system, I want to make sure that my current kernel version does > > > not have any limitation to support 64bit ext4. > > > > You kernel should support the feature, as it was introduced back at the > > version 3.6 of the kernel - [1]. > > > > [1] https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums > > That web page is talking about metadata checksums I can't see anything > about '64-bit'. Let me read it for you (note kernel version): Install Linux 3.6+ and e2fsprogs 1.43-WIP. modprobe crc32c-intel mkfs.ext4 -O metadata_csum,64bit /dev/path/to/disk To enable "metadata_csum" in its full glory one needs to enable "64bit" fs feature: In a perfect world, one could simply enable metadata checksums ... Therefore, it is best to start by formatting a fresh filesystem with 64-bit support enabled ... >What I'm assuming the OP is interested is 64-bit block numbers because >they said they want to "convert ext4 fs on this server to 64bit so that >I can grow it past 16TB limit". Note from me, 4kB sized blocks * 2^32 = >16TB, so block numbers whould need to be more than 32-bit for bigger >drives. Same page says: Therefore, it is best to start by formatting a fresh filesystem with 64-bit support enabled, since it is not possible to upgrade a 32-bit filesystem to a 64-bit filesystem. So if "convert" = "mkfs", then OP is fully set. But then again, it's nothing that can't be solved by pre-existing backup. Reco
Re: 64bit ext4 and kernel version compatibility
On Thu, 2020-01-09 at 14:35 +0300, Reco wrote: > On Wed, Jan 08, 2020 at 06:08:16PM -0600, R. Ramesh wrote: > > Before I get the source and build and update e2fsprogs and then the > > file system, I want to make sure that my current kernel version does > > not have any limitation to support 64bit ext4. > > You kernel should support the feature, as it was introduced back at the > version 3.6 of the kernel - [1]. > > Reco > > [1] https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums That web page is talking about metadata checksums I can't see anything about '64-bit'. What I'm assuming the OP is interested is 64-bit block numbers because they said they want to "convert ext4 fs on this server to 64bit so that I can grow it past 16TB limit". Note from me, 4kB sized blocks * 2^32 = 16TB, so block numbers whould need to be more than 32-bit for bigger drives. -- Tixy
Re: 64bit ext4 and kernel version compatibility
Hi. On Wed, Jan 08, 2020 at 06:08:16PM -0600, R. Ramesh wrote: > Before I get the source and build and update e2fsprogs and then the > file system, I want to make sure that my current kernel version does > not have any limitation to support 64bit ext4. You kernel should support the feature, as it was introduced back at the version 3.6 of the kernel - [1]. Reco [1] https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
Re: 64bit ext4 and kernel version compatibility
On Thu, 2020-01-09 at 09:02 +0100, Klaus Singvogel wrote: > R. Ramesh wrote: > > I want to make sure > > that my current kernel version does not have any limitation to support 64bit > > ext4. > > Please consult the Kernel Wiki regarding Ext4: > > https://ext4.wiki.kernel.org/index.php/Main_Page > > You will notice that Linux 2.6.28 was the first suppored kernel with ext4, > which was released a quiet long time ago (around 2009). As your > distribution is running 3.13.0-132-generic, the support of ext4 should be > no problem (never tested it to be 100% sure). But features keep getting added to filesystems as time goes by and it's quite possible that support for 64-bit block numbers wasn't included from the start. The man page for e2fsprogs says this about the '64bit' option: "Note that some older kernels and older versions of e2fsprogs will not support file systems with this ext4 feature enabled" -- Tixy
Re: 64bit ext4 and kernel version compatibility
R. Ramesh wrote: > I want to make sure > that my current kernel version does not have any limitation to support 64bit > ext4. Please consult the Kernel Wiki regarding Ext4: https://ext4.wiki.kernel.org/index.php/Main_Page You will notice that Linux 2.6.28 was the first suppored kernel with ext4, which was released a quiet long time ago (around 2009). As your distribution is running 3.13.0-132-generic, the support of ext4 should be no problem (never tested it to be 100% sure). Another important information I was missing of: the machine architecture of your processor; whether you're running a 64bit kernel or 32bit kernel. "uname -m" will tell you, if you have 64bit, like in "x86_64", or not. I'm very unsure, if your processor is able to address such files. PAE extension (32 bit) of Intel architecture supports it, but not sure about other archs, like Raspberry Pi v1 has. Nevertheless, I stronlgy recommend to upgrade to 16.04 LTS or better, if this machine connects or is connectable from the internet, due to security reasons. Regards, Klaus. -- Klaus Singvogel GnuPG-Key-ID: 1024R/5068792D 1994-06-27
64bit ext4 and kernel version compatibility
Hi, On my DVR, I am running fairly old version of kernel (3.13.0-132-generic, mythbuntu 14.04.5 LTS). I want to convert ext4 fs on this server to 64bit so that I can grow it past 16TB limit. At that time of installation (2014), e2fsprogs did not support 64bit fs. Now it does. Before I get the source and build and update e2fsprogs and then the file system, I want to make sure that my current kernel version does not have any limitation to support 64bit ext4. My google searches do not mention any kernel limitations. I think this is due to my inability to ask the right question to google. Appreciate any help I can get on answering my question. At this time it is difficult for me to upgrade the kernel without updating the distribution (and hence mythtv) and that path is beyond me at this time due to time constraints. Ramesh
Re: Re: Which kernel version (and sub-version) do I have?
Yes. Two of the above. You are running Debian kernel 3.16.7-ckt25-2+deb8u3 which is compatible with the kernel ABI used in Debian kernel *package* 3.16.0-4-686-pae. https://security-tracker.debian.org/tracker/CVE-2016-5195 confirms that you want 3.16.36-1+deb8u2. Thank you for your quick reply!
Re: Which kernel version (and sub-version) do I have?
On Mon, Mar 13, 2017 at 10:18:03PM +0100, Georg Stillfried wrote: > can someone please help me find out which kernel version (and > sub-version) I have? uname -a > $ uname -v > #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) > > $ uname -r > 3.16.0-4-686-pae Or that. It's the same as uname -a, just in pieces. > So is the kernel version of my system 3.16.7, 3.16.0 or 3.16.63? Yes. Two of the above. You are running Debian kernel 3.16.7-ckt25-2+deb8u3 which is compatible with the kernel ABI used in Debian kernel *package* 3.16.0-4-686-pae. > (Backgroud: I wanted to find out whether the Dirty COW bug was fixed in > my system. No, not yet. > According to > https://en.wikipedia.org/wiki/Dirty_COW#Remedies_and_recourse, it is > fixed from version 3.16.36-1+deb8u2 onwards.) You are running a kernel that is older than this. If you have installed a newer kernel, you have not yet rebooted into it. https://security-tracker.debian.org/tracker/CVE-2016-5195 confirms that you want 3.16.36-1+deb8u2. (Best not to rely 100% on wikipedia without verification.)
Which kernel version (and sub-version) do I have?
Hello, can someone please help me find out which kernel version (and sub-version) I have? Don't scould, I have done the search on Google and in the Debian documentation on how to find one's kernel version, but I am confused by the results: $ uname -v #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) $ uname -r 3.16.0-4-686-pae $ apt-cache show linux-image-686-pae Package: linux-image-686-pae Source: linux-latest (63) Version: 3.16+63 [...] So is the kernel version of my system 3.16.7, 3.16.0 or 3.16.63? (Backgroud: I wanted to find out whether the Dirty COW bug was fixed in my system. According to https://en.wikipedia.org/wiki/Dirty_COW#Remedies_and_recourse, it is fixed from version 3.16.36-1+deb8u2 onwards.) Kind greetings, Georg
Re: Defferences in kernel version and kernel release
Stefan Monnier <monn...@iro.umontreal.ca> wrote: >> This is what is called the Kernel-ABI. All modules compiled for >> "3.16.0-4-amd64" will be compatible with all kernels providing this. > I had kind of figured that out, but one thing still puzzles me: why > isn't it "3.16-4-amd64"? I mean, all those versions seem to always > have a ".0" which is unused. >From https://kernel-handbook.alioth.debian.org/ch-versions.html: , | Many programs parse the kernel version string reported by the uname | system call or command and expect to find at least 3 version components | separated by dots. For compatibility, the official kernel packages | currently add '.0' to the upstream version. ` Grüße, Sven -- Sigmentation fault. Core dumped.
Re: Defferences in kernel version and kernel release
> This is what is called the Kernel-ABI. All modules compiled for > "3.16.0-4-amd64" will be compatible with all kernels providing this. I had kind of figured that out, but one thing still puzzles me: why isn't it "3.16-4-amd64"? I mean, all those versions seem to always have a ".0" which is unused. Stefan
Re: Defferences in kernel version and kernel release
solitone <solit...@mail.com> wrote: > On Saturday, January 14, 2017 1:12:52 PM CET Sven Hartge wrote: >> This is the real kernel version. > Hi Sven, and thanks for your explanation. This means that > 3.16.36-1+deb8u2 is based on the following official version? > https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.16.36.tar.gz Yes. Plus a multitude of patches, fixes, improvements and sometimes backported code from newer Kernels. Grüße, S° -- Sigmentation fault. Core dumped.
Re: Defferences in kernel version and kernel release
On Saturday, January 14, 2017 1:12:52 PM CET Sven Hartge wrote: > > uname -v > > #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) > > This is the real kernel version. Hi Sven, and thanks for your explanation. This means that 3.16.36-1+deb8u2 is based on the following official version? https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.16.36.tar.gz
Re: Defferences in kernel version and kernel release
Thanks a lot for the clarification. Very useful info. 14 Янв 2017 г. 14:13 пользователь "Sven Hartge" <s...@svenhartge.de> написал: > Вадим Колчев <vadimkolc...@gmail.com> wrote: > > > Have up-to-date stable Jessie installation and noticed interesting thing. > > My kernel release is different from kernel-version. Is this okay? > > Yes, it is. > > > If yes, > why is this so? > > > uname -r > > 3.16.0-4-amd64 > > This is what is called the Kernel-ABI. All modules compiled for > "3.16.0-4-amd64" will be compatible with all kernels providing this. > > The kernel team aims to keep this ABI as stable as possible to avoid > the need to recompile all external modules every time a kernel is > updated. > > If the kernel changes in an incompatible way, then this string will be > changed, for example to "3.16.0-5-amd64", meaning every out-of-tree > kernel module needs to be recompiled. > > > uname -v > > #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) > > This is the real kernel version. > > S° > > -- > Sigmentation fault. Core dumped. > >
Re: Defferences in kernel version and kernel release
Вадим Колчев <vadimkolc...@gmail.com> wrote: > Have up-to-date stable Jessie installation and noticed interesting thing. > My kernel release is different from kernel-version. Is this okay? Yes, it is. > If yes, > why is this so? > uname -r > 3.16.0-4-amd64 This is what is called the Kernel-ABI. All modules compiled for "3.16.0-4-amd64" will be compatible with all kernels providing this. The kernel team aims to keep this ABI as stable as possible to avoid the need to recompile all external modules every time a kernel is updated. If the kernel changes in an incompatible way, then this string will be changed, for example to "3.16.0-5-amd64", meaning every out-of-tree kernel module needs to be recompiled. > uname -v > #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) This is the real kernel version. S° -- Sigmentation fault. Core dumped.
Defferences in kernel version and kernel release
Hi all, Have up-to-date stable Jessie installation and noticed interesting thing. My kernel release is different from kernel-version. Is this okay? If yes, why is this so? uname -r 3.16.0-4-amd64 uname -v #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) Thanks in advance. Best regards, Vadim
Jessie Kernel Version
Sorry for the newb question. I am trying to determine the kernel version of Jessie. Uname -r produces: 3.16.0-4-amd64 I have seen other references to 3.16.7 however, and I know 3.16.7 was the latest 3.16.x. Is 3.16.0-4 really the equivalent of 3.16.7? either way can someone explain to me how I would go about verifying without having to ask =).
Re: Jessie Kernel Version
Am 27.04.2015 um 15:05 schrieb Grant Albitz: Sorry for the newb question. I am trying to determine the kernel version of Jessie. Uname -r produces: 3.16.0-4-amd64 I have seen other references to 3.16.7 however, and I know 3.16.7 was the latest 3.16.x. Is 3.16.0-4 really the equivalent of 3.16.7? either way can someone explain to me how I would go about verifying without having to ask =). Have a look at /usr/share/doc/linux-image-3.16.0-4-amd64/changelog.Debian.gz to get the exact version. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
RE: Jessie Kernel Version
Thank you, this confirmed it was linux (3.16.7-ckt9-3~deb8u1) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/b54d10f9e0184999b2be7d22b2b11...@stsdcfs01.techsolllc.com
Re: Linux kernel version for Jessie
Le 27.10.2014 01:12, Santiago Vila a écrit : On Sun, Oct 26, 2014 at 10:56:19PM +0200, Georgi Naplatanov wrote: what kernel version will Jessie have when it became stable ? Is there any chance for newer version than 3.16.x (for example 3.17.x, 3.18.x). Is this important at all? You will always be able to build your own kernel or use one from backports. The importance is that, this version of the kernel is not a LTS (but it seems that Ubuntu will maintain it anyway...). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5ac7939249e98a0bc7f374a9ddf8a...@neutralite.org
Linux kernel version for Jessie
Hi list, what kernel version will Jessie have when it became stable ? Is there any chance for newer version than 3.16.x (for example 3.17.x, 3.18.x). Kind regards Georgi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544d5ff3.7030...@oles.biz
Re: Linux kernel version for Jessie
Georgi Naplatanov go...@oles.biz wrote: what kernel version will Jessie have when it became stable ? 3.16.x Is there any chance for newer version than 3.16.x (for example 3.17.x, 3.18.x). Zero chance: https://bits.debian.org/2014/07/kernel-version-for-jessie.html Grüße, S° -- Sigmentation fault. Core dumped. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0b3md0vd7...@mids.svenhartge.de
Re: Linux kernel version for Jessie
On Sun, Oct 26, 2014 at 10:56:19PM +0200, Georgi Naplatanov wrote: what kernel version will Jessie have when it became stable ? Is there any chance for newer version than 3.16.x (for example 3.17.x, 3.18.x). Is this important at all? You will always be able to build your own kernel or use one from backports. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141027001242.GA24804@nuc
Re: [Fwd: Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version]
What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. Yes you can, by getting the source code from kernel.org. If you simply copy the config from the Debians kernel, then IIRC # make-kpkg --initrd kernel-image kernel-headers won't use the Debians naming, but name the package and the output for uname -r and any string else as the original kernel.org name is. Thank you very much! That worked well and was easy! -- Thomas E. Vaughan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caao_ux-s-lz2rtcqmg1kjzdffzrmewogt7uwfyem1bpca03...@mail.gmail.com
Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version
Thomas Vaughan tevaug...@gmail.com writes: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? An appropriately named shell script in the right place in the path might take care of uname(1), but I don't see how to take care of uname(2), the system call. When the vendor says that the software parses the string, I think that the software is calling uname(). So my question is whether there is a way by compiling a custom kernel for me to alter what the uname() system call reports. You can replace functions from dynamically linked libraries using LD_PRELOAD. Check using ldd on your third party binary to verify it is dynamically linked. A quick search found this fragment of code: http://www.technovelty.org/c/using-ld_preload-to-override-a-function.html. That example is replacing getpid with a function that calls the original getpid and prints a message, but you can use the same trick for uname and modify the utsname structure to taste before returning. There are restrictions on what you can LD_PRELOAD, which are covered in the manpage for ld.so(8). But as long as you satisfy those constraints, this should be significantly easier than building your own kernel. -- regards, kushal pgp77iOTL_sm5.pgp Description: PGP signature
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On 2014-02-22 00:20 +0100, Thomas Vaughan wrote: I have downloaded some proprietary software that I want to install onto a 64-bit Debian machine. The software is written for 64-bit linux, but the kernel version reported, for example, by uname (and perhaps by some system call that the compiled software uses) is not in a format that the software expects. ---BEGIN QUOTE FROM VENDOR--- Its not that 3.12-1-amd64 isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? You could do that, but I would first try to run the software under setarch x86_64 --uname-2.6 which should let it see a kernel version of 2.6.52-1-amd64. Cheers, Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sirbblqc@turtle.gmx.de
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On Fri, 21 Feb 2014 22:58:40 -0500, Jerry Stuckle wrote: abiname shouldn't change should it? I wouldn't think so - but I also don't know. However, if you do change something basic like the kernel version, what else will it affect? You might get a kernel which will boot but nothing will run, for instance. When you install your custom kernel, make sure you keep an old kernel around, just in case. -- hendrik -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/leao5j$g51$3...@ger.gmane.org
Third-Party Software Needs Non-Debian Format for Kernel Version
I have downloaded some proprietary software that I want to install onto a 64-bit Debian machine. The software is written for 64-bit linux, but the kernel version reported, for example, by uname (and perhaps by some system call that the compiled software uses) is not in a format that the software expects. ---BEGIN QUOTE FROM VENDOR--- Its not that 3.12-1-amd64 isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? -- Thomas E. Vaughan
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On Feb 21, 2014, at 4:20 PM, Thomas Vaughan tevaug...@gmail.com wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? -- Glenn English -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/303a8294-5998-46d3-aebd-cab21fa97...@slsware.net
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
Forwarded Message From: Ralf Mardorf To: debian-user@lists.debian.org Subject: Re: Third-Party Software Needs Non-Debian Format for Kernel Version Date: Sat, 22 Feb 2014 01:54:59 +0100 Mailer: Evolution 3.10.4 Forwarded Message From: Ralf Mardorf To: debian-user@lists.debian.org Subject: Re: Third-Party Software Needs Non-Debian Format for Kernel Version Date: Sat, 22 Feb 2014 01:49:25 +0100 Mailer: Evolution 3.10.4 Forwarded Message From: Ralf Mardorf To: debian-user@lists.debian.org Subject: Re: Third-Party Software Needs Non-Debian Format for Kernel Version Date: Sat, 22 Feb 2014 01:35:26 +0100 Mailer: Evolution 3.10.4 On Fri, 2014-02-21 at 17:03 -0700, Glenn English wrote: On Feb 21, 2014, at 4:20 PM, Thomas Vaughan tevaug...@gmail.com wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or link or what ever? I don't understand what the software is doing, that the output of uname -r doesn't fit to some other string. More information is needed. Sure, Debian packages might be named 3.x for kernels 3.x.y, 3.x.z, 3.x.n. I like this, since I don't need to manually fix my manually customized grub.cfg, when such a kernel is upgraded and especially those kernels are updated and older versions automatically will be removed, while kernels build by myself are never touched. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1393032256.695.90.camel@archlinux
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On 22/02/14 11:03, Glenn English wrote: On Feb 21, 2014, at 4:20 PM, Thomas Vaughan tevaug...@gmail.com wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or sed? Or export? Or, um, more information about what Debian release is being used and the third-party software. :) Kind regards --- Dunno how to solve the problem but I know what you need to know to fix it for me? ;) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5307ff47.4070...@gmail.com
Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version
isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? An appropriately named shell script in the right place in the path might take care of uname(1), but I don't see how to take care of uname(2), the system call. When the vendor says that the software parses the string, I think that the software is calling uname(). So my question is whether there is a way by compiling a custom kernel for me to alter what the uname() system call reports. -- Thomas E. Vaughan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caao_ux-kfd6odmkp0fzzznwdbm1kljy+mykbknl9wfd6+qy...@mail.gmail.com
Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version
isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or link or what ever? I don't understand what the software is doing, that the output of uname -r doesn't fit to some other string. I think that the build system is using the uname(1) command, but the compiled software is calling the uname(2) system call. More information is needed. I have not very much information, but let's assume the worst: The vendor has some compiled code that calls the uname() system call. Is it possible by compiling a custom kernel for me to make what uname() returns be the format that the vendor desires, something like '3.12.9-1', or whatever? Sure, Debian packages might be named 3.x for kernels 3.x.y, 3.x.z, 3.x.n. I like this, since I don't need to manually fix my manually customized grub.cfg, when such a kernel is upgraded and especially those kernels are updated and older versions automatically will be removed, while kernels build by myself are never touched. I'm not sure that I understand. The package name is one thing, but isn't what uname returns something else? -- Thomas E. Vaughan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAO_ux8TwPVzU-NmP==wyqe23gia4ukkpujtdgpdprtc1v_...@mail.gmail.com
Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version
isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or sed? Or export? Or, um, more information about what Debian release is being used and the third-party software. :) If the compiled program calls the uname() system call, then script-related fixes won't work. I don't have the source to the compiled program. I'm running Debian testing (jessie). Kind regards And kind regards to you for replying so promptly to my plea for help! What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. If so, then any help doing that properly would be appreciated. -- Thomas E. Vaughan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAO_ux8P23JyZr3NyL_qR3K=0nzkeybr4vso9xsnj6+z_k-...@mail.gmail.com
[Fwd: Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version]
Forwarded Message From: Ralf Mardorf To: debian-user@lists.debian.org Subject: Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version Date: Sat, 22 Feb 2014 03:28:15 +0100 Mailer: Evolution 3.10.4 On Fri, 2014-02-21 at 19:20 -0700, Thomas Vaughan wrote: What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. Yes you can, by getting the source code from kernel.org. If you simply copy the config from the Debians kernel, then IIRC # make-kpkg --initrd kernel-image kernel-headers won't use the Debians naming, but name the package and the output for uname -r and any string else as the original kernel.org name is. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1393036199.695.111.camel@archlinux
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On 22/02/14 13:20, Thomas Vaughan wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or sed? Or export? Or, um, more information about what Debian release is being used and the third-party software. :) If the compiled program calls the uname() system call, then script-related fixes won't work. I don't have the source to the compiled program. Aaah - more information makes a difference. Yes - sed won't work with compiled (though you can often make simple changes in a compiled file with a binary editor - simpler than NOP hops). an alias will work. I'm running Debian testing (jessie). Kind regards And kind regards to you for replying so promptly to my plea for help! What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. Long way - try an alias first - it 'should' work fine. (The Debian promise applies - if it breaks you get to keep both pieces). If so, then any help doing that properly would be appreciated. Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53080cde.5040...@gmail.com
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On 2/21/2014 9:20 PM, Thomas Vaughan wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or sed? Or export? Or, um, more information about what Debian release is being used and the third-party software. :) If the compiled program calls the uname() system call, then script-related fixes won't work. I don't have the source to the compiled program. I'm running Debian testing (jessie). Kind regards And kind regards to you for replying so promptly to my plea for help! What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. If so, then any help doing that properly would be appreciated. I'm not sure if it will work or not - I'm far from a Debian kernel expert. But one thing to consider: are there any packages which require the correct Debian format? If so, what would happen to them if you changed it in the kernel? Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53080cf8.3020...@attglobal.net
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On 22/02/14 13:35, Jerry Stuckle wrote: On 2/21/2014 9:20 PM, Thomas Vaughan wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or sed? Or export? Or, um, more information about what Debian release is being used and the third-party software. :) If the compiled program calls the uname() system call, Good point. I should have given that more than a few seconds thought - and I suspect Jerry has pointed out a simpler way than intercepting sys calls. Is the name of the third-party software a secret? then script-related fixes won't work. I don't have the source to the compiled program. I'm running Debian testing (jessie). Kind regards And kind regards to you for replying so promptly to my plea for help! What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. If so, then any help doing that properly would be appreciated. I'm not sure if it will work or not - I'm far from a Debian kernel expert. Likewise. http://kernel-handbook.alioth.debian.org/ch-versions.html:- Kernel version This is the version that appears in kernel messages, filenames, package names and the output of 'uname -r'. In official kernel packages it follows the format upstreamversion[-abiname][-featureset]-flavour. It is not changed for every new package version. The abiname is changed as explained below. Many programs parse the kernel version string reported by the uname system call or command and expect to find at least 3 version components separated by dots. For compatibility, the official kernel packages currently add '.0' to the upstream version, but this will be dropped in wheezy+1. So it appears to be possible. But one thing to consider: are there any packages which require the correct Debian format? abiname shouldn't change should it? If so, what would happen to them if you changed it in the kernel? Jerry Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/530813c6.3050...@gmail.com
Re: Third-Party Software Needs Non-Debian Format for Kernel Version
On 2/21/2014 10:04 PM, Scott Ferguson wrote: On 22/02/14 13:35, Jerry Stuckle wrote: On 2/21/2014 9:20 PM, Thomas Vaughan wrote: isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or sed? Or export? Or, um, more information about what Debian release is being used and the third-party software. :) If the compiled program calls the uname() system call, Good point. I should have given that more than a few seconds thought - and I suspect Jerry has pointed out a simpler way than intercepting sys calls. Is the name of the third-party software a secret? then script-related fixes won't work. I don't have the source to the compiled program. I'm running Debian testing (jessie). Kind regards And kind regards to you for replying so promptly to my plea for help! What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. If so, then any help doing that properly would be appreciated. I'm not sure if it will work or not - I'm far from a Debian kernel expert. Likewise. http://kernel-handbook.alioth.debian.org/ch-versions.html:- Kernel version This is the version that appears in kernel messages, filenames, package names and the output of 'uname -r'. In official kernel packages it follows the format upstreamversion[-abiname][-featureset]-flavour. It is not changed for every new package version. The abiname is changed as explained below. Many programs parse the kernel version string reported by the uname system call or command and expect to find at least 3 version components separated by dots. For compatibility, the official kernel packages currently add '.0' to the upstream version, but this will be dropped in wheezy+1. So it appears to be possible. But one thing to consider: are there any packages which require the correct Debian format? abiname shouldn't change should it? I wouldn't think so - but I also don't know. However, if you do change something basic like the kernel version, what else will it affect? You might get a kernel which will boot but nothing will run, for instance. Just a thought. I always worry about side effects :) Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53082070.6050...@attglobal.net
Re: override kernel version with make-kpkg
On Tue, 10 Dec 2013 22:36:02 -0500 (EST), Michael Gulick wrote: I think my only option if I want automatic upgrades is to keep the abiname constant. I'm assuming (and I'm not sure whether this assumption is correct) that all the third party modules (primarily nvidia drivers and vmware) will be build by dkms on reboot. I've been upgrading the kernel manually for a while and haven't had any problems, so I think this is a safe assumption. I'm not sure if this is the right thing to do however, keeping the abiname the same for new stable releases. Any thoughts? To be honest, I really don't know. What you are trying to do is not something that any method of building a custom kernel tries to address. A custom kernel is, by definition, custom. It is not designed for or intended for automatic updates. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304596116.870129.1386982611903.javamail.r...@md01.wow.synacor.com
Re: override kernel version with make-kpkg
On Mon, 09 Dec 2013 23:13:32 -0500 (EST), Stephen Powell wrote: If you want to do this, you won't be able to use make-kpkg. You will need to do something like make a modified version of the Debian source package, linux, and build it with dpkg-buildpackage. But you want to use upstream sources. Hmm. No easy way to get from point A to point B. I haven't tried make deb-pkg in a while, but I suspect that it includes the SUBLEVEL in the package name as well. Give it a try and let me know what it does on current kernels, will you? I am trying to backport the latest LTSI 3.10-series kernels onto wheezy, so I ended up downloading the latest 3.10 source package from wheezy-backports, linux_3.10.11-1~bpo70+1.debian.tar.xz. This package was based on linux 3.10.11, and I am building against 3.10.23. I stripped out most of the patches that weren't necessary, removed the -rt featureset (which involved editing several configuration files), updated the abiname in debian/config/defines, ran dch --nmu to edit the changelog, and rebuilt using debuild -us -uc. I changed the abiname to differentiate this version from the upstream wheezy backports. I changed it from '0.bpo.3' to something like '0.bpo.mypkg1'. Also, when editing the changelog (via 'dch --nmu'), I set the version to '3.10.23-0~mypkg1~bpo70+1' This generates debian packages like linux-image-3.10-0.bpo.mypkg1-amd64_3.10.23-0~mypkg1~bpo70+1_amd64.deb. My plan what that with future stable releases I would increment the abiname, e.g. to '0.bpo.mypkg2', and the version, e.g. to '3.10.24-0~mypkg2~bpo70+1'. Unfortunately it seems the string 'linux-image-3.10-0.bpo.mypkg1' is used as the package name, which means that subsequent builds will have a different package name, and apt-get upgrade will not upgrade to the latest version automatically. I think my only option if I want automatic upgrades is to keep the abiname constant. I'm assuming (and I'm not sure whether this assumption is correct) that all the third party modules (primarily nvidia drivers and vmware) will be build by dkms on reboot. I've been upgrading the kernel manually for a while and haven't had any problems, so I think this is a safe assumption. I'm not sure if this is the right thing to do however, keeping the abiname the same for new stable releases. Any thoughts? I have a web page on the subject at http://users.wowway.com/~zlinuxman/Kernel.htm You might want to give it a read. Let me know if there's anything there that's out of date. I did come across your site in my searches prior to posting this. It was very helpful, but as you've seen it didn't quite have what I was looking for. I'll read it in depth some more and let you know if I have any feedback. I'd be happy to share more details about how I rebuilt the backports package for a newer kernel version. Let me know if you'd like me to send them to you. Thanks, Mike -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52a7dda2.6050...@gmail.com
override kernel version with make-kpkg
Hi, I'm looking for a way to override the default kernel package versions generated by make-kpkg. With 3.0+ kernels, the kernel sublevel (as in VERSION.PATCHLEVEL.SUBLEVEL), which is incremented when there are stable updates for a kernel release, is used to generate the package name. This produces packages with names like 'linux-image-3.10.22-mycustomversion_amd64.deb'. Unfortunately this means you can't upgrade these packages automatically with apt-get because apt-get thinks this is a new version of the package (instead of just an updated revision of the existing package version). I would like to be able to make packages called 'linux-image-3.10-myversion_amd64.deb', or 'linux-image-3.10.0-myversion_amd64.deb', so that these packages can be automatically upgraded via apt-get and a self-hosted repository. I'm building against the upstream vanilla kernel. I've tried editing the toplevel Makefile and setting SUBLEVEL = 0. While this does produce packages with version 3.10.0-something, the generated file include/generated/uapi/linux/version.h now indicates that the kernel is actually version 3.10.0 instead of 3.10.22. The stock kernel on wheezy (3.2.0) seems to have a correct value in version.h regardless of the package version. Any thoughts on how this can be done? Thanks, Mike
Re: override kernel version with make-kpkg
On Mon, Dec 9, 2013 at 8:39 PM, Michael Gulick mgul...@gmail.com wrote: I'm looking for a way to override the default kernel package versions generated by make-kpkg. With 3.0+ kernels, the kernel sublevel (as in VERSION.PATCHLEVEL.SUBLEVEL), which is incremented when there are stable updates for a kernel release, is used to generate the package name. This produces packages with names like 'linux-image-3.10.22-mycustomversion_amd64.deb'. Unfortunately this means you can't upgrade these packages automatically with apt-get because apt-get thinks this is a new version of the package (instead of just an updated revision of the existing package version). I would like to be able to make packages called 'linux-image-3.10-myversion_amd64.deb', or 'linux-image-3.10.0-myversion_amd64.deb', so that these packages can be automatically upgraded via apt-get and a self-hosted repository. I'm building against the upstream vanilla kernel. I've tried editing the toplevel Makefile and setting SUBLEVEL = 0. While this does produce packages with version 3.10.0-something, the generated file include/generated/uapi/linux/version.h now indicates that the kernel is actually version 3.10.0 instead of 3.10.22. The stock kernel on wheezy (3.2.0) seems to have a correct value in version.h regardless of the package version. The kernel, unlike other packages, has a version included in its name. For example, util-linux's deb is util-linux_2.20.1-5.5_amd64.deb whereas the kernel's deb is linux-image-3.11-2-amd64_3.11.8-1_amd64.deb. AIUI Debian gets around this by having a linux-image-amd64 metapackage that depends on linux-image-3.11-2-amd64_3.11.8-1_amd64.deb. When there's a new version of linux-image-version-amd64 , the version of linux-image-amd64 is bumped up and depends on it. # aptitude search --disable-columns -F %c%a%M %p %v %V linux-image i A linux-image-3.11-2-amd64 3.11.10-1 3.11.10-1 p linux-image-3.11-2-amd64-dbg none 3.11.10-1 i linux-image-amd64 3.11+54 3.11+54 p linux-image-amd64-dbg none 3.11+54 # # apt-cache show linux-image-amd64 | grep pool Filename: pool/main/l/linux-latest/linux-image-amd64_3.11+54_amd64.deb # # apt-cache show linux-image-3.11-2-amd64 | grep pool Filename: pool/main/l/linux/linux-image-3.11-2-amd64_3.11.10-1_amd64.deb Filename: pool/main/l/linux/linux-image-3.11-2-amd64_3.11.8-1_amd64.deb # # aptitude search --disable-columns -F %c%a%M %p %v %V '?reverse-depends(linux-image-amd64)' i A linux-image-3.11-2-amd64 3.11.10-1 3.11.10-1 p linux-image-3.11-2-amd64-dbg none 3.11.10-1 # So you could create a mykernel package (for example) that plays the same role for your linux-image-ver-myversion. OT: There's one thing that I don't understand. Your kernel package name is linux-image-ver-myversion_amd64.deb but if you look at a distro kernel deb you'll notice that it has two _ as above. In that distro kernel deb, 3.11.8-1 is the version of the deb and it's set via --revision when using make-kpkg. The make-kpkg revision default is 10.00.Custom. How are you overriding this value and making it nil? Does '--revision ' do it? More or less OT: kernel-package, and therefore make-kpkg, is considered unmaintained by the kernel maintainers. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SzBFiv6N0iq9r5xnF7Uf1zoWHTY7ZPcfKtp=mtc3p3...@mail.gmail.com
Re: override kernel version with make-kpkg
On Mon, 09 Dec 2013 15:39:29 -0500 (EST), Michael Gulick wrote: Hi, I'm looking for a way to override the default kernel package versions generated by make-kpkg. With 3.0+ kernels, the kernel sublevel (as in VERSION.PATCHLEVEL.SUBLEVEL), which is incremented when there are stable updates for a kernel release, is used to generate the package name. This produces packages with names like 'linux-image-3.10.22-mycustomversion_amd64.deb'. Actually, the pattern is more like linux-image-3.10.22-mycustomversion_3.10.22-1_amd64.deb Unfortunately this means you can't upgrade these packages automatically with apt-get because apt-get thinks this is a new version of the package (instead of just an updated revision of the existing package version). You don't use apt-get (or aptitude) to install such a package, you use dpkg. For example, dpkg -i linux-image-3.10.22-mycustomversion_3.10.22-1_amd64.deb dpkg treats this as a new package, not an upgrade to an existing package, that's true. And for custom kernels, that's probably what you want. I would like to be able to make packages called 'linux-image-3.10-myversion_amd64.deb', or 'linux-image-3.10.0-myversion_amd64.deb', so that these packages can be automatically upgraded via apt-get and a self-hosted repository. Ah, a self-hosted repository. OK, in that case, apt-get or aptitude is what you would use. Unfortunately, I know of no way to do what you want to do. Keep this in mind. Up until etch, the Debian kernel team used make-kpkg to produce its stock Debian kernels. But beginning with lenny, the Debian kernel team stopped using make-kpkg to produce its stock kernel packages and went their own way. But all three levels of the kernel version name (VERSION, PATCHLEVEL, and SUBLEVEL) were still used, at first, in the stock kernel version name, just as make-kpkg does it. But recently, the kernel team has started forcing the sublevel to zero in the linux image package name, such as in the stable kernels, or eliminating it altogether, such as in the testing kernels. The actual SUBLEVEL persists in the package version, but not in the kernel version included in the package name. That is a naming convention change for linux kernel images that has been recently adopted by the Debian kernel team. make-kpkg still does things the old way. It includes the SUBLEVEL in the package name. There is an --append-to-version option which can be used to append your own qualifiers, but no option that I know of to eliminate the SUBLEVEL from the name. If you want to do this, you won't be able to use make-kpkg. You will need to do something like make a modified version of the Debian source package, linux, and build it with dpkg-buildpackage. But you want to use upstream sources. Hmm. No easy way to get from point A to point B. I haven't tried make deb-pkg in a while, but I suspect that it includes the SUBLEVEL in the package name as well. Give it a try and let me know what it does on current kernels, will you? I have a web page on the subject at http://users.wowway.com/~zlinuxman/Kernel.htm You might want to give it a read. Let me know if there's anything there that's out of date. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1126472401.790971.1386648812411.javamail.r...@md01.wow.synacor.com
kernel version
I have two files, linux_2.6.x_VCP_Driver_Source.zip and linux_2.6.x_VCP_Driver_Source.zip. Each 'unzips' to the following files. These are Silicon Labs USB drivers. linux_2.6.x_VCP_Driver_Source.zip linux_2.6.x_VCP_Driver_Source.zip cp210x.c cp210x.c cp210x_gpio_example.c cp210x_gpio_example.c CP210x_VCP_Linux_2.6.x_Release_Notes.txt CP210x_VCP_Linux_2.6.x_Release_Notes.txt Makefile Makefile These are USB drivers to enable me to use a ham radio program (fldigi) so I can talk to my radio and transmit digital signals via the rear usb port on my ICOM IC-7600. The release notes give me instructions on how to install the driver for ubuntu and redhat and I do believe Ubuntu is a derivative of Debian which if I follow the following instruction should enable me to install that particular driver. Build instrutions: Ubuntu: 1. make ( your cp210x driver ) 2. cp cp210x.ko to /lib/modules/kernel-version/kernel/drivers/usb/serial 3. insmod /lib/modules/kernel-version/kernel/drivers/usb/serial/usbserial.ko 4. insmod cp210x.ko What I want to know is how do I determine the kernel version of my debian 6 system so I can load the correct version? John -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5207ad9d.9060...@sentex.net
Re: kernel version
John Lindsay grabbed a keyboard and wrote: What I want to know is how do I determine the kernel version of my debian 6 system so I can load the correct version? uname -r will do it. man uname for more. :-) --Dave smime.p7s Description: S/MIME Cryptographic Signature
Re: kernel version
On 2013-08-11, John Lindsay jcl...@sentex.net wrote: snip What I want to know is how do I determine the kernel version of my debian 6 system so I can load the correct version? John run uname -a from a term -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130811125714.657@0.0.0
Re: kernel version
Thanks for the info -- Running kernel 2.6.x.xx so I know which USB driver I need to install On 11/08/13 01:02 PM, Kruppt wrote: On 2013-08-11, John Lindsayjcl...@sentex.net wrote: snip What I want to know is how do I determine the kernel version of my debian 6 system so I can load the correct version? John run uname -a from a term -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5207d2f1.7040...@sentex.net
Re: Error after booting default kernel version
2012/10/20 Johan Grönqvist johan.gronqv...@gmail.com: 2012-10-20 10:44, Gábor Hársfalvi skrev: I've used this tutorial - http://forums.debian.net/viewtopic.php?f=16t=60019 - yesterday, and after reboot the playmouth animation worked but before it arrived login screen it showed me a black blank screen with a flashing cursor - not mouse - and after more waiting it stayed there too. Good! Now you know exactly what edits to what config files that you need to undo. I reboot after it and start with a previous kernel version number - the number ends with 486, not 686 - with Rescue Mode. It started and after Ctrl+D - when it needs - it booted the gui succesfully and everything worked well. So it sounds to me like there is no problem with your system as a whole, just the boot config for the 686 kernel. I would like to start the computer with the newest available kernel version number, what ends with 686, and what were the default when I started the system before, but it doesn't work and give me the error screen what I mentioned before. Please give me help to repair this to boot the computer normally as before it was happenned. I would: Start the system the way you can, via rescue mode. Undo the edits you made before. It might be enough to replace GRUB_CMDLINE_LINUX_DEFAULT=quiet splash nomodeset video=uvesafb:mode_option=1400x1050-24,mtrr=3,scroll=ywrap by CMDLINE_LINUX_DEFAULT=quiet Run the same update-initramfs and update-grub commands as you did when following the guide. Hope it helps Johan -- Now you know exactly what edits to what config files that you need to undo. - Yes, I tried that but nothing helped yet. the boot config for the 686 kernel. - Where and how could I repair this? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadh5rwanzg4pcdeyiqiv6p20pe0pzukeqrjhxjghfasly_w...@mail.gmail.com
Re: Error after booting default kernel version
2012-10-21 18:34, Gábor Hársfalvi skrev: 2012/10/20 Johan Grönqvistjohan.gronqv...@gmail.com: 2012-10-20 10:44, Gábor Hársfalvi skrev: Good! Now you know exactly what edits to what config files that you need to undo. Now you know exactly what edits to what config files that you need to undo. - Yes, I tried that but nothing helped yet. the boot config for the 686 kernel. - Where and how could I repair this? Did you ensure that the line starting with GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub reads GRUB_CMDLINE_LINUX_DEFAULT=quiet and put a # at the beginning of the GRUB_GFXMODE line then run update-grub2 again (as root or using sudo)? Did you remove the line uvesafb mode_option=1400x1050-24 mtrr=3 scroll=ywrap (or similar) from /etc/initramfs-tool/modules then run update-initramfs -u (as root or using sudo) again? (I had a typo in the first mail, and I may have one again, but the above should describe undoing the edits from the guide.) I would have expected that your installation would boot normally again after that. Regards Johan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/k61lue$cba$1...@ger.gmane.org
Error after booting default kernel version
Hi, I've used this tutorial - http://forums.debian.net/viewtopic.php?f=16t=60019 - yesterday, and after reboot the playmouth animation worked but before it arrived login screen it showed me a black blank screen with a flashing cursor - not mouse - and after more waiting it stayed there too. I reboot after it and start with a previous kernel version number - the number ends with 486, not 686 - with Rescue Mode. It started and after Ctrl+D - when it needs - it booted the gui succesfully and everything worked well. I would like to start the computer with the newest available kernel version number, what ends with 686, and what were the default when I started the system before, but it doesn't work and give me the error screen what I mentioned before. Please give me help to repair this to boot the computer normally as before it was happenned. Thanks. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadh5rwbhzfrpkgcna0yccanyv195hwvz-q6k6dj+013_9js...@mail.gmail.com
Re: Error after booting default kernel version
2012-10-20 10:44, Gábor Hársfalvi skrev: I've used this tutorial - http://forums.debian.net/viewtopic.php?f=16t=60019 - yesterday, and after reboot the playmouth animation worked but before it arrived login screen it showed me a black blank screen with a flashing cursor - not mouse - and after more waiting it stayed there too. Good! Now you know exactly what edits to what config files that you need to undo. I reboot after it and start with a previous kernel version number - the number ends with 486, not 686 - with Rescue Mode. It started and after Ctrl+D - when it needs - it booted the gui succesfully and everything worked well. So it sounds to me like there is no problem with your system as a whole, just the boot config for the 686 kernel. I would like to start the computer with the newest available kernel version number, what ends with 686, and what were the default when I started the system before, but it doesn't work and give me the error screen what I mentioned before. Please give me help to repair this to boot the computer normally as before it was happenned. I would: Start the system the way you can, via rescue mode. Undo the edits you made before. It might be enough to replace GRUB_CMDLINE_LINUX_DEFAULT=quiet splash nomodeset video=uvesafb:mode_option=1400x1050-24,mtrr=3,scroll=ywrap by CMDLINE_LINUX_DEFAULT=quiet Run the same update-initramfs and update-grub commands as you did when following the guide. Hope it helps Johan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/k5tshj$s28$1...@ger.gmane.org
Re: New kernel version availability.
On Sb, 17 dec 11, 01:28:59, Sthu Deus wrote: How do I find out if there is a new version of linux kernel package is available? - I mean, having 3.1 installed, to know that 3.2 is available? Beside Camaleón's suggestion, aptitude keeps track of new[1] packages. You can show the list with 'aptitude search ~N' and clear it with 'aptitude forget-new'. In interactive mode new packages have a dedicated section. [1] new for aptitude means new packages that are available since your last 'update'. This might happen because packages have been added to repositories you are tracking or just because you added new repositories to sources.list. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: New kernel version availability.
Sthu Deus wrote: apt-cache search linux-image ... Is there a more elegant way? In addition to the ways suggested by others there is also a program to query the database and provide other useful information. apt-show-versions | grep linux-image Mine shows: linux-image-2.6.32-5-686/squeeze-updates uptodate 2.6.32-39 linux-image-686/squeeze uptodate 2.6.32+29 Bob signature.asc Description: Digital signature
New kernel version availability.
Good time of the day. How do I find out if there is a new version of linux kernel package is available? - I mean, having 3.1 installed, to know that 3.2 is available? For the present I do it by apt-cache search linux-image and then look for what is available. Is there a more elegant way? PS apt-cache policy linux-image-exact_version shows only updates for the version - and not a new kernel version s 3.2 vs. 3.1 Thanks for Your time. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eeb8df6.823ce30a.02a9.4...@mx.google.com
Re: New kernel version availability.
On Sat 17 Dec 2011 at 01:28:59 +0700, Sthu Deus wrote: How do I find out if there is a new version of linux kernel package is available? - I mean, having 3.1 installed, to know that 3.2 is available? For the present I do it by apt-cache search linux-image and then look for what is available. Is there a more elegant way? w3m -dump http://packages.debian.org/unstable/kernel/ | grep linux-image-3.*pae | mail -s kernel images available brian is about as elegant as it gets here. Could be scripted, of course, and cron could be in on the act. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111216192007.GA3655@desktop
Re: New kernel version availability.
On Sat, 17 Dec 2011 01:28:59 +0700, Sthu Deus wrote: How do I find out if there is a new version of linux kernel package is available? - I mean, having 3.1 installed, to know that 3.2 is available? If it is available, the upgrade routine will auto-fetch it, as long as you have the kernel metapackage installed (for a 64-bits kernel that's linux-image-amd64 package). For the present I do it by apt-cache search linux-image and then look for what is available. Is there a more elegant way? apt-get update apt-get -V dist-upgrade is what I use to run in wheezy. PS apt-cache policy linux-image-exact_version shows only updates for the version - and not a new kernel version s 3.2 vs. 3.1 Anyway, AFAICS the latest available kernel in Debian is 3.1 (testing/sid) and 3.2 (for experimental). What branch are you running? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.12.16.21.00...@gmail.com
Re: New kernel version availability.
On 12/16/2011 02:20 PM, Brian wrote: On Sat 17 Dec 2011 at 01:28:59 +0700, Sthu Deus wrote: How do I find out if there is a new version of linux kernel package is available? - I mean, having 3.1 installed, to know that 3.2 is available? For the present I do it by apt-cache search linux-image and then look for what is available. Is there a more elegant way? w3m -dump http://packages.debian.org/unstable/kernel/ | grep linux-image-3.*pae | mail -s kernel images available brian is about as elegant as it gets here. Could be scripted, of course, and cron could be in on the act. apt-cache policy linux-image-3.* WT -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eebb4bb.3070...@gmail.com
Re: get kernel version of chroot
Hi. On Monday 16 August 2010 03:00, T o n g wrote: Hi, Is it possible to get the kernel version of a chroot system? I tried chroot chroot_fs uname -r but it only reports the kernel version of my current system, not the chroot system. Chroot changes into a different directory structure but does not boot a different kernel. uname reports the kernel in use, and that did not change. regards, Hartwig -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100816114717.478dc3dc...@mail-in-18.arcor-online.net
get kernel version of chroot
Hi, Is it possible to get the kernel version of a chroot system? I tried chroot chroot_fs uname -r but it only reports the kernel version of my current system, not the chroot system. Any other way? Thanks -- Tong (remove underscore(s) to reply) http://xpt.sourceforge.net/techdocs/ http://xpt.sourceforge.net/tools/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i4a2k6$rr...@dough.gmane.org
Re: get kernel version of chroot
On Sun, 15 Aug 2010 21:00:54 -0400 (EDT), Tong wrote: Is it possible to get the kernel version of a chroot system? I'm not sure that I understand what question you are really asking. I am assuming that you have, for example, used a Debian installation CD as a rescue CD on a system that you do not know what version of the kernel it normally runs. You are now running in a chrooted shell session. uname -r reports the version of the kernel that the rescue CD is running, but you want to know what version of the kernel the target system normally runs. If that is what you are asking, the easiest way I know to find out is to look at what kernel image (or images) are stored in the /boot directory. If there's more than one, you may be able to determine what the default kernel is by looking for the boot loader configuration file, such as /etc/lilo.conf, /boot/grub/menu.lst, etc. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1636772853.117145.1281921556857.javamail.r...@md01.wow.synacor.com
Re: etch kernel version 2.6.18
On Tuesday 01 September 2009, Greg Madden wrote: I have a Lenny box running the 2.6.18 kernel. I have the following sources added to the Lenny ones: deb http://mirrors.kernel.org/debian/ etch main contrib deb http://security.debian.org/ etch/updates main contrib. This gives me kernel version: 2.6.18-5. At http://packages.debian.org/etch; it shows kernel version 2.6.18-6. I am using dselect, and I am wondering why the differences in kernel version. -- TIA Peace Greg Madden It appears kernel 2.6.18-6 is available in dselect, it is just not offered as an 'update to 2.6.18-5. -- Peace Greg Madden -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: etch kernel version 2.6.18
On 2009-09-02 08:07 +0200, Greg Madden wrote: On Tuesday 01 September 2009, Greg Madden wrote: I have a Lenny box running the 2.6.18 kernel. I have the following sources added to the Lenny ones: deb http://mirrors.kernel.org/debian/ etch main contrib deb http://security.debian.org/ etch/updates main contrib. This gives me kernel version: 2.6.18-5. At http://packages.debian.org/etch; it shows kernel version 2.6.18-6. I am using dselect, and I am wondering why the differences in kernel version. -- TIA Peace Greg Madden It appears kernel 2.6.18-6 is available in dselect, it is just not offered as an 'update to 2.6.18-5. Because it has a different ABI, the package name differs. The -5 and -6 indicate the ABI numbers, do not confuse it with Debian revisions. Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
etch kernel version 2.6.18
I have a Lenny box running the 2.6.18 kernel. I have the following sources added to the Lenny ones: deb http://mirrors.kernel.org/debian/ etch main contrib deb http://security.debian.org/ etch/updates main contrib. This gives me kernel version: 2.6.18-5. At http://packages.debian.org/etch; it shows kernel version 2.6.18-6. I am using dselect, and I am wondering why the differences in kernel version. -- TIA Peace Greg Madden -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
/lib/modules/kernel-version directory not being removed
In a normal scenario, whenever we do: apt-get purge linux-image- the corresponding: /lib/modules/ directory gets removed from the system. But I noticed that suppose installed some out-of-tree kernel modules and now when you try to remove the same kernel (for which you installed out-of-tree modules), I get the following error message: Purging configuration files for linux-image-2.6.30-1-test7 ... Running postrm hook script /sbin/update-grub. Searching for GRUB installation directory ... found: /boot/grub Searching for default file ... found: /boot/grub/default Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst Searching for splash image ... none found, skipping ... Found kernel: /boot/vmlinuz-2.6.30-3-bpo50-test10 Updating /boot/grub/menu.lst ... done rmdir: failed to remove `/lib/modules/2.6.30-1-test7': Directory not empty dpkg - warning: while removing linux-image-2.6.30-1-test7, directory `/lib/modules/2.6.30-1-test7' not empty so not removed. In the above output I am trying to remove the kernel 2.6.30-1-test7. I know I can explicitly remove the directory but I would is there any configuration file which prevents removed directory which have been tainted by adding some additional files/modules which were not part of the original package? Kushal Koolwal I do blog at http://blogs.koolwal.net/ _ Get your vacation photos on your phone! http://windowsliveformobile.com/en-us/photos/default.aspx?OCID=0809TL-HM -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /lib/modules/kernel-version directory not being removed
On 2009-08-13 21:51 +0200, Kushal Koolwal wrote: In a normal scenario, whenever we do: apt-get purge linux-image- the corresponding: /lib/modules/ directory gets removed from the system. But I noticed that suppose installed some out-of-tree kernel modules and now when you try to remove the same kernel (for which you installed out-of-tree modules), I get the following error message: Purging configuration files for linux-image-2.6.30-1-test7 ... Running postrm hook script /sbin/update-grub. Searching for GRUB installation directory ... found: /boot/grub Searching for default file ... found: /boot/grub/default Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst Searching for splash image ... none found, skipping ... Found kernel: /boot/vmlinuz-2.6.30-3-bpo50-test10 Updating /boot/grub/menu.lst ... done rmdir: failed to remove `/lib/modules/2.6.30-1-test7': Directory not empty dpkg - warning: while removing linux-image-2.6.30-1-test7, directory `/lib/modules/2.6.30-1-test7' not empty so not removed. This sounds logical, since your out-of-tree modules are probably still there. In the above output I am trying to remove the kernel 2.6.30-1-test7. I know I can explicitly remove the directory but I would is there any configuration file which prevents removed directory which have been tainted by adding some additional files/modules which were not part of the original package? No, there is no such configuration file. A directory cannot be removed unless it is empty, it is as simple as that. Or do you mean that the directory _is_ empty? In that case, please show the exact command you typed and the complete output you got. Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RE: /lib/modules/kernel-version directory not being removed
This sounds logical, since your out-of-tree modules are probably still there. Yeah that's right. But why doesn't it (apt-get purge) remove those out-of-tree modules also when I try to remove the package? Is there a Debian package rule which says only remove files which were originally provided by the package and hence the out-of-tree module (which were not a part of the original package (linux-image-) gets left out and hence the directory is not removed since it is empty? Kushal Koolwal I do blog at http://blogs.koolwal.net/ _ Get your vacation photos on your phone! http://windowsliveformobile.com/en-us/photos/default.aspx?OCID=0809TL-HM -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /lib/modules/kernel-version directory not being removed
Kushal Koolwal writes: Is there a Debian package rule which says only remove files which were originally provided by the package... Would you expect removing vi to remove all the files you created with it? Purge means remove the configuration files that the package installed in addition to all the other files from the package. -- John Hasler -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RE: /lib/modules/kernel-version directory not being removed
Would you expect removing vi to remove all the files you created with it? Purge means remove the configuration files that the package installed in addition to all the other files from the package. Agreed, and I am not surprised that this happens. My intent for asking the question was to know where does that information exists in the package - like is there some kind of hook or a control file that does take care of this. Just trying to understand what causes such a mechanism. Kushal Koolwal I do blog at http://blogs.koolwal.net/ _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=PID23384::T:WLMTAGL:ON:WL:en-US:NF_BR_sync:082009 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: kernel version of debian testing.
--- On Thu, 12/18/08, Jan Brosius jan.bros...@skynet.be wrote: From: Jan Brosius jan.bros...@skynet.be Subject: kernel version of debian testing. To: debian-user@lists.debian.org Date: Thursday, December 18, 2008, 6:55 PM Hi, Does anyone know the kernel version in the latest version of debian-testing? I saw on the internet that my hardware (more precisely my ethernet card) needs kernel 2.6.27-*. thanks for any information, Jan Testing is still using the 2.6.26 kernel. -- Angus All churches, whether Jewish, Christian, or Muslim, appear to me no other than human inventions, setup to terrify and enslave mankind - and to monopolize power and profit. -- Thomas Paine (1737-1809) ##Laptop powered by Linux## ##Reg. Linux User #278931## -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
kernel version of debian testing.
Hi, Does anyone know the kernel version in the latest version of debian-testing? I saw on the internet that my hardware (more precisely my ethernet card) needs kernel 2.6.27-*. thanks for any information, Jan
Re: kernel version of debian testing.
On 12/18/08 12:55, Jan Brosius wrote: Hi, Does anyone know the kernel version in the latest version of debian-testing? I saw on the internet that my hardware (more precisely my ethernet card) needs kernel 2.6.27-*. thanks for any information, $ apt-cache search linux-image | grep ^linux-image | sort $ uname -r -- Ron Johnson, Jr. Jefferson LA USA How does being physically handicapped make me Differently-Abled? What different abilities do I have? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: kernel version of debian testing.
On 2008-12-18 19:08 +0100, Ron Johnson wrote: On 12/18/08 12:55, Jan Brosius wrote: Hi, Does anyone know the kernel version in the latest version of debian-testing? I saw on the internet that my hardware (more precisely my ethernet card) needs kernel 2.6.27-*. thanks for any information, $ apt-cache search linux-image | grep ^linux-image | sort $ uname -r Kind of useless for somebody who is not running Debian yet but rather considering to install it. Jan, you're out of luck, 2.6.26 is the latest kernel in Debian. There are unofficial repositories with 2.6.27, but you may have some problems to access them if your network doesn't work. Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: kernel version of debian testing.
On 12/18/08 12:26, Sven Joachim wrote: On 2008-12-18 19:08 +0100, Ron Johnson wrote: On 12/18/08 12:55, Jan Brosius wrote: Hi, Does anyone know the kernel version in the latest version of debian-testing? I saw on the internet that my hardware (more precisely my ethernet card) needs kernel 2.6.27-*. thanks for any information, $ apt-cache search linux-image | grep ^linux-image | sort $ uname -r Kind of useless for somebody who is not running Debian yet but rather considering to install it. Isn't he already running Debian? Doesn't *everyone* already run Debian But seriously, from this page http://www.debian.org/distrib/packages you can search for packages. Specifically, this is what OP needs: http://packages.debian.org/search?keywords=linux-imagesearchon=namessuite=testingsection=all Of course, since he doesn't run Debian, he doesn't know to search for linux-image. Shame on him!!! Jan, you're out of luck, 2.6.26 is the latest kernel in Debian. There are unofficial repositories with 2.6.27, but you may have some problems to access them if your network doesn't work. -- Ron Johnson, Jr. Jefferson LA USA How does being physically handicapped make me Differently-Abled? What different abilities do I have? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Kernel version for Pentium MMX
Hello, We're in the process of upgrading some old computers from sarge to etch. On one computer (used only as a firewall) it has: Intel Pentium with F0 0F bug - workaround enabled. CPU: Intel Pentium MMX stepping 03 Anyway the kernel it is running is: vmlinuz-2.4.27-4-586tsc for the Pentium-Classic. My question is, on the upgrade should I install the kernel-image-2.6-386 or the kernel-image-2.6-686? I see no 586tsc. Thanks, Ken -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel version for Pentium MMX
Intel Pentium with F0 0F bug - workaround enabled. CPU: Intel Pentium MMX stepping 03 Anyway the kernel it is running is: vmlinuz-2.4.27-4-586tsc for the Pentium-Classic. My question is, on the upgrade should I install the kernel-image-2.6-386 or the kernel-image-2.6-686? I see no 586tsc. I'd say install the 386 one. Your CPU is not a 686. -- Gu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel version for Pentium MMX
On Monday 21 July 2008 22:49, Account for Debian group mail wrote: Hello, We're in the process of upgrading some old computers from sarge to etch. On one computer (used only as a firewall) it has: Intel Pentium with F0 0F bug - workaround enabled. CPU: Intel Pentium MMX stepping 03 Anyway the kernel it is running is: vmlinuz-2.4.27-4-586tsc for the Pentium-Classic. My question is, on the upgrade should I install the kernel-image-2.6-386 or the kernel-image-2.6-686? I see no 586tsc. Thanks, Ken Ken The Pentium MMX is a 586, you should use kernel-image-2.6-386. Steven. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel version for Pentium MMX
Account for Debian group mail wrote: My question is, on the upgrade should I install the kernel-image-2.6-386 or the kernel-image-2.6-686? I see no 586tsc. Wow, this brings back memories (COAST modules anyone?) IIRC the 686 image will barf on your Pentium MMX as the Pentium Pro instruction set isn't supported. Don't know if it'd be worth looking at linux-image-2.6-486. Out of curiosity, why hang onto an old Pentium when you can pick up an old Athlon or P3 for probably nothing? Aside from not dumping yet another system into the waste stream that is. Best of luck, -- Henry Luciano Mote Marine Laboratory IS Director 941-388-4441 x409 The computer ... is an Old Testament God - lots of rules and no mercy. ~ Joseph Campbell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel version for Pentium MMX
Henry, On Mon, 21 Jul 2008, Henry Luciano wrote: Out of curiosity, why hang onto an old Pentium when you can pick up an old Athlon or P3 for probably nothing? Aside from not dumping yet another system into the waste stream that is. Because this computer was long ago paid for and there for doesn't cost anything. It is slow as sin but does a good job as a firewall and was our way to recycle an old worthless machine. It's been working fine as a fire wall for several years. Ken -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel version for Pentium MMX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/08 17:10, Henry Luciano wrote: [snip] Out of curiosity, why hang onto an old Pentium when you can pick up an old Athlon or P3 for probably nothing? Aside from not dumping yet another system into the waste stream that is. Maybe(?) because the CPU heat sink doesn't need a fan, and is therefore quiet? And, of course, it's paid for. Even quieter with a CF-IDE converter. - -- Ron Johnson, Jr. Jefferson LA USA Kittens give Morbo gas. In lighter news, the city of New New York is doomed. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiFIbkACgkQS9HxQb37XmdIYwCdH23wdXrsl+C6w/0Z0/IaPFfs ZzsAoI/narj+fmL3zRCHdsfpY0aBnIpE =BTRL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: updater wants to update to the current kernel version
Thanks for that. At least I know it is not a bug. Andrew On Sun, 2008-06-15 at 11:37 -0400, Douglas A. Tutty wrote: On Sun, Jun 15, 2008 at 08:24:33PM +1000, Andrew Storm wrote: Hi whoever is out there. I recently installed debian etch in a virtual box vm. Several times since then the updater has wanted to update the kernel image to the same version as the current kernel, which is 2.6.18-6-k7. I let it do it the first couple of times since i was new to debian, but it has become an irritation. Does anyone know why this happens? Is it a bug in the updater? Can anyone tell me how to stop this behaviour? Hello Andrw, I sent this to both you and the list given your whoever is out there. There have been repeated bugs found in the kernel that have been patched without changing the kernel version. So yes, you should continue to keep your system up-to-date even if the kernel version stays the same. I don't know what updater is, since the default package manager on Etch is aptitude on which you then run update to see what's new. I hope this answers your question. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
updater wants to update to the current kernel version
Hi whoever is out there. I recently installed debian etch in a virtual box vm. Several times since then the updater has wanted to update the kernel image to the same version as the current kernel, which is 2.6.18-6-k7. I let it do it the first couple of times since i was new to debian, but it has become an irritation. Does anyone know why this happens? Is it a bug in the updater? Can anyone tell me how to stop this behaviour? Thanks Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: updater wants to update to the current kernel version
On Sun, Jun 15, 2008 at 08:24:33PM +1000, Andrew Storm wrote: Hi whoever is out there. I recently installed debian etch in a virtual box vm. Several times since then the updater has wanted to update the kernel image to the same version as the current kernel, which is 2.6.18-6-k7. I let it do it the first couple of times since i was new to debian, but it has become an irritation. Does anyone know why this happens? Is it a bug in the updater? Can anyone tell me how to stop this behaviour? Hello Andrw, I sent this to both you and the list given your whoever is out there. There have been repeated bugs found in the kernel that have been patched without changing the kernel version. So yes, you should continue to keep your system up-to-date even if the kernel version stays the same. I don't know what updater is, since the default package manager on Etch is aptitude on which you then run update to see what's new. I hope this answers your question. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny Install CD kernel version. [solved-sorta]
koffiejunkie wrote: Jeff D wrote: On Sun, 15 Jul 2007, koffiejunkie wrote: When the installer came up, I hit Ctrl+Alt+F2 for a console, and did a uname -a. It gave me 2.6.18. This is what I want to check before downloading: which kernel the install CD uses, not which kernel it installs. are you sure you have the right one? The iso I downladed was built on the 10th. This is from the boot kernel of it: No, mine was built today. I'll look for that one and give it a try. Thanks! Ok, that (it's been replaced with 17 July though), does boot off the 2.6.21, but as luck would have it my notebook died yesterday. Sigh Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Lenny Install CD kernel version.
Hi guys, I noticed that even though 2.6.21 is now in the Lenny repos, the install CD (well, 13 July, at least) still runs 2.6.18. Is there any way to check, before downloading, what version of the kernel the install CD runs? Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny Install CD kernel version.
On Sun July 15 2007 04:38, koffiejunkie wrote: Hi guys, I noticed that even though 2.6.21 is now in the Lenny repos, the install CD (well, 13 July, at least) still runs 2.6.18. Is there any way to check, before downloading, what version of the kernel the install CD runs? What install disk are you using? The full install set hasn't been updated in a while, but you can get the daily built netinstall or businesscard iso and they use sid's kernel if I'm not mistaken. http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny Install CD kernel version.
Alan Ianson wrote: On Sun July 15 2007 04:38, koffiejunkie wrote: Hi guys, I noticed that even though 2.6.21 is now in the Lenny repos, the install CD (well, 13 July, at least) still runs 2.6.18. Is there any way to check, before downloading, what version of the kernel the install CD runs? What install disk are you using? The full install set hasn't been updated in a while, but you can get the daily built netinstall or businesscard iso and they use sid's kernel if I'm not mistaken. http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/ It was the daily build netinstall from 13 July that I downloaded (I guess the builds are made US time, so 14 July wasn't out yet). I checked after booting off the disc - it was 2.6.18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny Install CD kernel version.
On Sun July 15 2007 07:53, koffiejunkie wrote: Alan Ianson wrote: On Sun July 15 2007 04:38, koffiejunkie wrote: Hi guys, I noticed that even though 2.6.21 is now in the Lenny repos, the install CD (well, 13 July, at least) still runs 2.6.18. Is there any way to check, before downloading, what version of the kernel the install CD runs? What install disk are you using? The full install set hasn't been updated in a while, but you can get the daily built netinstall or businesscard iso and they use sid's kernel if I'm not mistaken. http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso -cd/ It was the daily build netinstall from 13 July that I downloaded (I guess the builds are made US time, so 14 July wasn't out yet). I checked after booting off the disc - it was 2.6.18 Strange, I used the disc dated July 10 and it booted and installed the 2.6.21 kernel. Are you sure you burned the iso successfully? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny Install CD kernel version.
On Sun July 15 2007 07:53, koffiejunkie wrote: Alan Ianson wrote: On Sun July 15 2007 04:38, koffiejunkie wrote: Hi guys, I noticed that even though 2.6.21 is now in the Lenny repos, the install CD (well, 13 July, at least) still runs 2.6.18. Is there any way to check, before downloading, what version of the kernel the install CD runs? What install disk are you using? The full install set hasn't been updated in a while, but you can get the daily built netinstall or businesscard iso and they use sid's kernel if I'm not mistaken. http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso -cd/ It was the daily build netinstall from 13 July that I downloaded (I guess the builds are made US time, so 14 July wasn't out yet). I checked after booting off the disc - it was 2.6.18 I used the businesscard iso, maybe there is a difference. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny Install CD kernel version.
Alan Ianson wrote: On Sun July 15 2007 07:53, koffiejunkie wrote: I checked after booting off the disc - it was 2.6.18 I used the businesscard iso, maybe there is a difference. I'll give that a try, thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny Install CD kernel version.
On Sun, 15 Jul 2007, koffiejunkie wrote: Alan Ianson wrote: On Sun July 15 2007 07:53, koffiejunkie wrote: I checked after booting off the disc - it was 2.6.18 I used the businesscard iso, maybe there is a difference. I'll give that a try, thanks. for what its worth, i just grabbed both netinst and the buisines card iso files from: http://cdimage.debian.org/cdimage/daily-builds/daily.new/arch-latest/i386/iso-cd/ and both of them contain the 2.6.21 kernel in them. -+- 8 out of 10 Owners who Expressed a Preference said Their Cats Preferred Techno. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny Install CD kernel version.
Jeff D wrote: On Sun, 15 Jul 2007, koffiejunkie wrote: Alan Ianson wrote: On Sun July 15 2007 07:53, koffiejunkie wrote: I checked after booting off the disc - it was 2.6.18 I used the businesscard iso, maybe there is a difference. I'll give that a try, thanks. for what its worth, i just grabbed both netinst and the buisines card iso files from: http://cdimage.debian.org/cdimage/daily-builds/daily.new/arch-latest/i386/iso-cd/ and both of them contain the 2.6.21 kernel in them. I'm not really concerned with which kernel the installer installs. I need the install CD itself to run the 2.6.21 kernel. I just tried today's (15 July) businesscard ISO, booted of it with the following command: expertgui vga=0x342 When the installer came up, I hit Ctrl+Alt+F2 for a console, and did a uname -a. It gave me 2.6.18. This is what I want to check before downloading: which kernel the install CD uses, not which kernel it installs. The reason is that 2.6.21 fixes an ACPI bug that prevents the CPU fan in my notebook from working correctly (if at all), amongst other things. I can install and upgrade the kernel, and that works fine, but I have to set up power management by hand, mostly. I want to see if I install of a disc running 2.6.21, i.e. it should detect and configure ACPI correctly, if it makes any difference to the default setup I get after installation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny Install CD kernel version.
On Sun July 15 2007 14:10, koffiejunkie wrote: I'm not really concerned with which kernel the installer installs. I need the install CD itself to run the 2.6.21 kernel. I just tried today's (15 July) businesscard ISO, booted of it with the following command: expertgui vga=0x342 I wonder if the expertgui option uses the 2.6.18 kernel? I installed with the command expert vga=771 and it booted the 2.6.21 kernel. That may be an oversight.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny Install CD kernel version.
On Sun, 15 Jul 2007, koffiejunkie wrote: Jeff D wrote: On Sun, 15 Jul 2007, koffiejunkie wrote: Alan Ianson wrote: On Sun July 15 2007 07:53, koffiejunkie wrote: I checked after booting off the disc - it was 2.6.18 I used the businesscard iso, maybe there is a difference. I'll give that a try, thanks. for what its worth, i just grabbed both netinst and the buisines card iso files from: http://cdimage.debian.org/cdimage/daily-builds/daily.new/arch-latest/i386/iso-cd/ and both of them contain the 2.6.21 kernel in them. I'm not really concerned with which kernel the installer installs. I need the install CD itself to run the 2.6.21 kernel. I just tried today's (15 July) businesscard ISO, booted of it with the following command: expertgui vga=0x342 When the installer came up, I hit Ctrl+Alt+F2 for a console, and did a uname -a. It gave me 2.6.18. This is what I want to check before downloading: which kernel the install CD uses, not which kernel it installs. The reason is that 2.6.21 fixes an ACPI bug that prevents the CPU fan in my notebook from working correctly (if at all), amongst other things. I can install and upgrade the kernel, and that works fine, but I have to set up power management by hand, mostly. I want to see if I install of a disc running 2.6.21, i.e. it should detect and configure ACPI correctly, if it makes any difference to the default setup I get after installation. are you sure you have the right one? The iso I downladed was built on the 10th. This is from the boot kernel of it: [install.386]$ strings vmlinuz |grep 2.6 2.6.21-2-486 ([EMAIL PROTECTED]) #1 Mon Jun 25 20:09:51 UTC 2007 I just booted up off of that and it booted up to the 2.6.21 kernel -+- 8 out of 10 Owners who Expressed a Preference said Their Cats Preferred Techno. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny Install CD kernel version.
Jeff D wrote: On Sun, 15 Jul 2007, koffiejunkie wrote: When the installer came up, I hit Ctrl+Alt+F2 for a console, and did a uname -a. It gave me 2.6.18. This is what I want to check before downloading: which kernel the install CD uses, not which kernel it installs. are you sure you have the right one? The iso I downladed was built on the 10th. This is from the boot kernel of it: No, mine was built today. I'll look for that one and give it a try. Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
