How to access encrypted LVM filesystem in rescue mode - ext3 filesystem cannot mount

English Install/Boot/Login
#1

I have two hard disks, one 120 GB Samsung EVO 840 SSD, and one 1 TB Samsung 7200 rpm spinning HDD.
On the 120 GB disk I installed openSUSE 13.1 successfully, using LVM and encryption at login.
This 120 GB drive is internally recognised as /dev/sdb.

Next, I formatted the 1 TB disk into three partitions, using the fdisk command.
sda1 is a legacy partition formatted in ntfs and I left untouched (file type 07).
sda2 became 600 GB in size and was formatted in 83 LINUX.
sda3 become 205 GB in size and was formatted in 83 LINUX.

Next, I chose to format both sda2 and sda3 in ext3, so I would have future compatibility with OpenBSD or Mac OS X. I completed the formatting successfully using mkfs.ext3 /dev/sda3.

Next, I created two directories in the /mnt directory, called P2 and P3.

Next, I made corresponding entries in the /etc/fstab file, using the vi editor. My two entries look like this
/dev/sda2 /mnt/P2 ext3 defaults 1 1
/dev/sda3 /mnt/P3 ext3 defaults 1 1

Next, I installed truecrypt on the desktop and encrypted the sda3 partition, using the truecrypt installation wizard. In this installation dialogue, truecrypt asks specifically, whether this partition will have to be accessible by other operating systems. My answer was “No”, to ensure that truecrypt would not change my format to FAT32 or NTFS, without my control. I made sure the format would remain ext3 to retain future compatibility with other UNIX-like operating systems.

Next, I copied some 70 GB of data into the truecrypt partition without any problems, and I shut down my computer.

Now my trouble begins:
At the next restart, openSUSE 13.1 boots successfully until it gets to the password prompt for the encrypted LVM filesystem on the 120 GB (sdb) disk. It accepts my correct password, then apparently tries to mount P2 and P3, but fails, as it throws the computer into an endless loop, toggling every few seconds between trying to start the X Window System environment with the login prompt, and switching back to console mode and sending endlessly this message to the screen:
…
186.133206] EXT4-fs (sda3): VFS: Can’t find ext4 filesystem
…

Clearly, it is looking for an ext4 filesystem, but only finds ext3. This should not be an issue for a Linux operating system, but let’s think results oriented first: I physically remove the 1 TB disk causing the trouble, which is easy to do as I am using an ICY DOCK MB994SP-4S (which is fantastic, BTW), then reboot the system. Removing the disk causes openSUSE to not even make it to the encryption password prompt, it crashes before it gets there.

I insert my boot DVD, and enter Rescue Mode. In Rescue mode, I do not make it to the encryption password prompt either, it throws out messages to me such as:
systemd-fsck[566]: fsck: fsck.ntfs: not found
systemd-fsck[566]: fsck: error 2 while executing fsck.ntfs
Mounting /mnt/P2…
[OK] Found device /dev/system/home.
[OK] Started Activation of LVM2 logical volumes.
[OK] Activated swap /dev/system/swap.
[FAILED] Failed to mount /mnt/P2.
See ‘systemctl status mnt-P2.mount’ for details.
Further down, I also get
[FAILED] Failed to start Recreate Volatile Files and Directories.

When I get to the rescue system prompt, using the root login (no password required), try to mount sdb, but fail:
Rescue:/etc# mount /dev/sdb /mnt
mount.bin: /dev/sdb is write-protected, mounting read-only
mount.bin: wrong fs type, bad option, bad superblock on /dev/sdb,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try “dmesg | tail” or so.

At this point, two solutions come to my mind:
(1) In Regular Mode, I need to try to stop the startup program from mounting sda3. How?
(2) In Rescue Mode, I would like to change the /etc/fstab entry, but cannot mount it unless I get an encryption password prompt first. How?

Any useful hints greatly appreciated.

#2

On 2014-01-11 11:56, rhett1butler wrote:

>
> I have two hard disks, one 120 GB Samsung EVO 840 SSD, and one 1 TB
> Samsung 7200 rpm spinning HDD.
> On the 120 GB disk I installed openSUSE 13.1 successfully, using LVM and
> encryption at login.

So, the main system is encrypted. Using LUKS, I guess.

> Next, I created two directories in the /mnt directory, called P2 and P3.
>
> Next, I made corresponding entries in the /etc/fstab file, using the vi
> editor. My two entries look like this
> /dev/sda2 /mnt/P2 ext3 defaults 1 1
> /dev/sda3 /mnt/P3 ext3 defaults 1 1
>
> Next, I installed truecrypt on the desktop and encrypted the sda3

Truecrypt, not LUKS, for the hard disk.

> Now my trouble begins:
> At the next restart, openSUSE 13.1 boots successfully until it gets to
> the password prompt for the encrypted disk.

I guess that it is the password for the system disk, the SSD, which is
using LUKS.

> It accepts my correct
> password, then apparently tries to mount P2 and P3, but fails,

Well, fstab says that those are plain unencrypted ext3 partitions, but
they are not. They are now encrypted with truecrypt

> Clearly, it is looking for an ext4 filesystem, but only finds ext3. This
> should not be an issue for a Linux operating system, but let’s think
> results oriented first: I physically remove the 1 TB disk causing the
> trouble, which is easy to do as I am using an ICY DOCK MB994SP-4S (which
> fantastic, BTW), then reboot the system. Removing the disk causes
> openSUSE to not even make it to the encryption password prompt, it
> crashes before it gets there.

It should jump to rescue mode, because fstab says to mount a device that
is no longer present. To avid that you have to edit fstab and mark P1
and P2 as “nofail”.

> 2.
> I insert my boot DVD, and enter Rescue Mode. In Rescue mode, I do not
> make it to the encryption password prompt either, it throws out messages
> to me such as:

I no longer use the rescue system on the DVD. Instead I download the
dedicated XFCE rescue image.

> systemd-fsck[566]: fsck: fsck.ntfs: not found
> systemd-fsck[566]: fsck: error 2 while executing fsck.ntfs
> Mounting /mnt/P2…

It should not be trying to mount that, because that is in the system
fstab. The rescue system should have no fstab, or rather a very
different fstab.

You should post your current partition tables, as seen by “fdisk -l” and
“blkid”. Your fstab file could be useful, too.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#3

Carlos answered most of the questions. But I’m not sure if he answered the one in the thread title.

To access the LVM from your rescue boot:


cryptsetup luksOpen /dev/sdXY cr_lvm
#### change that "sdXY" to the device name.
vgscan  ## not sure if this is really needed, and it will operate without any output
vgchange -a y  #### that makes the volumes accessible, but may also be silent
ls /dev/mapper   ### that will tell you something about what lvm volumes are now accessible to mount
#4

On 2014-01-11 19:06, nrickert wrote:
>
> rhett1butler;2615063 Wrote:
>> Any useful hints greatly appreciated.
>
> Carlos answered most of the questions. But I’m not sure if he answered
> the one in the thread title.

Mmm, right…
I have encrypted filesystems, but not combined with LVM :slight_smile:

I hoped the rescue system (not the one on the install disk) would mount
it automatically, and if not, then we’d see.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#5

Thank you for your input, also to robin_listas, your comments and suggestions are very much appreciated.

I just tried the above commands, here is my screen output:
>>>
Rescue: ~ # vgscan
No volume groups found
Rescue: ~ # vgchange -a y
No volume groups found
Rescue: ~ # ls /dev/mapper
control
Rescue: ~ # cryptsetup luksOpen /dev/sdb
Command requires device and mapped name as arguments.
Rescue: ~ # cryptsetup luksOpen /dev/sdb1
Usage: cryptsetup -?vyrq] -?|–help] --usage] --version] -v|–verbose] --debug] -c|–cipher=STRING] -h|–hash=STRING] -y|–verify-passphrase] -d|–key-file=STRING] --master-key=STRING] --dump-master-key] -r|–readonly] -i|iter-time=msecs] -q|–batch-mode] -t|–timeout=secs] -T|–tries=INT] --align-payload=SECTORS] --header-backup-file=STRING] --use-random] --shared] --uuid=STRING] --allow-discards] --header=STRING] --test-passphrase] --tcrypt-hidden] --tcrypt-system] -M|–type=STRING] --force-password] [OPTION…] <action> <action-specific>
cryptsetup: Unkown action.
Rescue: ~ # fdisk /dev/sdb
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p

Disk /dev/sdb: 120.0 GB, 120034123776 bytes, 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0001ceaa

Device Boot Start End Blocks Id System
/dev/sdb1 * 2048 819199 408576 83 Linux
/dev/sdb2 819200 234440703 116810752 8e Linux LVM

Command (m for help): q

Rescue: ~ # blkid
/dev/loop0: TYPE=“squashfs”
/dev/loop1: TYPE=“squashfs”
/dev/loop2: TYPE=“squashfs”
/dev/loop3: TYPE=“squashfs”
/dev/loop4: TYPE=“squashfs”
/dev/sda1: LABEL=P1" UUID="<16 character ID> TYPE=“ntfs”
/dev/sda2: UUID=“xxyyxxyy-xxyy-xxyy-xxyy-xxyyxxyyxxyy” TYPE=“ext3”
/dev/sdb1: UUID=“xxyyxxyy-xxyy-xxyy-xxyy-xxyyxxyyxxyy” TYPE=“ext4” PTTYPE=“dos”
/dev/sdb2: UUID=“xxyyxxyy-xxyy-xxyy-xxyy-xxyyxxyyxxyy” TYPE=“crypto LUKS”
/dev/sr0: UUID=“2013-11-06-20-55-31-00” LABEL="“openSUSE-13.1-DVD-x86_640091” TYPE=iso9660" PTTYPE=“dos”
<<<

Now, I could play around a little with the “cryptsetup” command to see what I can accomplish with it, thanks for the suggestion, nrickert!

At this point I may want to circumvent the problems I have with getting access via Rescue Mode by installing a second openSUSE operating system on the 600 GB spare partition sda2 (perhaps after splitting this partition into two so I have another spare partition left), then try to get access to sdb1 and sdb2 from there, so I can modify the /etc/fstab entries from this second openSUSE installation.

Alternatively, I have to do a fresh installation on the 120 GB, which is a nuissance, but does not involve any loss of data. I just do not like having to spend so much time updating and tweaking the setup until I have it the way it was (".)

I agree with the gist of what Robin_lista wrote as a possible explanation why my computer ends up in an endless loop: the boot script tries to mount sda3, but cannot mount it, probably because of truecrypt encryption. But it cannot stop trying because there is no “noauto” parameter set (I think “nofail” would not get me out of the loop).

I shall post any progress or new insights here.

Again, thank you for your valuable input, comments and suggestions. I very much appreciate it!

#6

On 2014-01-12 13:46, rhett1butler wrote:

> Thank you for your input, also to robin_listas, your comments and
> suggestions are very much appreciated.
>
> I just tried the above commands, here is my screen output:

Please do not forget to use CODE TAGS to post such things as that below.
You get them by clicking on the ‘#’ button on the editor. And don’t use
any extra formatting inside, such as bold or colors, please.

I’ll try to rebuild your part.


> *Rescue: ~ #* vgscan
> No volume groups found
> *Rescue: ~ #* vgchange -a y
> No volume groups found
> *Rescue: ~ #* ls /dev/mapper
> control
> *Rescue: ~ #* cryptsetup luksOpen /dev/sdb
> Command requires device and mapped name as arguments.

Notice that there is a missing word in the above when you compare it to
what nrickert told you to use. What about the “cr_lvm”?

That’s what the command is telling you to use. The manual tells you
about it, too.

(it is just an arbitrary name of your choosing)


> *Rescue: ~ #* fdisk /dev/sdb
> Welcome to fdisk (util-linux 2.23.2).

Just using “fdisk -l” produces the wanted output.

Now I have to rebuild your output to make it readable.


> Disk /dev/sdb: 120.0 GB, 120034123776 bytes, 234441648 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk label type: dos
> Disk identifier: 0x0001ceaa
>
> Device  Boot           Start          End      Blocks      Id      System
> /dev/sdb1    *         2048        819199      408576      83      Linux
> /dev/sdb2            819200     234440703   116810752      8e      Linux LVM



> *Rescue: ~ #* blkid
> /dev/loop0: TYPE="squashfs"
> /dev/loop1: TYPE="squashfs"
> /dev/loop2: TYPE="squashfs"
> /dev/loop3: TYPE="squashfs"
> /dev/loop4: TYPE="squashfs"
> /dev/sda1: LABEL=P1" UUID="<16 character ID> TYPE="ntfs"
> /dev/sda2: UUID="xxyyxxyy-xxyy-xxyy-xxyy-xxyyxxyyxxyy" TYPE="ext3"
> /dev/sdb1: UUID="xxyyxxyy-xxyy-xxyy-xxyy-xxyyxxyyxxyy" TYPE="ext4" PTTYPE="dos"
> /dev/sdb2: UUID="xxyyxxyy-xxyy-xxyy-xxyy-xxyyxxyyxxyy" TYPE="crypto LUKS"
> /dev/sr0: UUID="2013-11-06-20-55-31-00"
> LABEL=""openSUSE-13.1-DVD-x86_640091" TYPE=iso9660" PTTYPE="dos"

> At this point I may want to circumvent the problems I have with getting
> access via Rescue Mode by installing a second openSUSE operating system
> on the 600 GB spare partition sda2 (perhaps after splitting this
> partition into two so I have another spare partition left), then try to
> get access to sdb1 and sdb2 from there, so I can modify the /etc/fstab
> entries from this second openSUSE installation.

No, no need to install anything, unless you want to. Instead,
download… well, if you can, of course, you need another computer to do
the download, the so called XFCE rescue image from the openSUSE download
page, and copy it to an USB stick. It is very useful for any operation
such as this. It is way more powerful than the included rescue image in
the install DVD. The usb gets a writeable partition, so that
configuration changes remain across boots, and you can even install
packages to it (in 13.1, not in 12.3)

> I agree with the gist of what Robin_lista wrote as a possible
> explanation why my computer ends up in an endless loop: the boot script
> tries to mount sda3, but cannot mount it, probably because of truecrypt
> encryption. But it cannot stop trying because there is no “noauto”
> parameter set (I think “nofail” would not get me out of the loop).

Well, it really should stop! Stop and ask the admin to correct the
situation. That is what happened before systemd, when we had systemv.

> I shal post any progress or new insights here.
>
> Again, thank you for your valuable input, comments and suggestions. I
> very much appreciate it!

Welcome :slight_smile:

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#7

Noted, Robin_listas, thank you for the instructions how to use the # (“hash”) key.

As to your request regarding the missing “cr_lvm” in the command: I had forgotten to type it up, but for the avoidance of any doubt or ambiguity: it does not make any difference, the output is the same, the command is unsuccessful:


Rescue:~ # cryptsetup luksopen /dev/sdb1 cr_lvm
Usage: cryptsetup -?vyrq] -?|--help] --usage] --version]  -v|--verbose] --debug] -c|--cipher=STRING] -h|--hash=STRING]  -y|--verify-passphrase] -d|--key-file=STRING] --master-key=STRING]  --dump-master-key] -r|--readonly] -i|iter-time=msecs]  -q|--batch-mode] -t|--timeout=secs] -T|--tries=INT]  --align-payload=SECTORS] --header-backup-file=STRING] --use-random]  --shared] --uuid=STRING] --allow-discards] --header=STRING]  --test-passphrase] --tcrypt-hidden] --tcrypt-system]  -M|--type=STRING] --force-password] [OPTION...] <action>  <action-specific>
cryptsetup: Unknown action.

It also does not make any difference whether I use “sdb” or “sdb1” in the command above.

#8

It’s luksOpen. Capital “o”. cryptsetup also has manual page.

#9

Thanks arvidjaar, for pointing it out to me. The response from the system is slightly different, but it does not work yet either. Neither does “open” instead of “luksOpen” work:



Rescue:~ # cryptsetup luksOpen /dev/sdb1 cr_lvm
Device /dev/sdb1 is not a valid LUKS device.
Rescue:~ # cryptsetup luksOpen /dev/sdb cr_lvm
Device /dev/sdb is not a valid LUKS device.
Rescue:~ # cryptsetup open /dev/sdb1 cr_lvm
Device /dev/sdb1 is not a valid LUKS device.

I have read the manual page and am trying several variations.
Thank you again for your valuable input and for providing a critical eye.

#10

On 2014-01-12 15:56, rhett1butler wrote:

> Code:
> --------------------
>
>
> Rescue:~ # cryptsetup luksOpen /dev/sdb1 cr_lvm
> Device /dev/sdb1 is not a valid LUKS device.
>
> --------------------

Well, it is obvious that sdb1 is not a valid LUKS device. Insistence is
futile.

Find out what it is:


file -s /dev/sdb1

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#11

Thanks for your new input.

I have now installed a second openSUSE 13.1 operating system on the 120 GB SSD (“sda”), where the truecrypt partition sda3 resides.
I am trying to access the 1 TB HDD (“sdb”), which is a LUKS encrypted LVM. Booting the computer with both disks present was a bit “unorthodox”, as it now has two bootable partitions, but it booted into the “right” (new, unencrypted) disk, which is sda, which is what I wanted.

Apparently, I did mount both sdb1 (boot partition) and sdb2 (LVM partition) the LUKS encrypted partition successfully. Here are screenshots of what I did to get there. I hope I got the scripts in the right order.


   

   
caceres:~ # fdisk /dev/sdb
 Welcome to fdisk (util-linux 2.23.2).
 

 Changes will remain in memory only, until you decide to write them.
 Be careful before using the write command.
 

 

 Command (m for help): p
 

 Disk /dev/sdb: 120.0 GB, 120034123776 bytes, 234441648 sectors
 Units = sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk label type: dos
 Disk identifier: 0x0001ceaa
 Device   Boot   Start       End    Blocks   Id   System
 /dev/sdb1   *    2048    819199    408576   83    Linux
 /dev/sdb2      819200 234440703 116810752   8e    Linux LVM
 Command (m for help): q
 caceres:~ # mount /dev/sdb /mnt
 mount: /dev/sdb is write-protected, mounting read-only
 mount: wrong fs type, bad option, bad superblock on /dev/sdb,
 missing codepage or helper program, or other error
 In some cases useful info is found in syslog - try
 dmesg | tail or so.









   caceres:/mnt # cryptsetup luksOpen /dev/sdb2 cr_lvm
 Enter passphrase for /dev/sdb2:
 caceres:/mnt # cd /lvmdirectory
 bash: cd: /lvmdirectory: No such file or directory
 caceres:/mnt # ls -l
 total 39757
 -rw-r--r-- 1 root root  2697475 Nov  1 12:58 System.map-3.11.6-4-desktop
 -rw-r--r-- 1 root root      512 Dec 28 14:51 backup_mbr
 lrwxrwxrwx 1 root root        1 Dec 28 14:47 boot -> .
 -rw-r--r-- 1 root root     1484 Oct 18 07:48 boot.readme
 -rw-r--r-- 1 root root   140360 Nov  1 11:17 config-3.11.6-4-desktop
 drwxr-xr-x 2 root root     1024 Dec 28 14:47 grub
 drwxr-xr-x 7 root root     1024 Dec 29 04:36 grub2
 lrwxrwxrwx 1 root root       23 Dec 29 04:36 initrd -> initrd-3.11.6-4-desktop
 -rw------- 1 root root 25681164 Dec 29 04:36 initrd-3.11.6-4-desktop
 drwx------ 2 root root    12288 Dec 28 14:37 lost+found
 drwxr-xr-x 2 root root     1024 Jan 12 17:04 lvmdirectory
 -rw-r--r-- 1 root root   620544 Nov  6 19:54 message
 -rw-r--r-- 1 root root   261933 Nov  1 13:23 symvers-3.11.6-4-desktop.gz
 -rw-r--r-- 1 root root      516 Nov  1 13:23 sysctl.conf-3.11.6-4-desktop
 -rw-r--r-- 1 root root  6075542 Nov  1 13:22 vmlinux-3.11.6-4-desktop.gz
 lrwxrwxrwx 1 root root       24 Dec 28 14:46 vmlinuz -> vmlinuz-3.11.6-4-desktop
 -rw-r--r-- 1 root root  5210216 Nov  1 18:33 vmlinuz-3.11.6-4-desktop
 caceres:/mnt #
 





   caceres:/dev/mapper # mount
 devtmpfs on /dev type devtmpfs (rw,relatime,size=4078320k,nr_inodes=1019580,mode=755)
 tmpfs on /dev/shm type tmpfs (rw,relatime)
 tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
 devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
 /dev/sda6 on / type ext4 (rw,relatime,data=ordered)
 proc on /proc type proc (rw,relatime)
 sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
 securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
 tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
 cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/syste
 md-cgroups-agent,name=systemd)
 pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
 cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
 cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
 cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
 cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
 cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
 cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
 cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
 cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
 cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
 systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=32,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
 hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
 mqueue on /dev/mqueue type mqueue (rw,relatime)
 debugfs on /sys/kernel/debug type debugfs (rw,relatime)
 tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,relatime,mode=755)
 tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
 /dev/sda7 on /home type ext4 (rw,relatime,data=ordered)
 /dev/sdb1 on /mnt type ext4 (rw,relatime,data=ordered)
 gvfsd-fuse on /run/user/0/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
 gvfsd-fuse on /var/run/user/0/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
 fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
 caceres:/dev/mapper #






caceres:/dev/mapper # file -s /dev/sdb1
/dev/sdb1: DOS/MBR boot sector

but now I cannot access cr_lvm, at least I don’t know how.
The objective for me now is to access /etc/fstab and remove the entries instrucing the boot loader to mount the TRUECRYPT encrypted, ext3 formatted partition sda3, correct me if I am wrong, or if I am off track.

#12

CORRECTION to my previous post:
I installed the second, new operating system on sda, the 1TB disk, to rescue the LUKS encrypted operating system on the 120 GB sdb disk.
So, it is exactly the other way around from what I wrote in the post above. Sorry for causing confusion.

An add-on to my post just now:
I did mount /dev/sdb1 successfully using the command originally suggested by nrickert, which was:



caceres:/mnt # cryptsetup luksOpen /dev/sdb1 cr_lvm

The new LINUX partitions of the new, unencrypted openSUSE installation look like this in the /etc/fstab file:


 
/dev/disk/by-id/ata-SAMSUNG_HN-M101MBB_S2RXJ1NB900186-part5          swap       defaults              0 0
/dev/disk/by-id/ata-SAMSUNG_HN-M101MBB_S2RXJ1NB900186-part6 /        ext4        acl,user_xattr       1 1
/dev/disk/by-id/ata-SAMSUNG_HN-M101MBB_S2RXJ1NB900186-part7 /home    ext4        acl,user_xattr       1 2
~
#13

Sigh!

Here’s an excerpt from a command line session where I did the kind of thing that you wanted. I’ll intersperse with commentary.


# gdisk -l /dev/sdc
GPT fdisk (gdisk) version 0.8.7
...
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          401407   195.0 MiB   8300  Linux filesystem
   2          401408       231094271   110.0 GiB   8E00  Linux LVM
   3       231094272      1250263039   486.0 GiB   8300  Linux filesystem

I skipped some of the details there. As you can see, “/dev/sdc2” is an LVM, and it happens to be encrypted (which you cannot see from the “gdisk” output). The disk is GPT partitioned for a UEFI box, which is why I used “gdisk”.


# cryptsetup luksOpen /dev/sdc2 cr_lvm
Enter passphrase for /dev/sdc2: 
# ls /dev/mapper
control                                   cr_lvm     suselvm-home  suselvm-swap
cr_ata-ST1000DM003-9YN162_Z1D31DG1-part3  cr_shared  suselvm-root

I used “cryptsetup” for the particular partition. The passphrase does not show in the “typescript” file generated using the “script” command. Then I listed “/dev/mapper”. The only new entry there is “cr_lvm”. The other entries have to do with what I am normally using.


# vgscan
# vgchange -a y
# ls /dev/mapper
control                                   homesys-home  suselvm-root
cr_ata-ST1000DM003-9YN162_Z1D31DG1-part3  homesys-root  suselvm-swap
cr_lvm                                    homesys-swap
cr_shared                                 suselvm-home

I’m not sure if the “vgscan” is actually needed. The “vgchange” makes all lvm volumes visible. The subsequent listing of “/dev/mapper” show “homesys-root”, “homesys-home” and “homesys-swap” as the new entries. I could then have mounted “/dev/mapper/homesys-root” to access the root file system from that LVM.

As background, I am running 13.1 from an encrypted LVM. What I just did and described gave me access to the encrypted LVM where 12.3 is installed. I occasionally boot into that 12.3 to run updates, but eventually that will become my test system for 13.2.

I hope that helps.

#14

You are a star!
…and very patient with me, too! Thank you so much!

Here is my output, using your string of commands:


caceres:~ # vgscan
caceres:~ # vgchange -a y
caceres:~ # ls /dev/mapper  control  cr_lvm  system-home  system-root  system-swap  truecrypt3
caceres:~ # ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Jan 12 16:54 control
lrwxrwxrwx 1 root root       7 Jan 12 17:05 cr_lvm -> ../dm-0
lrwxrwxrwx 1 root root       7 Jan 12 19:22 system-home -> ../dm-2
lrwxrwxrwx 1 root root       7 Jan 12 19:22 system-root -> ../dm-3
lrwxrwxrwx 1 root root       7 Jan 12 19:22 system-swap -> ../dm-4
lrwxrwxrwx 1 root root       7 Jan 12 19:16 truecrypt3 -> ../dm-1
caceres:/dev/mapper # mount system-home /mnt
caceres:/dev/mapper # mount system-root /mnt

listing the /dev directory shows this (excerpt):


lrwxrwxrwx  1 root root          14 Jan 12 16:54 device-mapper -> mapper/control
drwxr-xr-x  6 root root         120 Jan 12 16:54 disk
brw-rw----  1 root disk    253,   0 Jan 12 17:05 dm-0
brw-rw----  1 root disk    253,   1 Jan 12 19:16 dm-1
brw-rw----  1 root disk    253,   2 Jan 12 19:22 dm-2
brw-rw----  1 root disk    253,   3 Jan 12 19:22 dm-3
brw-rw----  1 root disk    253,   4 Jan 12 19:22 dm-4
drwxr-xr-x  2 root root         120 Jan 12 16:54 dri
lrwxrwxrwx  1 root root           3 Jan 12 16:54 dvd -> sr0
lrwxrwxrwx  1 root root           3 Jan 12 16:54 dvdrw -> sr0

I will now try to access /etc/fstab, but it is getting late over here… – 3.45 AM in the morning.

Again: Thanks so much!

#15

On 2014-01-12 19:36, rhett1butler wrote:

> Code:
> --------------------
>
> caceres:~ # fdisk /dev/sdb

Use “fdisk -l /dev/sdb” instead. Memorize that “-l” option. Less dangerous.

> Device Boot Start End Blocks Id System
> /dev/sdb1 * 2048 819199 408576 83 Linux
> /dev/sdb2 819200 234440703 116810752 8e Linux LVM

> caceres:~ # mount /dev/sdb /mnt
> mount: /dev/sdb is write-protected, mounting read-only
> mount: wrong fs type, bad option, bad superblock on /dev/sdb,

Of course you can not mount “/dev/sdb”, that’s the entire disk!

> --------------------

> Code:
> --------------------

> caceres:/mnt # cryptsetup luksOpen /dev/sdb2 cr_lvm
> Enter passphrase for /dev/sdb2:
> caceres:/mnt # cd /lvmdirectory

Why do you change that? The “cryptsetup luksOpen” creates a mapped
device, but it does not mount it.

nrickert wonderfully explains what you have to do in his last post.

> --------------------

> Code:
> --------------------

> caceres:/dev/mapper # file -s /dev/sdb1
> /dev/sdb1: DOS/MBR boot sector
>
> --------------------

As expected. If you repeat that on /dev/sdb1 you would see something
different.

> but now I cannot access cr_lvm, at least I don’t know how.

I expect you see how to do that after reading nrickert post.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#16

Accessing fstab is now a breeze:



   caceres:/etc # cd /mnt
 caceres:/mnt # ls -l
 total 148
 -rw-r--r--   1 root root 24697 Jan 11 15:54 .readahead
 drwxr-xr-x   2 root root  4096 Jan  9 12:17 bin
 drwxr-xr-x   2 root root  4096 Dec 28 14:37 boot
 drwxr-xr-x   2 root root  4096 Dec 28 14:37 dev
 drwxr-xr-x 145 root root 12288 Jan 10 20:02 etc
 drwxr-xr-x   2 root root  4096 Dec 28 14:37 home
 drwxr-xr-x  14 root root  4096 Jan  9 12:17 lib
 drwxr-xr-x   7 root root 12288 Jan  9 12:17 lib64
 drwx------   2 root root 16384 Dec 28 14:37 lost+found
 drwxr-xr-x   2 root root  4096 Jan 10 20:00 media
 drwxr-xr-x   5 root root  4096 Jan 10 13:36 mnt
 drwxr-xr-x   3 root root  4096 Dec 29 07:09 opt
 drwxr-xr-x   2 root root  4096 Dec 28 14:37 proc
 drwx------  29 root root  4096 Jan 10 20:02 root
 drwxr-xr-x   2 root root  4096 Dec 28 14:37 run
 drwxr-xr-x   2 root root 12288 Jan  9 12:17 sbin
 drwxr-xr-x   2 root root  4096 Sep 27 21:24 selinux
 drwxr-xr-x   6 root root  4096 Dec 28 14:47 srv
 drwxr-xr-x   2 root root  4096 Dec 28 14:37 sys
 drwxrwxrwt  56 root root  4096 Jan 10 20:02 tmp
 drwxr-xr-x  13 root root  4096 Nov  6 19:53 usr
 drwxr-xr-x  16 root root  4096 Dec 28 14:43 var
 caceres:/mnt # cd /mnt/etc
 caceres:/mnt/etc #

fstab before deleting the sda3 mounting entry, that caused the computer to hang during boot:



   vi fstab:

 

 dev/system/swap     swap                 swap       defaults              0 0
 /dev/system/root     /                    ext4       acl,user_xattr        1 1
 /dev/disk/by-id/ata-Samsung_SSD_840_EVO_120GB_S1D5NSADA31861L-part1 /boot                ext4       acl,user_xattr        1 2
 /dev/system/home     /home                ext4       defaults              1 2
 /dev/sda1            /mnt/P1              ntfs       defaults              1 1
 /dev/sda2            /mnt/P2              ext3       defaults              1 1
 /dev/sda3            /mnt/P3              ext3       defaults              1 1

and after:



vi fstab:

 
 dev/system/swap     swap                 swap       defaults              0 0
 /dev/system/root     /                    ext4       acl,user_xattr        1 1
 /dev/disk/by-id/ata-Samsung_SSD_840_EVO_120GB_S1D5NSADA31861L-part1 /boot                ext4       acl,user_xattr        1 2
 /dev/system/home     /home                ext4       defaults              1 2
#17

On 2014-01-12 21:16, rhett1butler wrote:

> fstab before deleting the sda3 mounting entry, that caused the computer
> to hang during boot:
>
>
> Code:
> --------------------
>
>
> vi fstab:
>
> dev/system/swap swap swap defaults 0 0
> /dev/system/root / ext4 acl,user_xattr 1 1
> /dev/disk/by-id/ata-Samsung_SSD_840_EVO_120GB_S1D5NSADA31861L-part1 /boot ext4 acl,user_xattr 1 2
> /dev/system/home /home ext4 defaults 1 2
> /dev/sda1 /mnt/P1 ntfs defaults 1 1
> /dev/sda2 /mnt/P2 ext3 defaults 1 1
> /dev/sda3 /mnt/P3 ext3 defaults 1 1
>
> --------------------

Just a comment.

It is better not to use entries such as “/dev/sda”, because they are not
guaranteed to be permanent. I personally prefer the syntax
“LABEL=something”, but anything like “/dev/disk/by-XXX/YYY” is good.

I see those were the entries you removed, anyway.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#18

Thanks, robin_listas, for your support yesterday. Your input and guidance made a huge difference and helped me along.

Yes, I have removed the entries in the /etc/fstab that caused the computer to hang indefinitely.
However, curiously, the problem of openSUSE with ext3 filesystems seems to persist, as evidenced by the following.


segovia:~ # mount
devtmpfs on /dev type devtmpfs (rw,relatime,size=4077664k,nr_inodes=1019416,mode=755)
tmpfs on /dev/shm type tmpfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
/dev/mapper/system-root on / type ext4 (rw,relatime,data=ordered)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=28,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/mapper/system-home on /home type ext4 (rw,relatime,data=ordered)
/dev/sdb1 on /boot type ext4 (rw,relatime,data=ordered)
gvfsd-fuse on /run/user/0/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
gvfsd-fuse on /var/run/user/0/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
truecrypt on /tmp/.truecrypt_aux_mnt1 type fuse.truecrypt (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
/dev/mapper/truecrypt3 on /media/truecrypt3 type ext3 (rw,relatime,data=ordered)
/dev/sda1 on /run/media/root/P1 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
/dev/sda1 on /var/run/media/root/P1 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
segovia:~ # fdisk /dev/sda -l

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors                                                                        
Units = sectors of 1 * 512 = 512 bytes                                                                                                   
Sector size (logical/physical): 512 bytes / 512 bytes                                                                                    
I/O size (minimum/optimal): 512 bytes / 512 bytes                                                                                        
Disk label type: dos                                                                                                                     
Disk identifier: 0x000841a6                                                                                                              
                                                                                                                                         
   Device Boot      Start         End      Blocks   Id  System                                                                           
/dev/sda1               2   351824649   175912324    7  HPFS/NTFS/exFAT                                                                  
/dev/sda2       351824650   937762180   292968765+  83  Linux                                                                            
/dev/sda3      1523699712  1953525167   214912728   83  Linux                                                                            
/dev/sda4       937762181  1523699711   292968765+  a6  OpenBSD                                                                          
                                                                                                                                         
Partition table entries are not in disk order                                                                                            
segovia:~ # blkid                                                                                                                        
/dev/sdb1: UUID="229898e8-376b-4ad0-ac33-75eede360849" TYPE="ext4" PTTYPE="dos"                                                          
/dev/sdb2: UUID="224bd52d-4ccc-4459-96c5-4ab52ca2482d" TYPE="crypto_LUKS"                                                                
/dev/sda1: LABEL="P1" UUID="62EA0D07160059DB" TYPE="ntfs"                                                                                
/dev/sda2: UUID="efec197d-b9c8-4e1b-aec0-be1ab5e6f4bb" TYPE="ext3"                                                                       
/dev/mapper/cr_ata-Samsung_SSD_840_EVO_120GB_S1D5NSADA31861L-part2: UUID="H9Mk3L-5wOr-WzL1-KC7z-XfYX-pgKw-1NI3cr" TYPE="LVM2_member"     
/dev/mapper/system-home: UUID="6bb64170-4662-4336-8a7b-fc21879aa8fd" TYPE="ext4"                                                         
/dev/mapper/system-root: UUID="02f71199-55a3-47f2-97e6-d121609f2026" TYPE="ext4"                                                         
/dev/mapper/system-swap: UUID="153ed854-6d37-4a39-a275-324255876af8" TYPE="swap"                                                         
/dev/mapper/truecrypt3: UUID="cd11efb2-063a-4ba9-851e-13abbd0ed8cd" TYPE="ext3"                                                          
segovia:~ #

Opening the Dolphin File Manager and trying to access sda2 formatted in ext3, I get a red box at the top of the screen stating

An error occurred while accessing ‘279.4 GiB Hard Drive’, the system responded: The requested operation has failed: Error mounting /dev/sda2 at /run/media/root/efec197d-b9c8-4e1b-aec0-be1ab5e6f4bb: Command-line `mount -t “ext3” -o “uhelper=udisks2,nodev,nosuid” “/dev/sda2” “/run/media/root/efec197d-b9c8-4e1b-aec0-be1ab5e6f4bb”’ exited with non-zero exit status 32: mount: wrong fs type, bad option, bad superblock on /dev/sda2, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so.
<<<

At the same time, even though the partition sda3 for truecrypt is also formatted in ext3, the operating system has no trouble finding and mounting this partition.
*

I wonder what causes the trouble with ext3. This time, I have no specific entry in the /etc/fstab. Truecrypt can access its ext3 formatted ext3 partition sda3, but Dolphin File Manager cannot give me access to the equally ext3 formatted partition sda2.

sda4 partition is reserved as playground for softraid(4) under OpenBSD. I’d like to see how easy or difficult it is to handle in comparison to LVM and Truecrypt. I am very impressed by the reliability and especially: portability, of Truecrypt across different operating systems. OpenSUSE Linux has also impressed me by – without a single compaint! – mounting an HFS+ formatted Truecrypt partition I had created on an Mac OS X platform, so overall I greatly appreciate Linux for its versatility and robustness. This is why I find the trouble Linux is causing me with one of their own, ext3, filesystems astounding and puzzling.*

#19

On 2014-01-13 11:16, rhett1butler wrote:
>
> Thanks, robin_listas, for your support yesterday. Your input and
> guidance made a huge difference and helped me along.
>
> Yes, I have removed the entries in the /etc/fstab that caused the
> computer to hang indefinitely.
> However, curiously, the problem of openSUSE with ext3 filesystems seems
> to persist, as evidenced by the following.


>   segovia:~ # mount
....
>   /dev/mapper/system-root on / type ext4 (rw,relatime,data=ordered)
....
>   /dev/mapper/system-home on /home type ext4 (rw,relatime,data=ordered)
>   /dev/sdb1 on /boot type ext4 (rw,relatime,data=ordered)
....
>   truecrypt on /tmp/.truecrypt_aux_mnt1 type fuse.truecrypt (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
>   /dev/mapper/truecrypt3 on /media/truecrypt3 type ext3 (rw,relatime,data=ordered)
>   /dev/sda1 on /run/media/root/P1 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
>   /dev/sda1 on /var/run/media/root/P1 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)



>   segovia:~ # fdisk /dev/sda -l
>
>   Disk /dev/sda: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
.....
>   Device Boot      Start         End      Blocks   Id  System
>   /dev/sda1               2   351824649   175912324    7  HPFS/NTFS/exFAT
>   /dev/sda2       351824650   937762180   292968765+  83  Linux
>   /dev/sda3      1523699712  1953525167   214912728   83  Linux
>   /dev/sda4       937762181  1523699711   292968765+  a6  OpenBSD



>   Partition table entries are not in disk order
>   segovia:~ # blkid
>   /dev/sdb1: UUID="229898e8-376b-4ad0-ac33-75eede360849" TYPE="ext4" PTTYPE="dos"
>   /dev/sdb2: UUID="224bd52d-4ccc-4459-96c5-4ab52ca2482d" TYPE="crypto_LUKS"
>   /dev/sda1: LABEL="P1" UUID="62EA0D07160059DB" TYPE="ntfs"
>   /dev/sda2: UUID="efec197d-b9c8-4e1b-aec0-be1ab5e6f4bb" TYPE="ext3"
>   /dev/mapper/cr_ata-Samsung_SSD_840_EVO_120GB_S1D5NSADA31861L-part2: UUID="H9Mk3L-5wOr-WzL1-KC7z-XfYX-pgKw-1NI3cr" TYPE="LVM2_member"
>   /dev/mapper/system-home: UUID="6bb64170-4662-4336-8a7b-fc21879aa8fd" TYPE="ext4"
>   /dev/mapper/system-root: UUID="02f71199-55a3-47f2-97e6-d121609f2026" TYPE="ext4"
>   /dev/mapper/system-swap: UUID="153ed854-6d37-4a39-a275-324255876af8" TYPE="swap"
>   /dev/mapper/truecrypt3: UUID="cd11efb2-063a-4ba9-851e-13abbd0ed8cd" TYPE="ext3"
>   segovia:~ #

Ok…

Opening the Dolphin File Manager and trying to access sda2 formatted in
ext3, I get a red box at the top of the screen stating

I prefer direct “mount -v” commands in a terminal, they are easier to
understand. Even if there is no corresponding fstab entry, you can do it
manually:


mount -v /dev/sda2   /mnt/P2



> In some cases useful info is found in syslog - try dmesg | tail or
> so.

This section of the output is important, you should do as it recomends
to find out more info, if it exists.

At the same time, even though the partition sda3 for truecrypt is also
formatted in ext3, the operating system has no trouble finding and
mounting this partition.

Yet sda2 is listed in the blkid output and sda3 is not.

Ah. No, you can not post photos as user. Instead what we do is upload
the photos to susepaste.org and here post a link to it.

I wonder what causes the trouble with ext3. This time, I have no
specific entry in the /etc/fstab. Truecrypt can access its ext3
formatted ext3 partition sda3, but Dolphin File Manager cannot give me
access to the equally ext3 formatted partition sda2.

Notice that you can add again the faulty sda2/3 entries in fstab, with
the nofail parameter:


/dev/sda2   /mnt/P2     ext3    nofail        1 1
/dev/sda3   /mnt/P3     ext3    nofail        1 1

This way, if the mount fail boot will continue, not abort. However, you
do not get an error message either ¡when you run “mount”, the message
goes to the log only. If it goes at all. You have to run a second
command, like a file listing, to find out if it mounted or not.

sda4 partition is reserved as playground for softraid(4) under OpenBSD.
I’d like to see how easy or difficult it is to handle in comparison to
LVM and Truecrypt. I am very impressed by the reliability and
especially: portability, of Truecrypt across different operating
systems. OpenSUSE Linux has also impressed me by – without a single
compaint! – mounting an HFS+ formatted Truecrypt partition I had
created on an Mac OS X platform, so overall I greatly appreciate Linux
for its versatility and robustness. This is why I find the trouble Linux
is causing me with one of their own, ext3, filesystems astounding and
puzzling.

Problems are always puzzling till the solution is found :slight_smile:

You could run these commands:


file -s /dev/sda2
file -s /dev/sda3

to find out what is different about each one.

And then, mount them manually (with the fstab line in existence):


mount -v /mnt/P2

And see what it says…

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
*

#20

[QUOTE=robin_listas;2615583]

> *

Ah. No, you can not post photos as user. Instead what we do is upload
the photos to susepaste.org and here post a link to it.



Here are the links to the pictures showing that Truecrypt has no trouble with handling the ext3 format, where some part of Linux openSUSE 13.1 fails.

http://www.susepaste.org/64897563 
http://www.susepaste.org/24957085
http://www.susepaste.org/18427435

Dolphin File Manager is just the messenger of the bad news, not the culprit.*