>> No more luck here : I just installed the 138-1 version and the boot
>> sequence still doesn't ask for the passphrase.
>
> After installing the new version of udev, you will also need to update your
> initramfs (sudo update-initramfs -u -k 2.6.28-8-generic).
>
Ok, I'll try that. Thanks.
On the other hand, I installed the new version of udev through apt-get
dist-upgrade, so it's very much possible that initramfs is already
up-to-date, but I'll try nevertheless.
>> Also, until now I could easily fall back to an old kernel (2.6.28-5) and
>> continue to use my machine without much trouble. But with the 138-1
>> version, the udevd daemon eats 40-50% CPU continuously (the disk LED
>> blinks but no disk activity can be heard), and the whole machine is
>> quite unstable (fortunately, the consoles still work). Is it possible
>> that a mismatch between kernel and udev causes this problem ?
>
> That sounds like quite another matter; I'll defer to Scott here.
I rebooted several times to verify the behavior, and here how it goes :
- boot with kernel 2.6.26-5 (nosplash)
- ask for passphrase
- boot continues a while then stops (disk LED blinks but no hearable
disk activity)
- wait some minutes
- me hit Ctrl+C => nothing
- me hit Ctrl+Alt+Del => a warning appear briefly about a killed process
- boot continue but / is mounted as read-only
Is there a way to found which process hang during the boot ?
>> No more luck here : I just installed the 138-1 version and the boot
>> sequence still doesn't ask for the passphrase.
>
> After installing the new version of udev, you will also need to update your
> initramfs (sudo update-initramfs -u -k 2.6.28-8-generic).
>
Ok, I'll try that. Thanks.
On the other hand, I installed the new version of udev through apt-get
dist-upgrade, so it's very much possible that initramfs is already
up-to-date, but I'll try nevertheless.
>> Also, until now I could easily fall back to an old kernel (2.6.28-5) and
>> continue to use my machine without much trouble. But with the 138-1
>> version, the udevd daemon eats 40-50% CPU continuously (the disk LED
>> blinks but no disk activity can be heard), and the whole machine is
>> quite unstable (fortunately, the consoles still work). Is it possible
>> that a mismatch between kernel and udev causes this problem ?
>
> That sounds like quite another matter; I'll defer to Scott here.
I rebooted several times to verify the behavior, and here how it goes :
- boot with kernel 2.6.26-5 (nosplash)
- ask for passphrase
- boot continues a while then stops (disk LED blinks but no hearable
disk activity)
- wait some minutes
- me hit Ctrl+C => nothing
- me hit Ctrl+Alt+Del => a warning appear briefly about a killed process
- boot continue but / is mounted as read-only
Is there a way to found which process hang during the boot ?