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

Eric Bélanger a écrit :

On Wed, Oct 21, 2009 at 5:39 AM, Firmicus 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.

Eric Bélanger a écrit :

On Wed, Oct 21, 2009 at 11:00 AM, Firmicus wrote:

...

Eric Bélanger a écrit :

...

On Wed, Oct 21, 2009 at 5:39 AM, Firmicus 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? :)

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

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

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

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

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

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.

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

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.

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.