[arch-dev-public] [signoff] mkinitcpio 0.5.29-1
And yet another bugfix release of the old branch: udev 150-1 removed Arch's custom resolve-modalias binary in favor of modprobe --resolve-alias. mkinitcpio was broken by that, this version fixes it.
Am 24.01.2010 15:03, schrieb Thomas Bächler:
And yet another bugfix release of the old branch: udev 150-1 removed Arch's custom resolve-modalias binary in favor of modprobe --resolve-alias. mkinitcpio was broken by that, this version fixes it.
Okay, spoke too soon. klibc's fstype was used for autodetection, but it segfaulted on mounted ext4 filesystems. I merged a commit from the kill-klibc branch that will use blkid. So, forget 0.5.29, try 0.5.30.
On Sun, Jan 24, 2010 at 8:17 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 24.01.2010 15:03, schrieb Thomas Bächler:
And yet another bugfix release of the old branch: udev 150-1 removed Arch's custom resolve-modalias binary in favor of modprobe --resolve-alias. mkinitcpio was broken by that, this version fixes it.
Okay, spoke too soon. klibc's fstype was used for autodetection, but it segfaulted on mounted ext4 filesystems. I merged a commit from the kill-klibc branch that will use blkid. So, forget 0.5.29, try 0.5.30.
Signoff i686. -Dan
On Sun, Jan 24, 2010 at 11:36 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Sun, Jan 24, 2010 at 8:17 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 24.01.2010 15:03, schrieb Thomas Bächler:
And yet another bugfix release of the old branch: udev 150-1 removed Arch's custom resolve-modalias binary in favor of modprobe --resolve-alias. mkinitcpio was broken by that, this version fixes it.
Okay, spoke too soon. klibc's fstype was used for autodetection, but it segfaulted on mounted ext4 filesystems. I merged a commit from the kill-klibc branch that will use blkid. So, forget 0.5.29, try 0.5.30.
Signoff i686.
-Dan
another i686 signoff (with lvm hook).
Am Sun, 24 Jan 2010 15:17:33 +0100 schrieb Thomas Bächler <thomas@archlinux.org>:
Am 24.01.2010 15:03, schrieb Thomas Bächler:
And yet another bugfix release of the old branch: udev 150-1 removed Arch's custom resolve-modalias binary in favor of modprobe --resolve-alias. mkinitcpio was broken by that, this version fixes it.
Okay, spoke too soon. klibc's fstype was used for autodetection, but it segfaulted on mounted ext4 filesystems. I merged a commit from the kill-klibc branch that will use blkid. So, forget 0.5.29, try 0.5.30.
My desktop is broken with mkinitcpio 0.5.30 and ext4 and / and /home! I have to find 0.5.28 tomorrow to make it boot again. this is a stopper! -Andy
Update: I downgraded to mkinitcpio 0.5.28 and this didn't fix it. Downgrading udev+module-init-tools made it boot again. -Andy
Am 25.01.2010 22:53, schrieb Andreas Radke:
My desktop is broken with mkinitcpio 0.5.30 and ext4 and / and /home! I have to find 0.5.28 tomorrow to make it boot again.
this is a stopper!
In what great detail you describe the nature of your problem is truely astonishing.
On Tue, 26 Jan 2010, Thomas Bächler wrote:
In what great detail you describe the nature of your problem is truely astonishing.
Sry. I haven't had the time yesterday to investigate this more. I just wanted to warn to prevent you moving the packages. Today before work I downgraded udev to 149 and to module-init-tools from core repo and this solved the booting issue for me. I was put into rescue shell because the filesystem had a mounting time from the future. We had this in the past in our initscripts due to an unwanted "&" somewhere. Checking the logs shows that kernel log is active and boot process goes further without any weird msg. It just doesn't print anything to the screen. After long tme waiting a login prompt comes up but no filesystem seems mounted. My / and /home are both ext4. I also have reiserfs for my chroot disc and /tmpfs for /tmp and nfs for storage. Maybe you have an idea how we can investigate it further when I will come home. -Andy
On 26/01/10 20:06, Andreas Radke wrote:
Today before work I downgraded udev to 149 and to module-init-tools from core repo and this solved the booting issue for me.
Did you really require to downgrade both of these or have you just not confirmed yet? The module-init-tools in [testing] is just a rebuild to fix a man page. Allan
I didn't know what the change in module-init-tools was. So I downgraded it as well. I haven't tested it out but I expect udev to be the breaker. -Andy
Am 26.01.2010 13:36, schrieb Andreas Radke:
I didn't know what the change in module-init-tools was. So I downgraded it as well. I haven't tested it out but I expect udev to be the breaker.
-Andy
Okay, I shall move mkinitcpio then, the fixes are small but rather useful.
Am 26.01.2010 11:06, schrieb Andreas Radke:
On Tue, 26 Jan 2010, Thomas Bächler wrote:
In what great detail you describe the nature of your problem is truely astonishing.
Sry. I haven't had the time yesterday to investigate this more. I just wanted to warn to prevent you moving the packages.
Today before work I downgraded udev to 149 and to module-init-tools from core repo and this solved the booting issue for me. I was put into rescue shell because the filesystem had a mounting time from the future. We had this in the past in our initscripts due to an unwanted "&" somewhere.
So actually this has nothing to do with mkinitcpio at all. You know, the differences between 0.5.28 and 0.5.30 are microscopic and shouldn't actually break anything.
participants (5)
-
Allan McRae
-
Andreas Radke
-
Dan McGee
-
Eric Bélanger
-
Thomas Bächler