PDA

View Full Version : [ubuntu] Linux kernel 3.4.0 rc5 soon here



Harry33
May 1st, 2012, 02:27 PM
The new linux kernel 3.4.0 rc5 will soon hit the Quantal repos.
This is the second attempt to build it here, though it failed:

https://launchpad.net/ubuntu/quantal/+source/linux/3.4.0-1.2

dino99
May 1st, 2012, 06:25 PM
i386 have failed again :( , python3 will give some headaches for this early alpha.

xebian
May 1st, 2012, 07:41 PM
Hmm..wonders why it's failing. I have compiled src from kernel.org with quantal 4.7 right after rc5 came out successfully.


Linux version 3.4.0-rc5-ik1 (root@kubu1) (gcc version 4.7.0 (Ubuntu/Linaro 4.7.0-4ubuntu2) ) #1 SMP Sun Apr 29 18:02:04 CDT 2012

Maybe the newer "gcc 4:4.7.0-5ubuntu1 " is the reason?

JMB74
May 1st, 2012, 08:11 PM
Hmm..wonders why it's failing.

Buildlog seems to say that the docbook-utils dep couldn't be installed.

I think there was a new tex-common upload at about the same time...

xebian
May 1st, 2012, 10:19 PM
Buildlog seems to say that the docbook-utils dep couldn't be installed.

I think there was a new tex-common upload at about the same time...

I was thinking something connected to kernel patches, and/or compiler/linker flags.

JMB74
May 1st, 2012, 10:23 PM
https://launchpadlibrarian.net/103765039/buildlog_ubuntu-quantal-i386.linux_3.4.0-1.2_FAILEDTOBUILD.txt.gz


Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed.
This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies: docbook-utils : Depends: jadetex but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
apt-get failed.
Package installation failed
Trying to reinstall removed packages:
Trying to uninstall newly installed packages:
Source-dependencies not satisfied; skipping linux ************************************************** **************************** Finished at 20120501-1443 Build needed 00:00:00, 0k disk space

EDIT: Just saw that debian sync is causing dependency probs for now.

VinDSL
May 2nd, 2012, 04:29 AM
The new linux kernel 3.4.0 rc5 will soon hit the Quantal repos.[...]
Good Ol' Mainline Kernel works... ):P



http://vindsl.com/images/vindsl-desktop-1-may-2012-1(650x520).png (http://vindsl.com/images/vindsl-desktop-1-may-2012-1.png)

Harry33
May 2nd, 2012, 07:54 AM
The 3.4.0 rc5 kernel is now in Quantal repos:

https://launchpad.net/ubuntu/quantal/+source/linux/3.4.0-1.2

VinDSL
May 2nd, 2012, 08:38 AM
Beautiful!

Thanks, Harry! I haven't "seen" Plymouth in ages. LoL! :D



http://vindsl.com/images/vindsl-linux-3.4-2-may-2012.png


As usual, everything is working great!

Gotta love these pre-alphas... :guitar:

VinDSL
May 2nd, 2012, 04:15 PM
7 hours later...

Okay, fully updated (another 103 package upgrades) and survived a cold boot.

Time to purge some old kernels. :)

jppr
May 2nd, 2012, 04:35 PM
https://launchpad.net/ubuntu/quantal/+source/linux-meta/3.4.0.1.1

3vi1
May 2nd, 2012, 04:51 PM
Nvidia proprietary blobs appear to not be in love with the new kernel.


Setting up linux-headers-3.4.0-1-generic (3.4.0-1.2) ...
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 3.4.0-1-generic /boot/vmlinuz-3.4.0-1-generic
Error! Bad return status for module build on kernel: 3.4.0-1-generic (x86_64)
Consult /var/lib/dkms/nvidia-current/295.40/build/make.log for more information.
Error! Bad return status for module build on kernel: 3.4.0-1-generic (x86_64)
Consult /var/lib/dkms/nvidia-current-updates/295.40/build/make.log for more information.



In file included from /var/lib/dkms/nvidia-current-updates/295.40/build/nv.c:13:0:
/var/lib/dkms/nvidia-current-updates/295.40/build/nv-linux.h: At top level:
/var/lib/dkms/nvidia-current-updates/295.40/build/nv-linux.h:114:75: fatal error: asm/system.h: No such file or directory
compilation terminated.

Thehumorouscheese
May 2nd, 2012, 04:57 PM
Good Ol' Mainline Kernel works... ):P

http://vindsl.com/images/vindsl-desktop-1-may-2012-1%28650x520%29.png (http://vindsl.com/images/vindsl-desktop-1-may-2012-1.png)

my jaw hit the floor when i saw this screenshot.

nice backround dude! :D

3vi1
May 2nd, 2012, 05:05 PM
my jaw hit the floor when i saw this screenshot.

Vin's always got the best looking screenshots. He's the one that turned me on to using conky - though my desktop still never looks as good as his.

xebian
May 2nd, 2012, 05:18 PM
Quantal seems a bit strange right now.


p linux-image-3.4.0-1-generic - Linux kernel image for version 3.4.0 on 32 bit x86 SMP
p linux-image-3.4.0-1-generic-pae:i386 - Linux kernel image for version 3.4.0 on 32 bit x86 SMP

Not sure if this is just typo or not though I'm betting it is.

Cheesemill
May 2nd, 2012, 05:48 PM
It's a typo, I'm running it now:

root@quantal:/# aptitude search linux-image-3.4
i linux-image-3.4.0-1-generic - Linux kernel image for version 3.4.0 on 32 bit x86 SMP
p linux-image-3.4.0-1-generic-pae:i386 - Linux kernel image for version 3.4.0 on 32 bit x86 SMP
p linux-image-3.4.0-1-virtual - Linux kernel image for version 3.4.0 on 32 bit x86 Virtual Guests
p linux-image-3.4.0-1-virtual:i386 - Linux kernel image for version 3.4.0 on 32 bit x86 Virtual Guests
root@quantal:/# uname -a
Linux quantal 3.4.0-1-generic #2-Ubuntu SMP Tue May 1 13:03:06 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Mathor
May 2nd, 2012, 06:15 PM
I just installed the one from the repos, and it is working perfectly on this machine. :P

cecilpierce
May 2nd, 2012, 07:08 PM
I just installed the one from the repos, and it is working perfectly on this machine. :P

Yea 3.4.0-1 and it had problems with the nvidia-current (295-40). Boots to fail-safe vesa mode with huge graphics :confused:

Back on the old kernel now til some one else has a fix or maybe its me
:P

Bowmore
May 2nd, 2012, 08:24 PM
Right, the new kernel doesn't like nvidia-current. This is due to missing header files for most of the archs.

A workaround is to manually copy those header files from arm to x86:

cd /usr/src/linux-headers-3.4.0-1/arch
sudo cp arm/include/asm/system.h x86/include/asm/
sudo cp arm/include/asm/compiler.h x86/include/asm/
sudo cp arm/include/asm/system_info.h x86/include/asm/
sudo cp arm/include/asm/system_misc.h x86/include/asm/and then reinstall the kernel via synaptic.

Harry33
May 2nd, 2012, 08:41 PM
I am using xserver 1.12.1 from xorg-edgers so I am also using differently built nvidia-current.
It depends on xorg-video-abi-12, for xserver 1.11.4 (precise and quantal ATM) it is xorg-video-abi-11.

Anyways nvidia-current (both 295.40 and the new 302.07) builds fine and works fine with linux kernel 3.4.0-1 (rc5) from quantal repos.

xebian
May 2nd, 2012, 08:43 PM
I haven't been paying much attention lately but now even though I have 64-bit installation the 32-bit packages are showing up and available for installation?

Haven't used a 32-bit ubuntu since 2005 but can @VinDSL confirm if these 64-bit packages are showing up in your 32-bit installation?

No wonder APT seems sluggish lately as it has to fetch and search twice as many packages/indices. I find it absurd to bother with the 32-bits when I have no need for them. Is there a way of setting a flag to ignore them altogether?

Bowmore
May 2nd, 2012, 09:46 PM
@Harry
Ok, but those two nvidia driver versions contain dkms patches for the 3.4 kernel that probably fix this issue for xorg-edgers.

pressureman
May 2nd, 2012, 10:48 PM
I haven't been paying much attention lately but now even though I have 64-bit installation the 32-bit packages are showing up and available for installation?

Do you have 'foreign-architecture i386' in your /etc/dpkg/dpkg.cfg.d/multiarch?

VinDSL
May 2nd, 2012, 11:04 PM
Haven't used a 32-bit ubuntu since 2005 but can @VinDSL confirm if these 64-bit packages are showing up in your 32-bit installation?
Yes, I can see several pages of 64-bit upgrades available, including kernel images & headers.

It does seem (ahem) a bit senseless... :)

xebian
May 2nd, 2012, 11:15 PM
Do you have 'foreign-architecture i386' in your /etc/dpkg/dpkg.cfg.d/multiarch?

Commented this line and apt-get update is now faster without those 32-bit.

Thanks a lot.

xebian
May 2nd, 2012, 11:19 PM
Yes, I can see several pages of 64-bit upgrades available, including kernel images & headers.

It does seem (ahem) a bit senseless... :)

It is. But the master @pressureman showed a way. Comment out this line in /etc/dpkg/dpkg.cfg/multiarch

#foreign-architecture i386 <<== probably amd64 in your case.

then apt-get update to refresh indices. Do a aptitude search 'something' and you can now only see <pkg-name>i386, and less clutter.

xebian
May 2nd, 2012, 11:28 PM
For 64-bit it makes some sense because you can run 32-bit but for 32-bit installation it's absolute nonsense to include 64-bit. I suggest for 32-bit, this should be off by default.

cecilpierce
May 2nd, 2012, 11:37 PM
Right, the new kernel doesn't like nvidia-current. This is due to missing header files for most of the archs.

A workaround is to manually copy those header files from arm to x86:

cd /usr/src/linux-headers-3.4.0-1/arch
sudo cp arm/include/asm/system.h x86/include/asm/
sudo cp arm/include/asm/compiler.h x86/include/asm/
sudo cp arm/include/asm/system_info.h x86/include/asm/
sudo cp arm/include/asm/system_misc.h x86/include/asm/and then reinstall the kernel via synaptic.

Thanks, that fixed it for now, whats next?
:lolflag:

3vi1
May 2nd, 2012, 11:39 PM
I was able to get it running, after copying the headers and fixing nvidia-current.

But... I had to jump back to the 3.2 kernel on my main machine.

Each time I test the 3.4.0-1 kernel, I get a full system freeze (sometimes I can't even ctrl-alt-sysreq-reboot) within a minute or two after signing in. It's odd, because everything seems to work okay, then the system locks hard.

I *think* it's locking when the Ubuntu One syncdaemon kicks in.

Anyone else seeing this?

My sys: x58 mobo, i980x CPU, 12GB RAM, nV GeForce 560 Ti

(3.4 works fine on a second system I'm testing, with all different specs)

pressureman
May 3rd, 2012, 12:25 AM
The package description is wrong on the amd64 package (apt-cache show linux-image-3.4.0-1-generic):



Description-en: Linux kernel image for version 3.4.0 on 32 bit x86 SMP
This package contains the Linux kernel image for version 3.4.0 on
32 bit x86 SMP.


and 'dpkg -l | grep linux-image'


ii linux-image-3.2.0-23-generic 3.2.0-23.36 Linux kernel image for version 3.2.0 on 64 bit x86 SMP
ii linux-image-3.2.0-24-generic 3.2.0-24.37 Linux kernel image for version 3.2.0 on 64 bit x86 SMP
ii linux-image-3.4.0-1-generic 3.4.0-1.2 Linux kernel image for version 3.4.0 on 32 bit x86 SMP
ii linux-image-generic 3.4.0.1.1 Generic Linux kernel image


Even though it sounds like a wild ride, I don't usually mix and match 64 and 32 bit kernels on my box.

pressureman
May 3rd, 2012, 12:32 AM
It is. But the master @pressureman showed a way. Comment out this line in /etc/dpkg/dpkg.cfg/multiarch

#foreign-architecture i386 <<== probably amd64 in your case.

then apt-get update to refresh indices. Do a aptitude search 'something' and you can now only see <pkg-name>i386, and less clutter.

There's no reason whatsoever to have 'foreign-architecture amd64' on a 32-bit machine, as they are not forwards-compatible with 64 bit arch. A 64 bit application simply will not run on a 32 bit machine.

Remember that you'll need 'foreign-architecture i386' if you want to install closed-source, 32 bit apps like Skype on your 64 bit machine.

VinDSL
May 3rd, 2012, 12:43 AM
I purged all unused kernels, this morning.

My options are a little sparse, right now. LoL! :D



vindsl@Zuul:~$ dpkg -l | grep linux-image
ii linux-image-3.2.0-14.dmz.1-liquorix-686 3.2.0-19 Linux 3.2.0 for modern PCs
ii linux-image-3.4.0-1-generic-pae 3.4.0-1.2 Linux kernel image for version 3.4.0 on 32 bit x86 SMP

Mathor
May 3rd, 2012, 01:46 AM
I'm so glad I don't have nvidia sometimes. 3.4.0-1 works fine. I'm not using the edgers ppa, either.

Linus Torvalds said there were some new issues that came with this release (rc5). I'm looking to linux 3.5.

Xgen
May 3rd, 2012, 07:29 PM
I'm so glad I don't have nvidia sometimes. 3.4.0-1 works fine.

Are you using the propriety driver? Tried AMD 12.3 and 12.4, but no success. It only logins to 2d. The 3.3 kernel works fine with the propriety drivers.

pressureman
May 7th, 2012, 10:12 AM
Anyone else suddenly start having boot problems with this linux-image-3.4.0-1-generic? I installed it last week, and had a couple of boot hangs, but otherwise it was working.

This morning however, my Thinkpad T500 was consistently freezing, just before lightdm appeared - sometimes I'd get a mouse cursor just before it hung. Booting failsafe mode (and continuing with normal boot once prompted) worked fine - but of course was running in VESA mode. So it would appear to be something gfx-related (running "Integrated Graphics Chipset: Intel(R) GM45" here).

I booted the older 3.2.0 kernel, and had no problems. It's weird that this has only just started happening several days after installing 3.4.0.

Harry33
May 7th, 2012, 11:36 AM
Anyone else suddenly start having boot problems with this linux-image-3.4.0-1-generic? I installed it last week, and had a couple of boot hangs, but otherwise it was working.

This morning however, my Thinkpad T500 was consistently freezing, just before lightdm appeared - sometimes I'd get a mouse cursor just before it hung. Booting failsafe mode (and continuing with normal boot once prompted) worked fine - but of course was running in VESA mode. So it would appear to be something gfx-related (running "Integrated Graphics Chipset: Intel(R) GM45" here).

I booted the older 3.2.0 kernel, and had no problems. It's weird that this has only just started happening several days after installing 3.4.0.

This is perhaps in a wrong thread, as this concerns only the official 3.4.0 kernel in Quantal repos.
Anyways, it would help to know which updates you run before these problems with booting.

pressureman
May 7th, 2012, 12:05 PM
This is perhaps in a wrong thread, as this concerns only the official 3.4.0 kernel in Quantal repos.
Anyways, it would help to know which updates you run before these problems with booting.

It's simply a fully up to date quantal amd64 install. At first I suspected libxv1, as that was one of the most recent updates, so I downgraded that, but to no avail.

It's not a big deal, as I have a workaround for now. Hopefully the next 3.4.0 rc will fix it. I was just curious if anybody else had noticed the same symptoms.

jerrylamos
May 7th, 2012, 12:53 PM
? One of my pc's, the tower, running -2D, updated to 3.4. It has an ATI radeon xpress 200 and booted to black screen no cli until repeated rescue mode "fix broken packages" got it going, running O.K. (for a pre-Alpha).

This notebook running quantal lubuntu, is still at 3.2 after update/upgrade.

My netbook, running -2D, repeated update/upgrade still at 3.2.

?

Now I know I could fiddle around and get 3.4 going, I did that on another install, but I'm really trying to test whatever the usual update/upgrades do, i.e. I run whatever ubuntu throws over the wall with a rock tied to it.

Jerry

p.s. updated my wide screen notebook with 1280x1024 external monitor and update brought in 3.4 running O.K. Advanced Micro Devices [AMD] nee ATI Wrestler [Radeon HD 6310]. I'll give another go on my netbook and lubuntu quantal tomorrow to see if 3.4 comes in on them.

xebian
May 7th, 2012, 04:32 PM
It's simply a fully up to date quantal amd64 install. At first I suspected libxv1, as that was one of the most recent updates, so I downgraded that, but to no avail.

It's not a big deal, as I have a workaround for now. Hopefully the next 3.4.0 rc will fix it. I was just curious if anybody else had noticed the same symptoms.

Not seeing them here with 302.07, and also rc6 is working fine too.

VinDSL
May 8th, 2012, 03:01 AM
Not seeing them here with 302.07, and also rc6 is working fine too.
Dittos... ;)

Miykel
May 8th, 2012, 10:13 AM
G'Day Could someone please explain this, I seem to have version 3.4.0.1.3 along with all these other kernels, should I remove the older ones.

miykel@miykel:~$ dpkg -l | grep linux-image
rc linux-image-3.2.0-23-generic 3.2.0-23.36 Linux kernel image for version 3.2.0 on 64 bit x86 SMP
ii linux-image-3.4.0-1-generic 3.4.0-1.3 Linux kernel image for version 3.4.0 on 64 bit x86 SMP
rc linux-image-3.4.0-999-generic 3.4.0-999.201205070447 Linux kernel image for version 3.4.0 on 32 bit x86 SMP
ii linux-image-generic 3.4.0.1.1 Generic Linux kernel image

Kind Regards Miykel

pressureman
May 8th, 2012, 10:18 AM
The 'rc' at the start of the line indicates 'removed' and 'configured', so the bulk of the backage is already removed - only config files remain. You can 'sudo apt-get purge foopackagename' to clean this up.

VinDSL
May 9th, 2012, 02:15 AM
I always keep a fallback *DISTRO* on this machine (in a separate partition)... currently, Ubu 10.10 (even though it's been orphaned). After all, I *need* something to boot into, in case of Unity borkage... and to test Conky scripts in Gnome 2. :D

As far as "testing" kernels are concerned... I usually wait until I've collected 3-4 of them (about 7-10 days), keep the latest and greatest kernel (singular), then I purge the old ones, and start the cycle all over again.

Thus, if you will, I always maintain:

The latest "testing" kernel
A few 7-10 days old kernels
And, a fallback distro
.
I digress: I have any number of bootable thumb-drives (with persistence) laying around, but using them adds a level of unnecessary complexity. I mostly use them for "testing" my lappy and netbook, and don't like to boot my desktop machine with them.

Anyway... it's really up to you. Loading up your HD with kernels won't hurt anything, but I try to keep a handle on the cruft, you know?!?!? ;)