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, 02:47 PM
Julius Adorf
 
Default Timing issues when decrypting a USB drive during boot (/etc/crypttab)

Hello,

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?

Best,
Julius
 
Old 05-12-2012, 03:17 PM
XeCycle
 
Default Timing issues when decrypting a USB drive during boot (/etc/crypttab)

Julius Adorf <jeadorf@googlemail.com> writes:

> Hello,
>
> 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?

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.

--
Carl Lei (XeCycle)
Department of Physics, Shanghai Jiao Tong University
OpenPGP public key: 7795E591
Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591
 

Thread Tools




All times are GMT. The time now is 12:13 PM.

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