[arch-general] defunct packages spooking around
Hi folks, Sorry for the halloweenish subject heading ;) I recently got this bug report: http://bugs.archlinux.org/task/16690 It turned out it was not a bug with the perl package at all, but a problem which occurs when the presumably very old and no longer existing package "termcap-compat" is installed on a system. It was originally installed as a dependency for some other, unidentified package. And it turned out to my surprise that even I still had that package installed! That prompts me to ask the following: Are there other such obsolete packages that typically should no longer be installed on a "clean" Arch Linux system? I am not in favour of automating their removal, of course, but it would be useful to collect a list of such things that we could put in the wiki and/or our monthly newsletter. Another example that comes to mind is the obsolete file /etc/udev/udev.rules that I also still had until recently, and which I have removed after Thomas' suggestion. Please submit your suggestions for the forthcoming "Arch Ghostbusting Day" (aka "The Great Halloween Cleanup")! :) François
Firmicus wrote:
Hi folks,
Sorry for the halloweenish subject heading ;)
I recently got this bug report: http://bugs.archlinux.org/task/16690
It turned out it was not a bug with the perl package at all, but a problem which occurs when the presumably very old and no longer existing package "termcap-compat" is installed on a system. It was originally installed as a dependency for some other, unidentified package. And it turned out to my surprise that even I still had that package installed!
That prompts me to ask the following:
Are there other such obsolete packages that typically should no longer be installed on a "clean" Arch Linux system? I am not in favour of automating their removal, of course, but it would be useful to collect a list of such things that we could put in the wiki and/or our monthly newsletter. Another example that comes to mind is the obsolete file /etc/udev/udev.rules that I also still had until recently, and which I have removed after Thomas' suggestion.
Please submit your suggestions for the forthcoming "Arch Ghostbusting Day" (aka "The Great Halloween Cleanup")! :)
libdownload - replaced by libfetch as pacman download backend csup - relaced by using rsync for abs Although, all these should be detectable by "pacman -Qqtd" (maybe not libdownload as it was part of base). Allan
Allan McRae a écrit :
Firmicus wrote:
Hi folks,
Sorry for the halloweenish subject heading ;)
I recently got this bug report: http://bugs.archlinux.org/task/16690
It turned out it was not a bug with the perl package at all, but a problem which occurs when the presumably very old and no longer existing package "termcap-compat" is installed on a system. It was originally installed as a dependency for some other, unidentified package. And it turned out to my surprise that even I still had that package installed!
That prompts me to ask the following:
Are there other such obsolete packages that typically should no longer be installed on a "clean" Arch Linux system? I am not in favour of automating their removal, of course, but it would be useful to collect a list of such things that we could put in the wiki and/or our monthly newsletter. Another example that comes to mind is the obsolete file /etc/udev/udev.rules that I also still had until recently, and which I have removed after Thomas' suggestion.
Please submit your suggestions for the forthcoming "Arch Ghostbusting Day" (aka "The Great Halloween Cleanup")! :)
libdownload - replaced by libfetch as pacman download backend csup - relaced by using rsync for abs I removed these long ago, but...
Although, all these should be detectable by "pacman -Qqtd" (maybe not libdownload as it was part of base).
the above gave me quite a substantial list! Probably I should run this more often. Most of what is listed by pacman -Qqtd can indeed be safely removed. But sometimes the output can be surprising: I've got nautilus in there, which clearly is not something I would want to remove from my Gnome desktop :) Well, this is the kind of mess that one can expect on a system that has been installed nearly four years ago! F
On Wed, Oct 21, 2009 at 5:39 AM, Firmicus <Firmicus@gmx.net> wrote:
Allan McRae a écrit :
Firmicus wrote:
Hi folks,
Sorry for the halloweenish subject heading ;)
I recently got this bug report: http://bugs.archlinux.org/task/16690
It turned out it was not a bug with the perl package at all, but a problem which occurs when the presumably very old and no longer existing package "termcap-compat" is installed on a system. It was originally installed as a dependency for some other, unidentified package. And it turned out to my surprise that even I still had that package installed!
That prompts me to ask the following:
Are there other such obsolete packages that typically should no longer be installed on a "clean" Arch Linux system? I am not in favour of automating their removal, of course, but it would be useful to collect a list of such things that we could put in the wiki and/or our monthly newsletter. Another example that comes to mind is the obsolete file /etc/udev/udev.rules that I also still had until recently, and which I have removed after Thomas' suggestion.
Please submit your suggestions for the forthcoming "Arch Ghostbusting Day" (aka "The Great Halloween Cleanup")! :)
libdownload - replaced by libfetch as pacman download backend csup - relaced by using rsync for abs I removed these long ago, but...
Although, all these should be detectable by "pacman -Qqtd" (maybe not libdownload as it was part of base).
the above gave me quite a substantial list! Probably I should run this more often. Most of what is listed by pacman -Qqtd can indeed be safely removed. But sometimes the output can be surprising: I've got nautilus in there, which clearly is not something I would want to remove from my Gnome desktop :) Well, this is the kind of mess that one can expect on a system that has been installed nearly four years ago!
F
Try with "pacman -Qm". That might work better if you don't have a lot of custom/AUR packages installed.
Eric Bélanger a écrit :
On Wed, Oct 21, 2009 at 5:39 AM, Firmicus <Firmicus@gmx.net> wrote:
Allan McRae a écrit :
Firmicus wrote:
Hi folks,
Sorry for the halloweenish subject heading ;)
I recently got this bug report: http://bugs.archlinux.org/task/16690
It turned out it was not a bug with the perl package at all, but a problem which occurs when the presumably very old and no longer existing package "termcap-compat" is installed on a system. It was originally installed as a dependency for some other, unidentified package. And it turned out to my surprise that even I still had that package installed!
That prompts me to ask the following:
Are there other such obsolete packages that typically should no longer be installed on a "clean" Arch Linux system? I am not in favour of automating their removal, of course, but it would be useful to collect a list of such things that we could put in the wiki and/or our monthly newsletter. Another example that comes to mind is the obsolete file /etc/udev/udev.rules that I also still had until recently, and which I have removed after Thomas' suggestion.
Please submit your suggestions for the forthcoming "Arch Ghostbusting Day" (aka "The Great Halloween Cleanup")! :)
libdownload - replaced by libfetch as pacman download backend csup - relaced by using rsync for abs
I removed these long ago, but...
Although, all these should be detectable by "pacman -Qqtd" (maybe not libdownload as it was part of base).
the above gave me quite a substantial list! Probably I should run this more often. Most of what is listed by pacman -Qqtd can indeed be safely removed. But sometimes the output can be surprising: I've got nautilus in there, which clearly is not something I would want to remove from my Gnome desktop :) Well, this is the kind of mess that one can expect on a system that has been installed nearly four years ago!
F
Try with "pacman -Qm". That might work better if you don't have a lot of custom/AUR packages installed.
Hem, I have hundreds of them! But they're almost exclusively auto-generated packages for CPAN/perl stuff. In my case running pacman -Qqm | grep -v perl does the job, which does not, however, reveal any new item to be cleaned away. I am actually hunting for packages that used to be in core or extra and no longer exist, not even in community/AUR, but might still be polluting some Arch installations... Perhaps termcap-compat was an exceptional case after all.
On Wed, Oct 21, 2009 at 11:00 AM, Firmicus <Firmicus@gmx.net> wrote:
Eric Bélanger a écrit :
On Wed, Oct 21, 2009 at 5:39 AM, Firmicus <Firmicus@gmx.net> wrote:
Allan McRae a écrit :
Firmicus wrote:
Hi folks,
Sorry for the halloweenish subject heading ;)
I recently got this bug report: http://bugs.archlinux.org/task/16690
It turned out it was not a bug with the perl package at all, but a problem which occurs when the presumably very old and no longer existing package "termcap-compat" is installed on a system. It was originally installed as a dependency for some other, unidentified package. And it turned out to my surprise that even I still had that package installed!
That prompts me to ask the following:
Are there other such obsolete packages that typically should no longer be installed on a "clean" Arch Linux system? I am not in favour of automating their removal, of course, but it would be useful to collect a list of such things that we could put in the wiki and/or our monthly newsletter. Another example that comes to mind is the obsolete file /etc/udev/udev.rules that I also still had until recently, and which I have removed after Thomas' suggestion.
Please submit your suggestions for the forthcoming "Arch Ghostbusting Day" (aka "The Great Halloween Cleanup")! :)
libdownload - replaced by libfetch as pacman download backend csup - relaced by using rsync for abs
I removed these long ago, but...
Although, all these should be detectable by "pacman -Qqtd" (maybe not libdownload as it was part of base).
the above gave me quite a substantial list! Probably I should run this more often. Most of what is listed by pacman -Qqtd can indeed be safely removed. But sometimes the output can be surprising: I've got nautilus in there, which clearly is not something I would want to remove from my Gnome desktop :) Well, this is the kind of mess that one can expect on a system that has been installed nearly four years ago!
F
Try with "pacman -Qm". That might work better if you don't have a lot of custom/AUR packages installed.
Hem, I have hundreds of them! But they're almost exclusively auto-generated packages for CPAN/perl stuff. In my case running pacman -Qqm | grep -v perl does the job, which does not, however, reveal any new item to be cleaned away.
I am actually hunting for packages that used to be in core or extra and no longer exist, not even in community/AUR, but might still be polluting some Arch installations... Perhaps termcap-compat was an exceptional case after all.
check http://www.archlinux.de/?page=PackageStatistics especially the packages in the unknown category. Some of the removed packages are listed there.
Eric Bélanger a écrit :
On Wed, Oct 21, 2009 at 11:00 AM, Firmicus <Firmicus@gmx.net> wrote:
Eric Bélanger a écrit :
On Wed, Oct 21, 2009 at 5:39 AM, Firmicus <Firmicus@gmx.net> wrote:
Allan McRae a écrit :
Firmicus wrote:
Hi folks,
Sorry for the halloweenish subject heading ;)
I recently got this bug report: http://bugs.archlinux.org/task/16690
It turned out it was not a bug with the perl package at all, but a problem which occurs when the presumably very old and no longer existing package "termcap-compat" is installed on a system. It was originally installed as a dependency for some other, unidentified package. And it turned out to my surprise that even I still had that package installed!
That prompts me to ask the following:
Are there other such obsolete packages that typically should no longer be installed on a "clean" Arch Linux system? I am not in favour of automating their removal, of course, but it would be useful to collect a list of such things that we could put in the wiki and/or our monthly newsletter. Another example that comes to mind is the obsolete file /etc/udev/udev.rules that I also still had until recently, and which I have removed after Thomas' suggestion.
Please submit your suggestions for the forthcoming "Arch Ghostbusting Day" (aka "The Great Halloween Cleanup")! :)
libdownload - replaced by libfetch as pacman download backend csup - relaced by using rsync for abs
I removed these long ago, but...
Although, all these should be detectable by "pacman -Qqtd" (maybe not libdownload as it was part of base).
the above gave me quite a substantial list! Probably I should run this more often. Most of what is listed by pacman -Qqtd can indeed be safely removed. But sometimes the output can be surprising: I've got nautilus in there, which clearly is not something I would want to remove from my Gnome desktop :) Well, this is the kind of mess that one can expect on a system that has been installed nearly four years ago!
F
Try with "pacman -Qm". That might work better if you don't have a lot of custom/AUR packages installed.
Hem, I have hundreds of them! But they're almost exclusively auto-generated packages for CPAN/perl stuff. In my case running pacman -Qqm | grep -v perl does the job, which does not, however, reveal any new item to be cleaned away.
I am actually hunting for packages that used to be in core or extra and no longer exist, not even in community/AUR, but might still be polluting some Arch installations... Perhaps termcap-compat was an exceptional case after all.
check http://www.archlinux.de/?page=PackageStatistics especially the packages in the unknown category. Some of the removed packages are listed there.
That's what I guessed: termcap-compat has ~18%! csup: 15% and libdownload: 59%!! For the rest one would need to check each pkg under "unknown" for non-existence in AUR... Any volunteer? :)
On Wed, Oct 21, 2009 at 11:42 PM, Firmicus <Firmicus@gmx.net> wrote:
That's what I guessed: termcap-compat has ~18%! csup: 15% and libdownload: 59%!!
For the rest one would need to check each pkg under "unknown" for non-existence in AUR... Any volunteer? :)
I think you can automate that. One example from http://wiki.archlinux.org/index.php/Optdepends_bugs#Checking_script : if [ $(slurpy -i "$pkg" 2>/dev/null | wc -l) -gt 1 ]; then continue fi But you can use any other ways you like to access AUR :)
Allan McRae wrote:
Although, all these should be detectable by "pacman -Qqtd" (maybe not libdownload as it was part of base).
And remember always check "pacman -Qqtd" output before doing a "pacman -Rs $(pacman -Qqtd)"....
pacman -Qqtd aufs2 db4.1 esound evolution-data-server farsight2 gperf gtksourceview ....
pacman -Rs $(pacman -Qqtd) checking dependencies...
Remove (27): virtualbox-ose-3.0.8-1 virtualbox-modules-3.0.8-1 tcsh-6.17.00-1 sysstat-9.0.5-1 skype-2.1.0.47-1 qt-4.5.3-3 silc-toolkit-1.1.9-1 python-numpy-1.3.0-2 intltool-0.41.0-1 gtksourceview-1.8.5-2 libgnomeprint-2.18.6-1 libgnomecups-0.2.3-4 gperf-3.0.4-1 farsight2-0.0.16-1 libnice-0.0.9-1 evolution-data-server-2.28.1-1 libical-0.44-1 libgweather-2.28.0-1 libsoup-gnome-2.28.1-1 libsoup-2.28.1-1 libproxy-0.2.3-1 esound-0.2.41-1 audiofile-0.2.6-4 db4.1-4.1.25-3 aufs2-2.6.31_20090910-1 kernel26-2.6.31.4-1 kernel26-firmware-2.6.31-1 Hmm... aufs2 pulls in the kernel... good thing I did not reboot! Allan
On Sat, Oct 24, 2009 at 2:51 AM, Allan McRae <allan@archlinux.org> wrote:
Allan McRae wrote:
Although, all these should be detectable by "pacman -Qqtd" (maybe not libdownload as it was part of base).
And remember always check "pacman -Qqtd" output before doing a "pacman -Rs $(pacman -Qqtd)"....
pacman -Qqtd aufs2 db4.1 esound evolution-data-server farsight2 gperf gtksourceview ....
pacman -Rs $(pacman -Qqtd) checking dependencies...
Remove (27): virtualbox-ose-3.0.8-1 virtualbox-modules-3.0.8-1 tcsh-6.17.00-1 sysstat-9.0.5-1 skype-2.1.0.47-1 qt-4.5.3-3 silc-toolkit-1.1.9-1 python-numpy-1.3.0-2 intltool-0.41.0-1 gtksourceview-1.8.5-2 libgnomeprint-2.18.6-1 libgnomecups-0.2.3-4 gperf-3.0.4-1 farsight2-0.0.16-1 libnice-0.0.9-1 evolution-data-server-2.28.1-1 libical-0.44-1 libgweather-2.28.0-1 libsoup-gnome-2.28.1-1 libsoup-2.28.1-1 libproxy-0.2.3-1 esound-0.2.41-1 audiofile-0.2.6-4 db4.1-4.1.25-3 aufs2-2.6.31_20090910-1 kernel26-2.6.31.4-1 kernel26-firmware-2.6.31-1
Hmm... aufs2 pulls in the kernel... good thing I did not reboot!
Allan
After a normal install, you should have all base packages explicitly installed. In fact I have only 2 which were not : kernel26-firmware because it is new, and perl because I marked it myself as dep, not sure why.. Anyway, who would expect Allan to do a normal install ? :) LANG=C pacman -Qi $(pacman -Qgq base) | egrep "Name|Reason" they can all be reinstalled with pacman -S --asexplicit $(pacman -Qgq base)
Hi, I've recently set up full encryption of my system (including swap), but therefore lost the possibility to suspend my device to disk (hibernate). The only way mentioned in the wiki is highly not recommended as you would have to place your key on the unencrypted boot partition, which basically conflicts the idea of full encryption (see http://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt...). By looking for some solution, the only thing I could figure out was to set up lvm, and encrypting the whole lvm partition, which would include the swap. This way all of my stuff would get unlocked, including the swap and therefore my system could resume from a former hibernation. Before setting this up (which will cost some time, as I have to back up, configure and restore my stuff) I wanted to ask you, whether this will work as supposed, and if there may be any better solutions? How do you get both hibernation and full encryption working together? -- Best regards, Karol Babioch <karol@babioch.de>
How do you get both hibernation and full encryption working together?
you can probably modify the initramfs scripts to ask the password and unlock your swap partition before trying to resume. The initramfs scripts are in /lib/initcpio/hooks/ -- damjan
Hi, I've recently set up full encryption of my system (including swap), but therefore lost the possibility to suspend my device to disk (hibernate). The only way mentioned in the wiki is highly not recommended as you would have to place your key on the unencrypted boot partition, which basically conflicts the idea of full encryption (see http://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt...). By looking for some solution, the only thing I could figure out was to set up lvm, and encrypting the whole lvm partition, which would include the swap. This way all of my stuff would get unlocked, including the swap and therefore my system could resume from a former hibernation. Before setting this up (which will cost some time, as I have to back up, configure and restore my stuff) I wanted to ask you, whether this will work as supposed, and if there may be any better solutions? How do you get both hibernation and full encryption working together?f -- Best regards, Karol Babioch <karol@babioch.de>
On Sun, Oct 25, 2009 at 11:17, Karol Babioch <karol@babioch.de> wrote:
Hi, The only way mentioned in the wiki is highly not recommended as you would have to place your key on the unencrypted boot partition, which basically conflicts the idea of full encryption (see http://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt...).
Could you put the key on a usb drive so that the drive is required to unlock the partitions?
Hi, On So, 2009-10-25 at 11:27 -0400, Daenyth Blank wrote:
Could you put the key on a usb drive so that the drive is required to unlock the partitions?
thank you very much for your reply. However I don't like the idea to store my key(s) on an usb drive. First of all if my laptop really gets stolen (or I loose it :o), the usb drive certainly would be attached, making the whole encryption stuff unnecessary. Secondly I don't want to worry whether I have my usb drive with me or not, because without the usb drive my laptop is quite useless. I like the idea of having a pass-phrase, and I would like to stay with this approach. -- Best regards, Karol Babioch <karol@babioch.de>
Karol Babioch wrote:
Hi,
On So, 2009-10-25 at 11:27 -0400, Daenyth Blank wrote:
Could you put the key on a usb drive so that the drive is required to unlock the partitions?
thank you very much for your reply. However I don't like the idea to store my key(s) on an usb drive. First of all if my laptop really gets stolen (or I loose it :o), the usb drive certainly would be attached, making the whole encryption stuff unnecessary. Secondly I don't want to worry whether I have my usb drive with me or not, because without the usb drive my laptop is quite useless.
I like the idea of having a pass-phrase, and I would like to stay with this approach.
I think a lvm is the best solution, but I do not use it either currently (because I'm too lazy to set it up :) ). Therefore, I use the same passphrase for swap and root (it would also be possible to use different ones, but then you have to enter two passphrases), and patched the mkinitcpio encrypt hook to decrypt them both at boot.
Hi, I'm sorry that I've sent my message twice, my Evolution has crashed, and the message wasn't in the "Sent" folder, so I assumed that it has crashed before it has sent the message. As it seems I was wrong ;). -- Best regards, Karol Babioch <karol@babioch.de>
Karol Babioch schrieb:
Hi,
I've recently set up full encryption of my system (including swap), but therefore lost the possibility to suspend my device to disk (hibernate).
The only way mentioned in the wiki is highly not recommended as you would have to place your key on the unencrypted boot partition, which basically conflicts the idea of full encryption (see http://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt...).
By looking for some solution, the only thing I could figure out was to set up lvm, and encrypting the whole lvm partition, which would include the swap. This way all of my stuff would get unlocked, including the swap and therefore my system could resume from a former hibernation.
Before setting this up (which will cost some time, as I have to back up, configure and restore my stuff) I wanted to ask you, whether this will work as supposed, and if there may be any better solutions?
How do you get both hibernation and full encryption working together?
It is possible. Consider the following setup: You have two partitions, one small (50MB) /boot /dev/sda1, the rest /dev/sda2. Now you create a LUKS-Volume in /dev/sda2, let's call this volume enc. Inside /dev/mapper/enc create a LVM physical volume. Then, create your root, swap, home, ... filesystems as logical volumes inside the LVM (let's say they are called /dev/vg/{root,swap,home,...}. That way, you just need to enter ONE passphrase to be able to access all your volumes, including swap and root. The installer (AIF) can set all the above up correctly, however, the current version will make the wrong grub line. In the described setup, it should be: cryptdevice=/dev/sda2:enc root=/dev/vg/root resume=/dev/vg/swap ro Your mkinitcpio.conf should have the following line: HOOKS="base udev pata scsi sata keymap encrypt lvm2 resume filesystems" (note that lvm2 is before resume, not after) This setup will make it possible to use hibernation on an encrypted system without a separate key storage and without having to enter more than one passphrase. It is also a very elegant setup, as you have the usual advantages of LVM. Have fun!
Thomas Bächler schrieb:
How do you get both hibernation and full encryption working together?
It is possible. Consider the following setup:
You have two partitions, one small (50MB) /boot /dev/sda1, the rest /dev/sda2. Now you create a LUKS-Volume in /dev/sda2, let's call this volume enc. Inside /dev/mapper/enc create a LVM physical volume. Then, create your root, swap, home, ... filesystems as logical volumes inside the LVM (let's say they are called /dev/vg/{root,swap,home,...}. That way, you just need to enter ONE passphrase to be able to access all your volumes, including swap and root.
The installer (AIF) can set all the above up correctly, however, the current version will make the wrong grub line. In the described setup, it should be:
cryptdevice=/dev/sda2:enc root=/dev/vg/root resume=/dev/vg/swap ro
Your mkinitcpio.conf should have the following line:
HOOKS="base udev pata scsi sata keymap encrypt lvm2 resume filesystems" (note that lvm2 is before resume, not after)
This setup will make it possible to use hibernation on an encrypted system without a separate key storage and without having to enter more than one passphrase. It is also a very elegant setup, as you have the usual advantages of LVM.
Have fun!
Forgot to add: This is supported out of the box by Arch without any modifications to mkinitcpio hooks (unlike the other suggested setups). I have it set up right now, but I only hibernate rarely, I like suspend to ram better.
Hi, thanks very much, I'm about to save my stuff, and trying to set this up, although it could take a while ;). -- Best regards, Karol Babioch <karol@babioch.de>
thanks very much, I'm about to save my stuff, and trying to set this up, although it could take a while ;).
Yes, thanks Thomas. I look forward to trying this the next time I do an install. Added security is always added peace of mind :) -- Chris
Hi, ok, I've set everything up as described by you, and it actually works just great. The only problem I ran into was that I've backed up my files using "partclone", which is just great, but as I've changed my partition scheme a little bit, it was quite hard to restore everything, as partclone doesn't want to restore a partition, which is smaller than the one backed up. However this has nothing to do with the encryption itself, I now have a flexible, working and _encrypted_ system. Thank you very much. -- Best regards, Karol Babioch <karol@babioch.de>
Thomas Bächler wrote:
Karol Babioch schrieb:
Hi,
I've recently set up full encryption of my system (including swap), but therefore lost the possibility to suspend my device to disk (hibernate).
The only way mentioned in the wiki is highly not recommended as you would have to place your key on the unencrypted boot partition, which basically conflicts the idea of full encryption (see http://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt...).
By looking for some solution, the only thing I could figure out was to set up lvm, and encrypting the whole lvm partition, which would include the swap. This way all of my stuff would get unlocked, including the swap and therefore my system could resume from a former hibernation.
Before setting this up (which will cost some time, as I have to back up, configure and restore my stuff) I wanted to ask you, whether this will work as supposed, and if there may be any better solutions?
How do you get both hibernation and full encryption working together?
It is possible. Consider the following setup:
You have two partitions, one small (50MB) /boot /dev/sda1, the rest /dev/sda2. Now you create a LUKS-Volume in /dev/sda2, let's call this volume enc. Inside /dev/mapper/enc create a LVM physical volume. Then, create your root, swap, home, ... filesystems as logical volumes inside the LVM (let's say they are called /dev/vg/{root,swap,home,...}. That way, you just need to enter ONE passphrase to be able to access all your volumes, including swap and root.
The installer (AIF) can set all the above up correctly, however, the current version will make the wrong grub line. In the described setup, it should be:
cryptdevice=/dev/sda2:enc root=/dev/vg/root resume=/dev/vg/swap ro
Your mkinitcpio.conf should have the following line:
HOOKS="base udev pata scsi sata keymap encrypt lvm2 resume filesystems" (note that lvm2 is before resume, not after)
This setup will make it possible to use hibernation on an encrypted system without a separate key storage and without having to enter more than one passphrase. It is also a very elegant setup, as you have the usual advantages of LVM.
Have fun!
Wow, thanks for this tutorial. Hopefully, I remember this mail when I set up my box again.
On Sun, Oct 25, 2009 at 05:01:11PM +0100, Thomas Bächler wrote:
It is possible. Consider the following setup:
You have two partitions, one small (50MB) /boot /dev/sda1, the rest /dev/sda2. Now you create a LUKS-Volume in /dev/sda2, let's call this volume enc. Inside /dev/mapper/enc create a LVM physical volume. Then, create your root, swap, home, ... filesystems as logical volumes inside the LVM (let's say they are called /dev/vg/{root,swap,home,...}. That way, you just need to enter ONE passphrase to be able to access all your volumes, including swap and root.
The installer (AIF) can set all the above up correctly, however, the current version will make the wrong grub line. In the described setup, it should be:
cryptdevice=/dev/sda2:enc root=/dev/vg/root resume=/dev/vg/swap ro
Your mkinitcpio.conf should have the following line:
HOOKS="base udev pata scsi sata keymap encrypt lvm2 resume filesystems" (note that lvm2 is before resume, not after)
This setup will make it possible to use hibernation on an encrypted system without a separate key storage and without having to enter more than one passphrase. It is also a very elegant setup, as you have the usual advantages of LVM.
Have fun!
Thanks, helpful hints. But does this also work with "suspend-to-ram"? I mean, when suspending to ram everything remains unencrypted? Do I see this right? Vlad --
vlad schrieb:
Thanks, helpful hints. But does this also work with "suspend-to-ram"? I mean, when suspending to ram everything remains unencrypted? Do I see this right?
Suspend to RAM always works - however, there are potential attacks where people freeze your laptop, take out the (frozen) RAM and recover the encryption keys from there.
participants (11)
-
Allan McRae
-
Cedric Staniewski
-
christopher floess
-
Daenyth Blank
-
Damjan Georgievski
-
Eric Bélanger
-
Firmicus
-
Karol Babioch
-
Thomas Bächler
-
vlad
-
Xavier