I understand intuitively the argument (although not having the sufficient knowledge do have a sound picture) but what surprised me is that I did (by error) mount the usb-key without the "noauto" function and ...... it worked like charm. So either they changed something or the issue appears only to be essential when you begin to encrypt the root partition.
I did write to the author of the how-to and hope he will find the time to reply (have doubts about it, since they are working on 11.2) but still I would have liked to know before doing the final steps. I will use the time to read the menu.lst links you provided (still thanks for that).
A quick google well that is what you did 
noauto is don't mount at startup. Using yast would of automagically added it, you would need to check but I'm pretty certain here.
Mmm I shouldn't reply before having my coffee don't know then.
Sure, when you uncheck the "Don't mount automatically at boot" then it takes off the noauto parameter out of /etc/fstab........and vice versa.
But if everything worked, why did he give then the statement. I would have understood that if I did mount automatically by error the /dev/sdb1 then.....according to what he said it should not work due to the issue of order.......
BTW. I am by no means expert with the boot process, but the parameters of /etc/fstab I did study them beforehand.........so not just "playing russe roulette". 
The handling of boot.local.fs is however a very individual thing for every distribution, if I well understood. I tried also in Mandriva to encrypt. The issue is uttermost important to me and so I would have changed distribution. But apparently the diskdrake cannot handle encrypted swap partition (sic) which makes it for me pointless. So I am forcing on this howto to get it done, however the how-to of Suse are often quite outdated.....(10.3 was quite different to 11.1 in its behaviour). And up to now I did not find a lot of feedback from users. Apparently nobody tried to do the install on external usb.....
Not quite true my distro doing a find /etc -name *boot* will only return something in my vmware.. The boot process is wildly varied. Surely without using the /boot on a pen if you can encrypt all of them minus /boot then if you can create an unenecypted using a flash pen as boot it is a question of converting the 2 together.
Personally it shouldn't be any more difficult I would try it for you but I just don't have a flash pen handy.
Though to be honest I can only see very few examples where it is needed to encrypt everything and the kitchen sink. For me if I wished for encryption I would do it on a folder(ecryptfs) basis, and think all this root, swap stuff is like using a shotgun to kill a fly, ymmv.
I am traveling a lot with the notebook not always 100 percent attended. I had cases before where this caused me substantial damage. So I am ....somehow forced to get it working. There are people living still with the door open at night and the keys in the panel of the car.......I am living, if you want to have the comparison holding, in a slum suburb of Asia with Ali-Baba and the 30 burglars waiting for the sunset.....
So I will try to get it fixed.
Swap: if the system hibernates the content is available unencrypted.
Root: you just take a life cd and you get to read everything if it is only an encrypted home partition.
Usb is extreme, but then you live according to the nice people surrounding you........
Thats not true you can't just get root and read it try it. They've still got to crack the encryption or password on home. Look into ecryptfs the data maybe there but it is unreadable. So they maybe able to "attempt" a password cracker but at 1 attempt every second it is going to take many years.
Only reason for doing root is to stop a kernel hack/rooting(i.e install things to get your passphrase) if they got this far then tbh if went beyond common theft and into things like industrial espionage, or government intervention and I don't mean to be rude you wouldn't be leaving the data at home/unattended.
Encryption won't stop theft worse case scenario it is reformat hdd or replace.
Edit
If this was me I would do swap and use a directory or just do home but as said earlier ymmv.
Edit2
http://www.auscert.org.au/render.html?it=2260 look at the table here for the amount of time and variations just for a 8 character combination.
Ok, I got everything working, the system suspended correctly and then........I got no possibility to get it back on. It goes to stage 1.5 and then it blocks with Grub error 25.
So what is this now? It starts normally, it suspends normally to disk, but it cannot start?
THIS is even more particular. So, I cannot come back from resume. But if I put in the installation DVD and choose boot installed system, grub starts as it should. Suggestions? I am speechless. 
But I am not far away from succeeding, I am sure.
I am afraid that I am a noob at suspending (I never do this, but I have desktops only, no laptops).
But I can give a suggestion: suspend to disk means writing to swap. This means encryption. Does the resume (GRUB) know anything about this encryption?
yes this is the curious thing. I believe this is the symptom of the error I made in the very beginning when not mounting sdb1 by hand but forgott about the noauto. He messes up at stage 1.5 when the file systems are mounted. Now, if it is true that if it is auto then he tries to mount it after the /etc/fstab entries, then this means I am screwed.
I will do another install (anyway it is too late to make it before my next travel but at least if I am not doing the shreds of the disks it is fast and I can see whether this is the error or not.)
Sure it is nuts, but it has become a "personal question".
BTW. Now it does not resume not even if I do it from the DVD......maybe also a BIOS problem.
But for one more time I will try for sure.
I must object here. Maybe I interprete wrongly what you stipulate. There is a huge difference between GRUB (stage whateever, but including 1.5) and the system using /etc/fstab at boot.
GRUB does NOT use /etc/fstab. It only knows about the (hd0,0), etc. partitions it finds in its configuration (menu.lst). It uses them to find the kernel (and some other things), but does not 'mount' them.
When the system boots, somewhere early in the process (the kernel is loaded then and init is started, which results in /etc/inittab being interpreted) etc/fstab is used. The filesystems mentioned there are fsck-ed when needed and mounted (/root was already mounted read-only, but is now remounted read-write).
Do Not Mount at System Start-up”. This is necessary because the USB devices are created after the boot.localfs script tries to mount the entries listed in fstab.
This is the point I was refering to and that I think could be the error (if ever). Maybe the scripts are done in a way that the use of external usb-keys simply has to fail... I should look at boot.localfs
no, seems to happen at a later stage I guess. Something blocks when resuming in stage 1.5 or at beginning of stage 2
This Topic Is Locked To Guest Posts
It's been a while since this topic was active, if you'd like to get it going again, please post as a registered member
