This is a continuation of the symptoms reported with bug 107680. That problem was worked around by some additional mount options in /etc/fstab under under 2.6.12-gentoo-r10, but this fails to work under to 2.6.13-gentoo-r3. The filesystem can still be mounted under under 2.6.12-gentoo-r10, even though util-linux was upgraded to 2.12r from util-linux-2.12q, so the thing that changed must have been in the kernel. Reproducible: Always Steps to Reproduce: 1. See bug 107680, only use 2.6.13-gentoo-r3 instead of 2.6.12-gentoo-r10. Actual Results: See bug 107680, only use 2.6.13-gentoo-r3 instead of 2.6.12-gentoo-r10. Expected Results: The encrypted reiserfs filesystem should have mounted the same way it does under 2.6.12-gentoo-r10
So what exactly is the error you are getting when trying to mount? Can you attach your current fstab for clarification?
ezekiel ~ # uname -a Linux ezekiel.elilabs.com 2.6.12-gentoo-r10 #1 Thu Sep 29 16:04:42 EDT 2005 i686 AMD Athlon(tm) AuthenticAMD GNU/Linux The relevant lines from /etc/fstab are: /dev/md0 /crypto_raid reiserfs noauto,encryption=AES256,phash=unhashed2 0 0 /dev/cdrom /crypto_dvd squashfs noauto,ro,encryption=AES256,phash=unhashed2 0 0 Please see bug 107680 for further details. The symptoms are the same that I was experiencing there before changing the /etc/fstab entries to those shown above.
I've glanced over the bug but am still unclear on this: So what exactly is the error you are getting when trying to mount?
As it is the start of a new month, and the machine in question is my backup server, it will be busy making archival backups for another day or so; therefore, I cannot reb oot it to get it running 2.6.13-r3. It is presently running 2.6.12-r10 as a workaraound for this problem. As soon as I can reboot into 2.6.13-r3, I will provide exact copy of the error message, but basicly, it says I need a longer password, and fails to mount the drive because it decrypts it incorrectly.
Please reopen when you provide more info
OK, I just booted the system into 2.6.13-gentoo-r3: [code]ezekiel ~ # uname -a Linux ezekiel.elilabs.com 2.6.13-gentoo-r3 #2 Mon Oct 10 15:09:26 EDT 2005 i686 AMD Athlon(tm) AuthenticAMD GNU/Linux[/code] Now to try to mount an aes256 encrypted filesystem. First, here is the relevant entry in [color=green]/etc/fstab[/color]:[code]/dev/md0 /crypto_raid reiserfs noauto,encryption=AES256,phash=unhashed2 0 0[/code] Now we attampt to mount with an 8 char password, which we [u]must[/u] use, since that is the wat the filesystem was created long ago:[code]ezekiel ~ # mount /crypto_raid/ Password: WARNING - Please use longer password (20 or more characters) mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so ezekiel ~ # [/code] So it fails the mount, yet if I boot back into 2.6.12-gentoo-r10:[code]ezekiel ~ # uname -a Linux ezekiel.elilabs.com 2.6.12-gentoo-r10 #1 Thu Sep 29 16:04:42 EDT 2005 i686 AMD Athlon(tm) AuthenticAMD GNU/Linux[/code] And try to mount the same fiolesystem, using the same [color=green]/etc/fstab[/color]:[code}ezekiel ~ # mount /crypto_raid/ Password: WARNING - Please use longer password (20 or more characters) ezekiel ~ # [/code] And the filesystem mounts just fine, but with a warning that still would only make sense if one were creating a new filesystem; after all, one does not have the option to mount an already existing filesystem with a different password just because the requirements were changed after the original filesystem was created. It needs to be stresses that although the above example was using a RAID-1 on hard disk drives, there are also literraly hundreds of archival backup dvds encrypted the samew waay -- with an 8 char password -- so the option of converting everything over to longer passwords is really out of the question. What is needed is a way to mount these filesystems -- especially the dvds -- using a short password, otherwise I will have to keep a system around running 2.6.12 for 5 more years just to insure the ability to read the archival dvds. Is there some reason why we cannot just have a command line option to mount or losetup that will override the long password requirement? That really should not be too hard to do.
Oops! Sorry about the phpbb [code] and [color] tags. I forgot I was in bugzilla. :-(
If you are bothered by the warning then you should file a separate bug for that. When you tried to mount it under 2.6.13, it said: mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so Did you try that? Can we see the results? (Ideally the whole of dmesg as an attachment, *after* you have tried to mount). It would also be a good idea to reproduce this on the latest development kernel (currently vanilla-sources-2.6.15_rc4)
Listen carefully! This is a very simple problem caused by what someone thought was a good idea. Newer kernels and the newer mount program are now enforcing the "good idea": make the user enter a long (20 char) password. This is great for creating a new filesystem, but it absolutely is totally moronic for a pre-existing filesystem. One does not have the option of entering a 20 char password for a filesystem that was created long ago with a shorter password. All that is needed is an option, such as --short-password or some such thing, to mount, to allow the user to proceed without forcing him to enter a long password. Why is everybody having such a hard time understanding this?
That would be a valid explanation, but are you sure? The message you posted says: > WARNING - Please use longer password (20 or more characters) That doesn't sound like an actual error, for the reason that it says it's a WARNING, and also the reason it is phrased like a suggestion rather than a requirement. You also saw this message on previous kernels (right?) so it's not like its something new. Am I missing something? Maybe you are basing your conclusion on something else that I'm not seeing...
If you will look at bug 107680, which is referenced in the original post here, you will see that previously, the change was made to mount that required the user to enter a 20 char passphrase, but if I used an earlier version of mount, it would take my short password and go ahead and mount the filesystem. With some help from a thread I started on gentoo forums, I was able to add some options to the entry in /etc/fstab for the filesystem so that it would work with the newer version of mount. Then a kernel update came along, and even with the older version of mount, or with the options that worked before with the newer version of mount, it still refused to accept my short password, and therefor failed to mount the filesystem. So to sum it up, the problem was first caused by a newer version of mount (and losetup), and then when the newer kernel was installed, it failed even with the old version of mount. So I am now still running with the old kernel and the new version of mount and the aforementioned options in my /etc/fstab, but I fear that I will have to make a special livecd with a big ram disk so I can boot from the live cd and then have it copy the squashfs to the big ram disk, so that I can put an encrypted backup dvd into the cd/dvd drive and read it; otherwise, I will not be able to keep the system anywhere near up to date and still be able to read my backup dvds. I am planning to switch to the longer password at the end of the year, but I will still need to be able to read those older encrypted dvds that still have the short password. Newer backup dvds will use the long password, as will the online raid-1 mirror. It is still hard for me to believe that I am the only person who has encountered a problem with this. Am I the only person who actually encrypts my backups?
Ok, but you are jumping to conclusions. I'm not convinced that the new kernel is imposing a 20 character minimum length or has dropped that parameter. Of course, you might be totally correct, but I don't see any true information here which confirms that. If you want my help, you have to convince me of this :) So, please get the dmesg output I asked for in comment #8.
OK, but it will be a few days before I can get the dmesg output, as the system is busy doing monthly archival backups right now. Hopefully Monday or Tuesday I will post the output you requested. Remember, I have to reboot into the newer kernel to do this. Sorry about the delay.
When you test this, it would also be useful to see the output of a straced mount attempt, i.e.: # strace -f -o mount.strace mount /crypto_raid/ Then upload the 'mount.strace' output file here.
Some other things to try and useful info to check: Is util-linux compiled with USE=crypt? Which version of loop-aes is installed? Have you rebuilt it since you upgraded kernel? (this is necessary because loop-aes is a kernel module) You can check this by posting the output of "equery files loop-aes" (equery is in the gentoolkit package0 Output of this would be interesting: grep LOOP /usr/src/linux/.config This is looking less an less like a kernel problem. The encryption= and phash= options are not sent to the kernel at all. They are handled by util-linux. Also, the block driver used to mount this is loop-aes, which is not part of the kernel, it is an external package.
I havethis problem as well Robert. Only it is even worse, as I have a whole volume of work-related source code (6 GB worth) in an encrypted volume that as of this morning I am totally unable to access. I have been trying *everything* I can think of, rolling back util-linux, rolling back the kernel, using every phash method I can come across, all with no success, because near as I can tell the encryption must rely on some specific version of the kernel/util-linux and some specific phash to actually work. All in all I have wasted the past 6 hours on this, before I even found this bug report - there does not seem to be much help for this problem anywhere, even though I have found it reported in several places I have seen few solutions, other than rebooting off an old OS to extract the data. I will now try booting off a 2004 live CD to see if I can access the data that way (been downloading now for the past hour, such an old ISO is only available on slow mirrors now). Personally, I can not believe that someone would change such a core thing as the loopback encryption method without either leaving in a compatibility layer that auto-detects the old encryption type and uses the old method, or else prints a HUGE WARNING to the screen when you go to upgrade something that can cause you to lose access to all your data. I have been extremely frustrated with this whole situation, so much so that once I get this volume decrypted I am **never** using linux loopback encryption again, I am going to either use some third-party application level encryption, or roll my own, or purchase a commercial application. I can't afford to waste 8+ hours of my day over this again.
I'm sorry that this problem has caused you trouble. Please remember that the loop encryption is *not* part of the kernel, and neither is there any evidence saying that the old encryption methods have been dropped (I even had a quick look at the source myself). I will help troubleshoot the problem if you can provide me with the information I have requested in comment #8, comment #14 and comment #15. It would also be useful if you could clarify the rest of the situation since you didn't include many details. Even if you are repeating what Robert has said already, please provide a detailed report.
Well, at least I am not the only person to have been hit by this, not that I would wish it on anyone, but at least its existence has been independently verified by someone else. Yes, booting off that 2004 live CD will work. You will then have to copy the file to some other volume, and either leave it as plain text, or encrypt in with the new algorith, or use some other encryption method. I am using loopback aes256 encryption for my network backup server. It keeps the backups on a 3-way RAID-1 mirror, and archives to encrypted compressed dvds. I can live with converting the mirror to a new encryption method, although it will be a pain, but there is *NO WAY* I am going to copy and re-encrypt hundreds of archival dvds! Your filesystem size of 6 GB is trivial compared to what I am dealing with. Can you say several hundred dvds with about 8 GB of compressed encrypted data on each one? That comes to around 1.6 TB! I have to use either cryptoloop, or the loopback encryption, or dm.crypt, as I need a fully functional reiserfs as an encrypted filesystem on the raid. I guess I could switch to some other method for the archival dvds, but I really do not want to have to do that. All we need is a backward compatibility option for losetup to use the old way.
Ok - to expand on my previous rant a bit, let me post the actual problem. I have an AES encrypted volume I made earlier this year, probably around May or so. I made, and have always mounted, said volume like this: losetup -e aes /dev/loop0 ~/secure.crypt <Enter a 16 char password> mount -t reiserfs -o loop ~/secure.crypt ~/secure Now, starting sometime this month, after an emerge sync, I am unable to mount the data. First, it no longer accepts my 16 char password, saying it has to be 20 chars. So, I rebuild util-linux with a lower limit (-DLOOP_PASSWORD_MIN_LENGTH=8), and losetup now accepts my password, but the filesystem is not recognized when I try to mount. I have tried every -H <phash> method available in losetup, none of them work. Now, to be even more confusing, I cannot figure out what the difference is between 'emerge loop-aes' and enabling loopback encryption in the kernel itself. I do not know which I had enabled when I created this volume. How can I tell? I am really desperate for help on this issue.
Created attachment 74657 [details] Mount.strace as requested Password replaced with XXXXXXXXXXXXXXXX
Thanks, Jason. My backup server is currently busy and cannot be rebooted for a few more days. (Mashing around with HUGE amounts of data takes time...) I was going to provide such an strace whenI could do a reboot. Hopefully, your strace will suffice for the investigation. :-)
Alas - I am unable to even access the data booting off of the 2004 live CD. I am convinced I must have had some wierd combination of utlin-linux and CryptoAPI going on. I have also tried copying the encrypted volumne to a debian sid machine, and could not decrypt it there either, using any of the supplied phash algos.
If you cannot read it with that old live cd, then I fear you have a different problem that I have. Perhaps I should go ahead and make the strace when I can reboot the backup server -- probably not before next Monday at this rate.
I also need the other info I asked about, see comment #8 and comment #15
I will try to get all that info to yu when I can reboot the server to the newer kernel. Right now, it is performing its assigned duties with an older kernel, as the newer one has this mount problem...
There is also an "old-crypt" flag for util-linux which may be worth trying, especially in Jason's case. You'll then get "mount-old-crypt" and "losetup-old-crypt" which can be used instead of "mount" and "losetup" respectively.
Please reopen when requested info arrives.