Re: cryptsetup luksOpen /dev/sdb1 lin-bak, but it disappears after I reboot
There is no default directory /var/mapper. It is supposed to be /dev/mapper. Can you do all of that steps again, but before you reboot, can you please give me the output of the following files: cat /dev/mapper cat /etc/fstab cat /etc/crypttab On Sun, Jul 29, 2012 at 10:59 PM, Todd And Margo Chester toddandma...@gmail.com wrote: On Sun, Jul 29, 2012 at 7:37 PM, Todd And Margo Chester toddandma...@gmail.com mailto:toddandma...@gmail.com** wrote: Hi All, I can set up /dev/mapper/lin-bak with # cryptsetup luksOpen /dev/sdb1 lin-bak but it disappears after I reboot. This messes up my crypttab/fstab. Any idea what I am doing wrong? Many thanks, -T On 07/29/2012 06:15 PM, Tam Nguyen wrote: Hi Todd, Did you create a file journal (mkfs...) after you executed the command?: # cryptsetup luksOpen /dev/sdb1 lin-bak Basic steps are: 1) cryptsetup luksFormat /dev/xyz 2) cryptsetup luksOpen /dev/xyz abc ---then verify it in /dev/mapper 3) mkfs.ext4 /dev/mapper/abc --- i like to use ext4. Do research on this journal if you're not clear. Now that we got it settled. Come the fun part- automounting: 4) configure your /etc/fstab 5) then configure your /etc/crypttab Before you reboot your machine, do a tested mount: mount -a -Tam Yes, did all that. I can mount too. But, when I reboot, lin-bak disappears from /var/mapper. AAA! -T
Scientific Linux 6.3 Release Candidate 1 i386/x86_64 is now available for testing
Scientific Linux 6.3 Release Candidate 1 i386/x86_64 July 30, 2012 These are notes of the Alpha/Beta releases for Scientific Linux 6.3 . THIS IS NOT FOR PRODUCTION. This is for testing. Please report back any issues to scientific-linux-de...@listserv.fnal.gov . There should be no expectation that a yum upgrade to SL 6.3 will work. A new install is the recommended method to move from sl6rolling(this alpha release) and the released SL 6.3. Items marked with * are changes from 6.2 Items marked with ** are changes from the alpha/beta release DOWNLOAD INFO DVD: http://ftp.scientificlinux.org/linux/scientific/6.3/i386/iso http://ftp.scientificlinux.org/linux/scientific/6.3/x86_64/iso Network Install Images: http://ftp.scientificlinux.org/linux/scientific/6.3/i386/images/boot.iso http://ftp.scientificlinux.org/linux/scientific/6.3/x86_64/images/boot.iso CHANGES WE MADE SINCE PREVIOUS RELEASE *yum-conf-sl6x-1-2 -Updated GPG key list, CERN's key is now listed here too *redhat-logos-60.0.14-2.sl6.5 -Now provides 'linux-logos' *kmod-openafs-1.6.1-112.sl6.71 *openafs-1.6.1-112.sl6 *openafs-authlibs-1.6.1-112.sl6 *openafs-authlibs-devel-1.6.1-112.sl6 *openafs-client-1.6.1-112.sl6 *openafs-compat-1.6.1-112.sl6 *openafs-devel-1.6.1-112.sl6 *openafs-kernel-source-1.6.1-112.sl6 *openafs-kpasswd-1.6.1-112.sl6 *openafs-krb5-1.6.1-112.sl6 *openafs-plumbing-tools-1.6.1-112.sl6 *openafs-server-1.6.1-112.sl6 -Updated to more current version, this is based on OpenAFS 1.6.1 *sl-indexhtml-6-2.sl6.6 -Updated Swedish translation by Alexander Lindqvist *sl-bookmarks-6-2.sl6 -Now includes links to useful non-SL provided resources **sl-release-6.3-1 -Updated to point at 6.3, non-rolling *SL_enable_serialconsole-4.1-1.el6 *SL_enable_serialconsole-96-4.1-1.el6 *SL_enable_serialconsole-192-4.1-1.el6 *SL_enable_serialconsole-384-4.1-1.el6 *SL_enable_serialconsole-1152-4.1-1.el6 -added '-r' option to script for removal of the configuration -now removes configuration when uninstalled -Switched to augeas based configuration -The old script can be found in the %doc folder -removed support for non-grub bootloaders -a number of SPEC file changes to make things cleaner -Now uses 'conflict' to ensure only one version installed at a time *sl-release-notes-6.3-1 -Updated for 6.3 - Added technical release notes from TUV **revisor-2.2-4.sl6_3 -Added support for --final feature that was added in anaconda buildinstall --Added requires for newer anaconda **sl-revisor-configs-1-6.3.4 -Renamed kickstart files for simplicity -Added script for making a disc containing published errata -Updated yuminstall.py to latest release --Updated ks/sl6.install.dvd.i386.ks ks/sl6.install.dvd.x86_64.ks RPMS ADDED IN THIS RELEASE *rpmfusion-free-release-6-1.noarch.rpm *yum-conf-rpmfusion-6-0.1.noarch.rpm -Simplified access to this repository was requested by the community The 'non-free' repository is not included. It is the responsibility of the end user to verify their compliance with the licensing of the rpms in the rpmfusion repository. **gtk2-immodules-2.18.9-10.el6.i686.rpm **gtk2-immodule-xim-2.18.9-10.el6.i686.rpm **ibus-gtk-1.3.4-6.el6.i686.rpm **procps-3.2.8-23.el6.i686.rpm --These were supposed to be in the x86_64 tree They have been added in so that things function as expected **pacemaker-1.1.7-6.el6.i686.rpm **pacemaker-cli-1.1.7-6.el6.i686.rpm **pacemaker-cluster-libs-1.1.7-6.el6.i686.rpm **pacemaker-libs-1.1.7-6.el6.i686.rpm **pacemaker-libs-devel-1.1.7-6.el6.i686.rpm --These were returned to the i686 tree as the documentation saying to remove them seems to have been mistaken MAJOR CHANGES TUV MADE *libreoffice -openoffice.org has been replaced with libreoffice. The libreoffice packages 'provide' the right packages to maintain compatibility for kickstart and yum installs. *anaconda -Anaconda now alerts users to the beta status of a release when it is tagged appropriately. Upstream has added this functionality and we are taking advantage of it for the beta cycle. POSSIBLE UPGRADE PROBLEMS
DBus and nautilus
Hello all, It looks like one of my SL6.2 machines is not correctly hooking up with dbus - a user has some bookmarks defined as sftp links, and they are no longer working after a restart on the weekend. The error reported is: Could not open location 'sftp://user@remote/dir' DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Is this a known problem, and is there a fix, or is this more likely something on my end (I don't have access to the server the user is attempting to access with sftp, so I can't test other systems very well) Thanks, Chris
Re: cryptsetup luksOpen /dev/sdb1 lin-bak, but it disappears after I reboot
On 07/30/2012 06:26 PM, Tam Nguyen wrote: Todd, let's keep it simple, get it right and work, then you can take off from there. So do this: vi /etc/fstab: /dev/mapper/lin-bak /mnt ext4 defaults 0 0 Hi Tam, I have tried this. With and without the first parameter set to allow dump, which I do need. vi /etc/crypttab: lin-bak/dev/sdb1 I have tried this. At boot I get mount: special device /dev/mapper/lin-bak does not exist mount -a without /dev/mapper/lin-bak, it won't mount. reboot /dev/mapper/lin-bak disappears Then we'll go from there. -Tam You know what I have not tried, removing the dash from lin-bak in crypttab -T
Re: cryptsetup luksOpen /dev/sdb1 lin-bak, but it disappears after I reboot
On 07/30/2012 06:26 PM, Tam Nguyen wrote: Todd, let's keep it simple, get it right and work, then you can take off from there. So do this: vi /etc/fstab: /dev/mapper/lin-bak /mnt ext4 defaults 0 0 Hi Tam, I have tried this. With and without the first parameter set to allow dump, which I do need. vi /etc/crypttab: lin-bak/dev/sdb1 I have tried this. At boot I get mount: special device /dev/mapper/lin-bak does not exist mount -a without /dev/mapper/lin-bak, it won't mount. reboot /dev/mapper/lin-bak disappears Then we'll go from there. -Tam You know what I have not tried, removing the dash from lin-bak in crypttab Makes no difference. -T I am mounting now by using rc.local: # if I can not get /etc/crypttab to work, this will populate # /dev/mapper with lin-bak and mount /lin-bak if [ ! -L /dev/mapper/lin-bak ]; then cryptsetup luksOpen /dev/sdb1 lin-bak /etc/crypttab.lin-bak.key if [ -L /dev/mapper/lin-bak ] [ -n $(mount -l | grep -i lin-bak) ]; then mount /lin-bak fi fi I suppose I don't need the [ -n $(mount -l | grep -i lin-bak) ] But, I was pleased with my coding, so I left it in. -T
Re: cryptsetup luksOpen /dev/sdb1 lin-bak, but it disappears after I reboot
On Mon, Jul 30, 2012 at 10:55 PM, Todd And Margo Chester toddandma...@gmail.com mailto:toddandma...@gmail.com wrote: On 07/30/2012 06:26 PM, Tam Nguyen wrote: Todd, let's keep it simple, get it right and work, then you can take off from there. So do this: vi /etc/fstab: /dev/mapper/lin-bak /mnt ext4 defaults 0 0 Hi Tam, I have tried this. With and without the first parameter set to allow dump, which I do need. vi /etc/crypttab: lin-bak/dev/sdb1 I have tried this. At boot I get mount: special device /dev/mapper/lin-bak does not exist mount -a without /dev/mapper/lin-bak, it won't mount. reboot /dev/mapper/lin-bak disappears Then we'll go from there. -Tam You know what I have not tried, removing the dash from lin-bak in crypttab Makes no difference. -T I am mounting now by using rc.local: # if I can not get /etc/crypttab to work, this will populate # /dev/mapper with lin-bak and mount /lin-bak if [ ! -L /dev/mapper/lin-bak ]; then cryptsetup luksOpen /dev/sdb1 lin-bak /etc/crypttab.lin-bak.key if [ -L /dev/mapper/lin-bak ] [ -n $(mount -l | grep -i lin-bak) ]; then mount /lin-bak fi fi I suppose I don't need the [ -n $(mount -l | grep -i lin-bak) ] But, I was pleased with my coding, so I left it in. -T On 07/30/2012 08:04 PM, Tam Nguyen wrote: Todd, I am glad it works for you. I get my working on the VM without touching the rc.local file. You should research on it. Good luck Hi Tam, Thank you for the copious amounts of time and your knowledge you shared with me helping me! Red Hat is going to get a few bug reports out of this in the next few days! -T
