headers
roconnor | 7 Aug 2009 03:47
Picon

My new problem with running losetup at boot time for encrypted root.

I'm running an encrypted root Kubuntu system.  Yesterday I upgraded to 
Kubuntu 9.04 thus moving from a 2.6.27 to a 2.6.28 kernel.  I understand 
the problem with the new kernel, and have download a proper kernel from 
<http://ubuntu.cern.ch>, so this is not my problem.  I am running loop-aes 
version 3.2f-1cern1+2.6.28-14.47.

I have added an losetup command in a custom
/etc/initramfs-tools/scripts/local-top/loop_aes file.  After doing some 
sanity checking the last line in my file is:

/sbin/losetup -v -T -e AES256 -G / -K /keyfile.gpg -s [CENSORED] /dev/loop0 /dev/sda

Please note that I have successfully been using this setup for around 2 
years before now. (Techinically I added the `-v' and `-T' flags today. 
The `-v' didn't seem to add any information).

After the update, when I get to this point in the boot sequence, the 
command no longer prompts for a Password.  Instead it now immediately 
fails with a gpg decryption failed error, the same error you get if you 
don't answer the password correctly.

After this failure I drop down into busybox (because it times out wating 
for the /dev/loop0 device which is the root device).  The strange bit is 
that in busybox I can type in that exact losetup command and it works 
properly.  It prompts for my password, and creates the loop device 
properly.  I can exit busybox and then booting continues normally.

I also tried adding the flag `-p0' to the losetup command.  This also 
works.  Of course, there is no prompt, and the password appears in plain 
text on the console.  Obviously that isn't an acceptable solution.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jari Ruusu | 7 Aug 2009 08:20
Picon

Re: My new problem with running losetup at boot time for encryptedroot.

roconnor <at> theorem.ca wrote:
> I also tried adding the flag `-p0' to the losetup command.  This also
> works.  Of course, there is no prompt, and the password appears in plain
> text on the console.  Obviously that isn't an acceptable solution.

At first I thought this could be library dependency problem, but if -p0
works, that means losetup and gpg library dependencies are OK.

> I guess that there is something strange going on between how losetup calls
> gnupg and how gnupg gets and manipluates the console to prompt for and get
> the password (without echoing to the console), but I really don't know how
> to proceed to debugging this.  Maybe someone more familiar with losetup
> and the linux boot process may have some idea what may have changed in
> this Kubuntu upgrade that would cause the problem I described.

Password prompt comes from losetup that calls getpass() library funtion.
Then losetup starts gpg and sends the password to gpg via a pipe.

Can you make sure that a /dev/tty device node exists at the time losetup
runs in your boot script? If I remember correctly, getpass() library funtion
opens /dev/tty device.

What happens if you add this line to your boot script right before losetup
is called?

    mknod /dev/tty c 5 0

Plan B:
~~~~~~~
Can you change one line of util-linux mount/lomount.c main() function, so
(Continue reading)

Permalink | Reply | 1 comment |
headers
roconnor | 8 Aug 2009 04:07
Picon

Re: My new problem with running losetup at boot time for encryptedroot.

On Fri, 7 Aug 2009, Jari Ruusu wrote:

> roconnor <at> theorem.ca wrote:
>> I guess that there is something strange going on between how losetup calls
>> gnupg and how gnupg gets and manipluates the console to prompt for and get
>> the password (without echoing to the console), but I really don't know how
>> to proceed to debugging this.  Maybe someone more familiar with losetup
>> and the linux boot process may have some idea what may have changed in
>> this Kubuntu upgrade that would cause the problem I described.
>
> Password prompt comes from losetup that calls getpass() library funtion.
> Then losetup starts gpg and sends the password to gpg via a pipe.
>
> Can you make sure that a /dev/tty device node exists at the time losetup
> runs in your boot script? If I remember correctly, getpass() library funtion
> opens /dev/tty device.

Apparently the /dev/tty didn't exist at the time losetup was called.  I 
added code to wait for /dev/tty in addition to the wait for /dev/sda.  I 
suppose in principle I should wait for /dev/loop0 as well.

Now it works again. The wait time is not actually perceivable by me. 
Thanks for your quick help.

--

-- 
Russell O'Connor                                      <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gabriel VLASIU | 28 Aug 2009 21:54

loop_end_io_transfer


Hi!

I receive this error then I try to mount a encrypted loop-AES partition:

loop0: loop_end_io_transfer err=-95 bi_rw=0x5

For all others encrypted partitions I do not receive this error. Can be 
ignored? It is safe to stick for now with this kernel?

kernel: 2.6.18-164.el5_3g.AES (RHEL 5.4 beta, compiled from sources at:
        http://people.redhat.com/dzickus/el5/164.el5/src/kernel-2.6.18-164.el5.src.rpm)
loop-AES: 3.2g

Gabriel

--

-- 

// Gabriel VLASIU
//
// OpenGPG-KeyID      : 0xE684206E
// OpenGPG-Fingerprint: 0C3D 9F8B 725D E243 CB3C 8428 796A DB1F E684 206E
// OpenGPG-URL        : http://www.vlasiu.net/public.key
Permalink | Reply | 3 comments |
headers
Gabriel VLASIU | 28 Aug 2009 23:18

Re: loop_end_io_transfer


On Fri, 28 Aug 2009, Gabriel VLASIU wrote:

> I receive this error then I try to mount a encrypted loop-AES partition:
> 
> loop0: loop_end_io_transfer err=-95 bi_rw=0x5
> 
> For all others encrypted partitions I do not receive this error. Can be 
> ignored? It is safe to stick for now with this kernel?
> 
> kernel: 2.6.18-164.el5_3g.AES (RHEL 5.4 beta, compiled from sources at:
>         http://people.redhat.com/dzickus/el5/164.el5/src/kernel-2.6.18-164.el5.src.rpm)
> loop-AES: 3.2g

OK, I thing I know why this error occur.

I use loop0 to mount a partition on top of raid5 array (software). 
File-system is xfs. When partition is about to be mounted kernel xfs module 
want to enable barriers and fail and continue with barriers disabled.
If I mount the partition with an explicit "nobarrier" option, the error is 
gone.

# losetup -F /dev/loo0                       <--- no error reported
# mount /dev/loop0 /mnt/qwer                 <--- error reported
# mount -o barrier /dev/loop0 /mnt/qwer      <--- error reported
# mount -o nobarrier /dev/loop0 /mnt/qwer    <--- no error reported

All other partitions are "normal" ones and barrier can be enabled for 
them (well, at least with this kernel - I've seen the same behavior in 
2.6.30 from Fedora but not in the previous ones).
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jari Ruusu | 29 Aug 2009 14:46
Picon

Re: loop_end_io_transfer

Gabriel VLASIU wrote:
> On Fri, 28 Aug 2009, Gabriel VLASIU wrote:
> > I receive this error then I try to mount a encrypted loop-AES partition:
> >
> > loop0: loop_end_io_transfer err=-95 bi_rw=0x5
> >
> > For all others encrypted partitions I do not receive this error. Can be
> > ignored? It is safe to stick for now with this kernel?
> >
> > kernel: 2.6.18-164.el5_3g.AES (RHEL 5.4 beta, compiled from sources at:
> >         http://people.redhat.com/dzickus/el5/164.el5/src/kernel-2.6.18-164.el5.src.rpm)
> > loop-AES: 3.2g
> 
> OK, I thing I know why this error occur.
> 
> I use loop0 to mount a partition on top of raid5 array (software).
> File-system is xfs. When partition is about to be mounted kernel xfs module
> want to enable barriers and fail and continue with barriers disabled.
> If I mount the partition with an explicit "nobarrier" option, the error is
> gone.
> 
> # losetup -F /dev/loo0                       <--- no error reported
> # mount /dev/loop0 /mnt/qwer                 <--- error reported
> # mount -o barrier /dev/loop0 /mnt/qwer      <--- error reported
> # mount -o nobarrier /dev/loop0 /mnt/qwer    <--- no error reported
> 
> All other partitions are "normal" ones and barrier can be enabled for
> them (well, at least with this kernel - I've seen the same behavior in
> 2.6.30 from Fedora but not in the previous ones).
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gabriel VLASIU | 29 Aug 2009 14:55

Re: loop_end_io_transfer


On Sat, 29 Aug 2009, Jari Ruusu wrote:

> err=-95 means:
> 
> #define EOPNOTSUPP 95 /* Operation not supported on transport endpoint */
> 
> bi_rw=0x5 means:
> 
>  * bit 0 -- data direction
>  *      If not set, bio is a read from device. If set, it's a write to device.
> [snip]
>  * bit 2 -- barrier
>  *      Insert a serialization point in the IO queue, forcing previously
>  *      submitted IO to be completed before this one is issued.
> 
> Here is what happens:
> - File system sends barrier write to loop device.
> - Loop encrypts the data (not relevant here).
> - Loop device sends barrier write to RAID5 backing device.
> - RAID5 backing device not supporting barrier writes at all, so it returns
>   EOPNOTSUPP error code.
> - Loop device prints error code it got from backing device.
> - Loop device returns EOPNOTSUPP error code to file system.
> - File system realizes that barrier writes do not work on that device, so it
>   switches off barrier writes.
> - File system re-sends the write without barrier.
> 
> Summary:
> File system auto-detects that barriers don't work on that particular device.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane