FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 05-12-2012, 03:31 PM
Tom Gundersen
 
Default Timing issues when decrypting a USB drive during boot (/etc/crypttab)

On Sat, May 12, 2012 at 4:47 PM, Julius Adorf <jeadorf@googlemail.com> wrote:
> Recently, I tried to automatically unlock an encrypted external USB
> hard drive on Arch Linux. I have done this by inserting an appropriate
> entry into /etc/crypttab. I chose the device to be unlocked by
> cryptsetup with a key file by UUID.
>
> Unfortunately, the unlocking failed at boot time ("device does not
> exist or access denied"). After some debugging via /etc/rc.sysinit, I
> found out that it is a timing issue and the USB drive which is a
> couple of years old was not ready yet at the time the /etc/crypttab
> was read and processed. A similar issue has been reported here:
> https://bbs.archlinux.org/viewtopic.php?id=137467
>
> For now, I have inserted a workaround into /etc/rc.local which unlocks
> the disk after an initial delay. This is still programming by
> coincidence; I wonder whether there is any better (i.e. reliable)
> solution to this problem?

This is a fundamental problem of how our initscripts work. systemd
does not have this problem, so one option is to switch to that.
Another option is to add a hook which basically does "sleep <random
amount of time>".

A third option would be to add some workaround to initscripts to make
this work more reliably. This is essentially the current state of
affairs:

When "udevadm --settle" returns it means that as far as udev knows all
devices (such as sata or pata devices) are ready. However, due to the
way USB works, udev won't know if all the connected usb devices have
been discovered yet, so have no way of knowing when they are all
ready.

What we could do, would be to add some logic that figures out what usb
devices we certainly need (parsing crypttab and fstab), and fave a
loop waiting for those to appear. I prefer not to do this in
initsrcipts itself (as it is a bit too ugly for my liking), but it
could easily be done in the form of a hook (which could be put on the
AUR).

Cheers,

Tom
 
Old 05-12-2012, 03:42 PM
Damjan
 
Default Timing issues when decrypting a USB drive during boot (/etc/crypttab)

Recently, I tried to automatically unlock an encrypted external USB
hard drive on Arch Linux. I have done this by inserting an appropriate
entry into /etc/crypttab. I chose the device to be unlocked by
cryptsetup with a key file by UUID.


Udisks listens to udev events and sends dbus events, so you can make a
"daemon" script, similar to that devmon shell that waits for your usb
drive and then does what it needs to do.



--
дамјан
 
Old 05-14-2012, 08:45 AM
Rodrigo Rivas
 
Default Timing issues when decrypting a USB drive during boot (/etc/crypttab)

On Sat, May 12, 2012 at 5:17 PM, XeCycle <xecycle@gmail.com> wrote:

> Julius Adorf <jeadorf@googlemail.com> writes:
>
> I think systemd auto mount facility may be able to handle it.
> But you're probably won't want to use systemd only for this.
>
>
systemd was created specifically to avoid these kind of problems, so maybe
you do want to use it only for this.
I've already switched to systemd and I am quite satisfied with it.
--
Rodrigo.
 
Old 05-14-2012, 09:21 AM
Julius Adorf
 
Default Timing issues when decrypting a USB drive during boot (/etc/crypttab)

Thanks for your efforts.

> systemd was created specifically to avoid these kind of problems, so maybe
> you do want to use it only for this.

As far as I am concerned, I'll leave the workaround on my local work
station as it is for now. I was just wondering whether I overlooked
something obvious; as soon as the situation asks for a more robust and
reliable solution, I will give systemd+cryptsetup a try.

> I prefer not to do this in initsrcipts itself (as it is a bit too ugly for my liking)

I have noticed that the symbolic link for the USB drive in
/dev/disk/by-uuid has already been created at the time crypttab is
processed in rc.sysinit; still the drive can only accessed and
decrypted after some delay. I have only very superficial understanding
of the initscripts. Yet, I think that inserting logic just to avoid
such specific problems is probably no good, especially when it is
dealing with asynchronous behaviour.

Regards,
Julius
 
Old 05-14-2012, 01:01 PM
Kevin Chadwick
 
Default Timing issues when decrypting a USB drive during boot (/etc/crypttab)

On Sat, 12 May 2012 16:47:36 +0200
Julius Adorf wrote:

> I wonder whether there is any better (i.e. reliable)
> solution to this problem?

until mounted (grep /proc/mounts); do sleep 5 mount


Where do you store the key anyway?
 
Old 05-14-2012, 01:15 PM
Kevin Chadwick
 
Default Timing issues when decrypting a USB drive during boot (/etc/crypttab)

On Mon, 14 May 2012 14:01:05 +0100
Kevin Chadwick wrote:

> Where do you store the key anyway?

Sorry didn't read your message carefully. I assumed it was a system
drive as you were using rc. Why not use a udev rule as дамјан mentioned.
That's what systemd would use anyway. Or even a simple button in your
gui to mount it.
 
Old 05-14-2012, 07:51 PM
Julius Adorf
 
Default Timing issues when decrypting a USB drive during boot (/etc/crypttab)

>> Where do you store the key anyway?

The key itself is on an encrypted drive, an extra passphrase is not
required for my purposes.

> Sorry didn't read your message carefully. I assumed it was a system
> drive as you were using rc.

Nope, it is an external drive.

> Why not use a udev rule as дамјан mentioned.
> That's what systemd would use anyway. Or even a simple button in your
> gui to mount it.

Thanks for reminding me of udev rules. I've now created a udev rule
which triggers the decryption; even better than the rc.local solution
since it will be decrypted whenever I plug the external drive in. The
timing issue remains. My drive is really slow compared to a very new
one; I will replace it eventually anyway, so it's just a matter of
time that the problem disappears...

J.
 

Thread Tools




All times are GMT. The time now is 05:07 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org