Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
On Sat, 8 May 2010 00:04:43 +0200, Dieter Plaetinck <dieter@plaetinck.be>
wrote:
On Sun, 02 May 2010 17:49:13 +0200
Pierre Schmitz <pierre@archlinux.de> wrote:
This new kernel just exports some additional symbols for aufs2 which was updated to a new snapshot. This should hopefully fix some issues with the .33 kernel and aufs. Related aufs packages are: aufs2 2.6.33_20100425-2 and aufs2-util 20100422-1
In addition to regular sign-off some feedback about aufs would be nice; especially if you use archiso.
http://build.archlinux.org/isos/archlinux-2010.05.07-netinstall-i686.iso boots fine on my system. signoff i686.
once i have rebuilt images (with correct copyright statement) i will let the community test, then you'll have a bit more feedback about how well it works ;)
Dieter
It seems to be fine in x86_64 and the aufs bugs are confirmed to be fixed with this version. So, I'll move these to core/extra. Hello,
On Sunday 09 of May 2010 15:55:17 Pierre Schmitz wrote: please just test a bit more the new kernel, I have just rebooted to the new 2.6.33.3-2 kernel and got kernel panic on Init: ..something about missing symbols, failed exec and 52 - I didn't take notes of that and don't know if it's logged somewhere (?) I'm using [testing], i686, and encrypted disk, but this probably occurred before this. I'll retest when I have time.. Anybody else experiencing this? Thanks and have a nice day Mark -- Marek Otahal :o)
On Sun, 9 May 2010 19:20:31 +0200, Marek Otahal <markotahal@gmail.com> wrote:
It seems to be fine in x86_64 and the aufs bugs are confirmed to be fixed with this version. So, I'll move these to core/extra. Hello, please just test a bit more the new kernel, I have just rebooted to the new 2.6.33.3-2 kernel and got kernel panic on Init: ..something about missing symbols, failed exec and 52 - I didn't take notes of that and don't know if it's logged somewhere (?) I'm using [testing], i686, and encrypted disk, but this probably occurred before this. I'll retest when I have time.. Anybody else experiencing this?
Thanks and have a nice day Mark
I noticed the same. But this is caused by the mkinitcpio update and not the kernel. In my case "logo.nologo" in the kernel parameter line was causing this. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 09.05.2010 19:23, schrieb Pierre Schmitz:
I noticed the same. But this is caused by the mkinitcpio update and not the kernel. In my case "logo.nologo" in the kernel parameter line was causing this.
That is plan bullshit. The mkinitcpio update didn't even _touch_ the init file, it is entirely unchanged.
Am 09.05.2010 19:37, schrieb Thomas Bächler:
Am 09.05.2010 19:23, schrieb Pierre Schmitz:
I noticed the same. But this is caused by the mkinitcpio update and not the kernel. In my case "logo.nologo" in the kernel parameter line was causing this.
That is plan bullshit. The mkinitcpio update didn't even _touch_ the init file, it is entirely unchanged.
Okay, gcc 4.5.0 still fucks up, I am pushing a new mkinitcpio-busybox directly to core, built with -O0 this time, as this will keep breaking people's systems.
On Sunday 09 May 2010 23:22:19 Thomas Bächler wrote:
Am 09.05.2010 19:37, schrieb Thomas Bächler:
Am 09.05.2010 19:23, schrieb Pierre Schmitz:
I noticed the same. But this is caused by the mkinitcpio update and not the kernel. In my case "logo.nologo" in the kernel parameter line was causing this.
That is plan bullshit. The mkinitcpio update didn't even _touch_ the init file, it is entirely unchanged.
Okay, gcc 4.5.0 still fucks up, I am pushing a new mkinitcpio-busybox directly to core, built with -O0 this time, as this will keep breaking people's systems.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43987 is that related? -- Regards Shridhar
On Sunday 09 of May 2010 19:52:19 Thomas Bächler wrote:
Am 09.05.2010 19:37, schrieb Thomas Bächler:
Am 09.05.2010 19:23, schrieb Pierre Schmitz:
I noticed the same. But this is caused by the mkinitcpio update and not the kernel. In my case "logo.nologo" in the kernel parameter line was causing this.
That is plan bullshit. The mkinitcpio update didn't even _touch_ the init file, it is entirely unchanged.
Okay, gcc 4.5.0 still fucks up, I am pushing a new mkinitcpio-busybox directly to core, built with -O0 this time, as this will keep breaking people's systems.
I'm not sure if my mirrors are synced, but now probably yes..i have: mkinitcpio 0.6.4-1 mkinitcpio-busybox 1.16.1-3 the problem on boot still appears, maybe it's slightly different. It says: Loading initramfs Starting udevd Done /Init: export: line 52: ...unreadable chars.. : bad variable name Kernel panic.... Removing logo.nologo boot param solves the problem. Thank you -- Marek Otahal :o)
On 05/10/2010 12:57 PM, Marek Otahal wrote:
On Sunday 09 of May 2010 19:52:19 Thomas Bächler wrote:
Am 09.05.2010 19:37, schrieb Thomas Bächler:
Am 09.05.2010 19:23, schrieb Pierre Schmitz:
I noticed the same. But this is caused by the mkinitcpio update and not the kernel. In my case "logo.nologo" in the kernel parameter line was causing this.
That is plan bullshit. The mkinitcpio update didn't even _touch_ the init file, it is entirely unchanged.
Okay, gcc 4.5.0 still fucks up, I am pushing a new mkinitcpio-busybox directly to core, built with -O0 this time, as this will keep breaking people's systems.
I'm not sure if my mirrors are synced, but now probably yes..i have: mkinitcpio 0.6.4-1 mkinitcpio-busybox 1.16.1-3
the problem on boot still appears, maybe it's slightly different. It says: Loading initramfs Starting udevd Done /Init: export: line 52: ...unreadable chars.. : bad variable name Kernel panic....
Removing logo.nologo boot param solves the problem.
Thank you
did you forgot to regenerate initrd? -- Ionut
On Monday 10 of May 2010 12:11:28 Ionut Biru wrote:
On 05/10/2010 12:57 PM, Marek Otahal wrote:
On Sunday 09 of May 2010 19:52:19 Thomas Bächler wrote:
Am 09.05.2010 19:37, schrieb Thomas Bächler:
Am 09.05.2010 19:23, schrieb Pierre Schmitz:
I noticed the same. But this is caused by the mkinitcpio update and not the kernel. In my case "logo.nologo" in the kernel parameter line was causing this.
That is plan bullshit. The mkinitcpio update didn't even _touch_ the init file, it is entirely unchanged.
Okay, gcc 4.5.0 still fucks up, I am pushing a new mkinitcpio-busybox directly to core, built with -O0 this time, as this will keep breaking people's systems.
I'm not sure if my mirrors are synced, but now probably yes..i have: mkinitcpio 0.6.4-1 mkinitcpio-busybox 1.16.1-3
the problem on boot still appears, maybe it's slightly different. It says: Loading initramfs Starting udevd Done /Init: export: line 52: ...unreadable chars.. : bad variable name Kernel panic....
Removing logo.nologo boot param solves the problem.
Thank you
did you forgot to regenerate initrd?
Oh, my bad.. of course I didn't regenerate it. Problem solved. Thank you for pointing me in the good direction. -- Marek Otahal :o)
Am 09.05.2010 19:23, schrieb Pierre Schmitz:
please just test a bit more the new kernel, I have just rebooted to the new 2.6.33.3-2 kernel and got kernel panic on Init: ..something about missing symbols, failed exec and 52 - I didn't take notes of that and don't know if it's logged somewhere (?) I'm using [testing], i686, and encrypted disk, but this probably occurred before this.
Wow, this is so helpful, what about writing it down?
On Sunday 09 of May 2010 19:23:28 Pierre Schmitz wrote:
On Sun, 9 May 2010 19:20:31 +0200, Marek Otahal <markotahal@gmail.com>
wrote:
It seems to be fine in x86_64 and the aufs bugs are confirmed to be
fixed
with this version. So, I'll move these to core/extra.
Hello, please just test a bit more the new kernel, I have just rebooted to the new 2.6.33.3-2 kernel and got kernel panic on Init: ..something about
missing
symbols, failed exec and 52 - I didn't take notes of that and don't know if it's logged somewhere (?) I'm using [testing], i686, and encrypted disk, but this probably
occurred
before this. I'll retest when I have time.. Anybody else experiencing this?
Thanks and have a nice day Mark
I noticed the same. But this is caused by the mkinitcpio update and not the kernel. In my case "logo.nologo" in the kernel parameter line was causing this.
Pierre: hmm, thanks for a constructive idea, yes I'm using logo.nologo boot param and I did update mkinitcpio recently. I'll try booting without the parameter. Thomas: Why such an unfriendly tone.. Anyways, I did write it down and it goes: Loading initramfs Starting udevd Done /Init: export: line 52: <some unreadable characters> Variable name missing... Thank you both for looking at this. -- Marek Otahal :o)
Am 09.05.2010 20:03, schrieb Marek Otahal:
Thomas: Why such an unfriendly tone.. Anyways, I did write it down and it goes: Loading initramfs Starting udevd Done /Init: export: line 52: <some unreadable characters> Variable name missing...
Thank you both for looking at this.
I sincerely apologize, that was entirely uncalled for. It seems gcc screwed up, see my latest post here.
I sincerely apologize, that was entirely uncalled for. It seems gcc screwed up, see my latest post here. not a problem :) I'm glad the bug is fixed and my systems boot again. Thank you! --
Marek Otahal :o)
On Sun, May 9, 2010 at 12:03 PM, Marek Otahal <markotahal@gmail.com> wrote:
Loading initramfs Starting udevd Done /Init: export: line 52: <some unreadable characters> Variable name missing...
You're not the only one seeing it: http://bugs.archlinux.org/task/19403 -- Byron Clark
On 05/09/2010 06:20 PM, Marek Otahal wrote:
On Sat, 8 May 2010 00:04:43 +0200, Dieter Plaetinck <dieter@plaetinck.be>
wrote:
On Sun, 02 May 2010 17:49:13 +0200
Pierre Schmitz <pierre@archlinux.de> wrote:
This new kernel just exports some additional symbols for aufs2 which was updated to a new snapshot. This should hopefully fix some issues with the .33 kernel and aufs. Related aufs packages are: aufs2 2.6.33_20100425-2 and aufs2-util 20100422-1
In addition to regular sign-off some feedback about aufs would be nice; especially if you use archiso.
http://build.archlinux.org/isos/archlinux-2010.05.07-netinstall-i686.iso boots fine on my system. signoff i686.
once i have rebuilt images (with correct copyright statement) i will let the community test, then you'll have a bit more feedback about how well it works ;)
Dieter
It seems to be fine in x86_64 and the aufs bugs are confirmed to be fixed with this version. So, I'll move these to core/extra. Hello,
On Sunday 09 of May 2010 15:55:17 Pierre Schmitz wrote: please just test a bit more the new kernel, I have just rebooted to the new 2.6.33.3-2 kernel and got kernel panic on Init: ..something about missing symbols, failed exec and 52 - I didn't take notes of that and don't know if it's logged somewhere (?) I'm using [testing], i686, and encrypted disk, but this probably occurred before this. I'll retest when I have time.. Anybody else experiencing this?
Thanks and have a nice day Mark
If you have something like radeon.modeset=1 in your kernel line, remove that, that caused me some trouble and I got a kernel panic during startup with this message: "/init: export: line 52: (garbled chars): bad variable Kernel panic - not syncing: Attempted to kill init!" -- Mauro Santos
participants (7)
-
Byron Clark
-
Ionut Biru
-
Marek Otahal
-
Mauro Santos
-
Pierre Schmitz
-
Shridhar Daithankar
-
Thomas Bächler