Bug 519456

That message comes from kernel cryptoAPI when cryptestup tries to configure dm-crypt (here probably IV using sha).

I am not sure if this should be solved in mkinitrd (to properly load generic crypto modules) or directly in kernel but cryptsetup cannot help here.
(It is just first user of cryptoPAI which trigger this message.)

Why is this bug filed against rawhide?  I spent an hour looking for the problem before realizing it was a Fedora 11 problem...

Sorry. It wasn't my intention to set it to rawhide. The Version field in bugzilla is usually set correct by default, and I am pretty sure I didn't change it manually. But apparently I did ...

Changing Version to Fedora 11.

Running a snippet from livecd-iso-to-disk it seems like the problem isn't in rawhide. I will verify on Fedora 11 later.
[root@localhost tmp]# dd if=/dev/null of=crypted count=1 bs=1M seek=1 2> /dev/null
[root@localhost tmp]# loop=$(losetup -f)
[root@localhost tmp]# losetup $loop crypted
[root@localhost tmp]# cryptsetup luksFormat -y -q $loop
Enter LUKS passphrase: 
Verify passphrase: 
Command successful.

A similar issue was reported and fixed on Fedora 9 at bug #442190 (a module-init-tools bug). Should this bug be reassigned to module-init-tools?

I also couldn't reproduce the problem on another Fedora 11 machine. But I know for sure that I see the problem on uptodate Live USBs - I just haven't had time to verify exactly the same commands with exactly the same kernel.

So the problem might be because of the difference between normal mkinitrd and /usr/libexec/mkliveinitrd in combination with the modules listed in the /etc/sysconfig/mkinitrd created by /usr/lib/python2.6/site-packages/imgcreate/live.py

The problem could (in principle) also be restricted to non-PAE kernels.

I see the problem on my Fedora 11 machine, running 2.6.29.6-217.2.16.fc11.i686.PAE and module-init-tools-3.7-9.fc11.i586.

On my case the message appears after initrd had already been ran. From my boot.log:

(in portuguese, sorry)

^[%G            Welcome to ^[[0;34mFedora^[[0;39m
                Press 'I' to enter interactive startup.
Iniciando o udev: ^[%G^[[60G[^[[0;32m  OK  ^[[0;39m]^M
Definindo o nome da máquina blackpad.lan.raisama.net:  ^[[60G[^[[0;32m  OK  ^[[0;39m]^M
mdadm: No arrays found in config file or automatically
modprobe: FATAL: Error inserting padlock_sha (/lib/modules/2.6.29.6-217.2.16.fc11.i686.PAE/kernel/drivers/crypto/padlock-sha.ko): No such device
^M
key slot 0 unlocked.
Command successful.
Configurando o Gerenciamento de Volumes Lógicos:   3 logical volume(s) in volume group "VolGroup00" now active
^[[60G[^[[0;32m  OK  ^[[0;39m]^M
Verificando sistemas de arquivos
/dev/mapper/luks-42593326-2028-449b-94e2-7a7d61f68701: clean, 971754/2632672 files, 8437918/10526215 blocks
/dev/sda1: clean, 44/25896 files, 33856/103424 blocks
/dev/mapper/luks-a9c7af42-e017-45ed-83b6-9eec645710c5: clean, 418079/537504 files, 1593209/2146175 blocks
^[[60G[^[[0;32m  OK  ^[[0;39m]^M
Montando o sistema de arquivos root no modo leitura-escrita:  ^[[60G[^[[0;32m  OK  ^[[0;39m]^M

Weird. This was definitely fixed. I will take a look - is this always on a live CD or regular Fedora too?

Jon.

(In reply to comment #7)
> Weird. This was definitely fixed. I will take a look - is this always on a live
> CD or regular Fedora too?

Here it is a regular Fedora system, not live media.

I get the same error, on up-to-date FC11, when using cryptsetup for the first time. That link in the first post shows exactly what happens and whats necessary for it to be fixed.

	
An additional information: In FC11, the bug only happens if the partition is encrypted after the updates. If the partition is created immediately after the regular installation (without updates) the problem does not happen. I have not done any test with other versions of Fedora or with the live CD.

I still see it on my custom livecd with kernel-2.6.30.8-64.fc11.i586

Removing "need-info". AFAICS there is no open questions - except "does anybody know what is going on".

skiffx: Can you be more specific about what seems to be obvious to you: What the problem is and how it in your opinion should be solved?

I have the same problem on an up-to-date regular F11 i686 VMWare image. /home was set up as encrypted when I performed the installation, with cipher aes-xts-plain. However I added an encrypted swap partition (cipher: aes-cbc-essiv:sha256) afterwards.

There doesn't appear to be any other issues than the error report on boot though.

kernel-PAE-2.6.30.9-102.fc11.i686
cryptsetup-luks-1.0.6-7.fc11.i586

Let's keep an eye on this one. It's not a harmful message at all, it should go away and is caused because the optional hardware module doesn't find a hardware padlock to talk to. It's on my radar.

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

In reply to comment #14:

The bug still exists in FC13.

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

(In reply to comment #16)
> Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
> no longer maintained, which means that it will not receive any further 
> security or bug fix updates. As a result we are closing this bug.
> 
> If you can reproduce this bug against a currently maintained version of 
> Fedora please feel free to reopen this bug against that version.
> 
> Thank you for reporting this bug and we are sorry it could not be fixed.    

The bug still exists in FC13, but I cannot reopen the bug. But now as the bug is closed, all hope is lost. We will never fix that bug until doomsday. What a shame. It's a silly bug, I admit. Anyway EOL for this bug. But the bug is still alive. Pfft. What shall we do. Type stupid long messages? Who knows.

Reopened.

Is it clear exactly when the message is seen? Do you know exactly how it can be reproduced?

My theory is that I see it because some modules have been left out from the livecd "initrd".

Thanks for reopening.

I have it on fresh FC13 install. It occurs right before my encrypted swap is added. /var/log/messages snipplet:

SNIP
Jun 28 07:04:29 localhost kernel: HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Jun 28 07:04:29 localhost kernel: cfg80211: World regulatory domain updated:
Jun 28 07:04:29 localhost kernel:    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jun 28 07:04:29 localhost kernel:    (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jun 28 07:04:29 localhost kernel:    (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Jun 28 07:04:29 localhost kernel:    (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Jun 28 07:04:29 localhost kernel:    (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jun 28 07:04:29 localhost kernel:    (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jun 28 07:04:29 localhost kernel: cfg80211: Calling CRDA for country: DE
Jun 28 07:04:29 localhost kernel: cfg80211: Regulatory domain changed to country: DE
Jun 28 07:04:29 localhost kernel:    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jun 28 07:04:29 localhost kernel:    (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jun 28 07:04:29 localhost kernel:    (5150000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jun 28 07:04:29 localhost kernel:    (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
Jun 28 07:04:29 localhost kernel: hda_codec: ALC268: BIOS auto-probing.
Jun 28 07:04:29 localhost kernel: kjournald starting.  Commit interval 5 seconds
Jun 28 07:04:29 localhost kernel: EXT3-fs (sda3): using internal journal
Jun 28 07:04:29 localhost kernel: EXT3-fs (sda3): mounted filesystem with ordered data mode
Jun 28 07:04:29 localhost kernel: padlock: VIA PadLock not detected.
Jun 28 07:04:29 localhost kernel: padlock: VIA PadLock Hash Engine not detected.
Jun 28 07:04:29 localhost kernel: Adding 4194296k swap on /dev/mapper/cswap.  Priority:-1 extents:1 across:4194296k 
Jun 28 07:04:29 localhost kernel: QEMU Accelerator Module version 1.4.0, Copyright (c) 2005-2008 Fabrice Bellard
SNIP

my /etc/crypttab

cswap   /dev/mapper/vg_system-lv_swap   /dev/urandom    swap,cipher=aes-cbc-essiv:sha256

and my /var/log/boot snipplet

SNIP
Remounting root filesystem in read-write mode:             [  OK  ]
Mounting local filesystems:                                [  OK  ]
Enabling local filesystem quotas:                          [  OK  ]
modprobe: FATAL: Error inserting padlock_sha (/lib/modules/2.6.33.5-124.fc13.x86_64/kernel/drivers/crypto/padlock-sha.ko): No such device

Enabling /etc/fstab swaps:                                 [  OK  ]
Entering non-interactive startup
SNIP

I use

kernel-2.6.33.4-95.fc13.x86_64
cryptsetup-luks-1.1.0-1.fc13.x86_64
cryptsetup-luks-libs-1.1.0-1.fc13.x86_64


hth

I can reproduce this with a fresh install of fc14:

modprobe: FATAL: Error inserting padlock_sha (/lib/modules/2.6.35.6-48.fc14.x86_64/kernel/drivers/crypto/padlock-sha.ko): No such device

"can reproduce" sounds like you do something to trig it. What? Are you loading the module manually? Or does it appear automatically when you run cryptsetup?

It appears automatically at boot time.

Sorry for the bad wording. I am not a native speaker of English.

This is a harmless "error" which is triggered by the module itself. It's not really the fault of the tools, but instead that the module doesn't initialize because the hardware is not present. I am thinking this is a WONTFIX candidate because it results in no actual harm to the system, but I agree it would be nice if the module would e.g. output something indicating why it didn't load.

I'm closing this. I will look at having upstream padlock_sha fixed.

Jon.