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

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.

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.