Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 519456 - FATAL: Error inserting padlock_sha (.../padlock-sha.ko): No such device
FATAL: Error inserting padlock_sha (.../padlock-sha.ko): No such device
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Jon Masters
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-26 13:11 EDT by Mads Kiilerich
Modified: 2013-02-01 11:08 EST (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-16 01:40:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mads Kiilerich 2009-08-26 13:11:59 EDT
Description of problem:

When using cryptsetup a message
  FATAL: Error inserting padlock_sha (/lib/modules/2.6.30.5-32.fc11.i686.PAE/kernel/drivers/crypto/padlock-sha.ko): No such device
is shown on stderr while 
  padlock: VIA PadLock Hash Engine not detected.
is klogged

cryptsetup is obviously very security sensitive, and it is important that users get a feeling that it is secure. Showing such an error right next to the password prompt gives a lousy user experience and make careful users run away screaming.

The problem is dicussed and apprently solved on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464673


Version-Release number of selected component (if applicable):

cryptsetup-luks-1.0.6-7.fc11.i586
kernel-PAE-2.6.30.5-32.fc11.i686
Comment 1 Milan Broz 2009-08-26 13:26:09 EDT
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.)
Comment 2 Chuck Ebbert 2009-08-31 22:28:34 EDT
Why is this bug filed against rawhide?  I spent an hour looking for the problem before realizing it was a Fedora 11 problem...
Comment 3 Mads Kiilerich 2009-09-01 01:26:41 EDT
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.
Comment 4 Eduardo Habkost 2009-09-01 18:09:04 EDT
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?
Comment 5 Mads Kiilerich 2009-09-01 18:52:33 EDT
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.
Comment 6 Eduardo Habkost 2009-09-01 19:45:11 EDT
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
Comment 7 Jon Masters 2009-09-02 02:09:05 EDT
Weird. This was definitely fixed. I will take a look - is this always on a live CD or regular Fedora too?

Jon.
Comment 8 Eduardo Habkost 2009-09-02 10:22:06 EDT
(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.
Comment 9 skiffx 2009-09-19 14:47:43 EDT
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.
Comment 10 Andre Cruz 2009-10-02 19:14:17 EDT
	
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.
Comment 11 Mads Kiilerich 2009-10-13 10:04:31 EDT
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?
Comment 12 Chris Underhill 2009-12-15 17:49:52 EST
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
Comment 13 Jon Masters 2010-02-25 16:25:45 EST
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.
Comment 14 Bug Zapper 2010-04-28 05:59:41 EDT
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
Comment 15 schlaffi 2010-05-27 13:39:45 EDT
In reply to comment #14:

The bug still exists in FC13.
Comment 16 Bug Zapper 2010-06-28 10:18:54 EDT
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.
Comment 17 schlaffi 2010-06-28 11:00:42 EDT
(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.
Comment 18 Mads Kiilerich 2010-06-28 11:16:23 EDT
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".
Comment 19 schlaffi 2010-06-28 17:19:30 EDT
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
Comment 20 Matthieu Pupat 2010-11-02 21:30:56 EDT
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
Comment 21 Mads Kiilerich 2010-11-03 06:33:40 EDT
"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?
Comment 22 Matthieu Pupat 2010-11-03 09:46:19 EDT
It appears automatically at boot time.

Sorry for the bad wording. I am not a native speaker of English.
Comment 23 Jon Masters 2010-11-16 01:40:23 EST
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.

Note You need to log in before you can comment on or make changes to this bug.