Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Sat, Aug 23, 2003 at 08:55:28PM +0200, Thierry Godefroy wrote: I got no compatibility problem with the crypto API but for when they changed from 2.2 to 2.4 kernel (the data had to be transfered to a new encrypted volume, but that's all). it will change again for 2.6, probably a few times yet. Also, the crypto API is to become the standard, so I'd recommend starting to get used to it right now instead of using a third party software which seems pretty much incompatible with the crypto API (as far as I could see by reading the loop-AES documentation). the standard is just emerging, it had 2 versions with incompatible disk formats last 2 weeks and mount options are still subject of discussion.. not a good time to get used to it. So far it seems loop-AES can encrypt or decrypt all formats except perhaps some of those with broken IV keys. that looks very strange. Perhaps I can make some sense out of it when I see the patch. Alas, there's some weirdness in the rc.sysinit script of ShoeString: it looks like a line in fstab such as: /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0 no idea. What would mount -a do if that line is in /etc/fstab? Mine simply complains no such fs and that's it but I have newer version of the script. I don't see anything in the script itself. # Source functions . /etc/init.d/functions action $Super-Mounting the CD-ROM: mount /mnt/cdrom /mnt/cdrom -t supermount -o fs=iso9660,dev=/dev/cdrom,ro action $Super-Mounting the floppy: mount /mnt/floppy /mnt/floppy -t supermount -o fs=vfat,dev=/dev/fd0 this is a good idea, much easier to provide as fully configured but optional addon. Richard
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Thu, 21 Aug 2003 09:58:01 +0200, Richard Zidlicky wrote: On Wed, Aug 20, 2003 at 04:24:20PM +0200, Thierry Godefroy wrote: Hi, I'm using the full crypto-API (with all the ciphers; AES being a rather weaker one than Serpent, for example...). Serpent is distributed in the ciphers package of loop-AES. It is an extra download but no hassle compile. Btw some recent cryptoanalysis suggests AES is actually less susceptible to a certain type of attack then Serpent so it is far from easy which one is weaker. Still no immediate threat. Actually, this is not quite exact. It is true that more cryptoanalyis was done on Serpent (which algorythm is easier to analyse). But so far more rounds have been broken in AES (Rinjdael) than in Serpent (unless I missed one of the lastest articles about thos algorythms, which is possible). The reason why Rinjdael was choosen as the AES instead of Serpent is unclear and even highly suspicious to me... It is admitedly a little faster than Serpent, but was pointed out as less secure than Serpent too (and as it was not as much crypto-analyzed as Serpent, one may find a shortcut attack on day or another...). My thought is that the NSA is probably quite interested in having an AES algorythm which is not too difficult to break... I personally use Serpent with 256 bits keys for the encrypted partitions on my PCs. It's of course probably too slow for the Q60 though (128 bits keys seem more reasonable for a poor 68060 @ 66MHz to deal with...). What is the advantage of SuperMount over autofs? It's 100% automatic, doesn't need for any demon, and it doesn't hog the processor/drives by checking every few seconds that a new medium was inserted... As soon as an access is requested to a supermounted medium, then a check for changed/absent medium is made transparently for the user. It's the standard 'automounter' for Mandrake and I just love it. :-) appart of the extra demon this sound really very much like what autofs does for me. How does it work to release a medium, eg CD or floppy? With autofs I have to wait until it timeouts. No wait with SuperMount. It's just like if you were using the medium under DOS/Windoze (Yuck !), or SMSQ/E... It's 100% kernel based and done at the driver level... The problem is that its author doesn't maintain it anymore and all the maintnance is now done by the Mandrake developers, and scattered in numerous patches to each kernel... There are times were you just can't find a proper (set of) patch(es) applying cleanly to a given kernel... Well, I could make one out of Mandrake's patches for Linux-vanilla v2.4.21 and I use it since v2.4.21 is out without a single problem. I'll put the patch on my q60linux website. ;-) How do you configure it? It's like a filesystem driver. You configure it in fstab, example: /mnt/dos/a /mnt/dos/a supermount fs=vfat,dev=/dev/fd0 0 0 /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0 More option can be passed to the underlying driver. A doc short is supplied in the patch and appears in the patched Linux sources tree as: Documentation/filesystems/supermount.txt Hmm... Strange... Mandrake's patched version of gcc v3.2.2 doesn't got this problem on i586 Linux... Perhaps would it be worth rebuilding the Mandrake gcc package for Linux-Q60 ? probably not, the problem is m68k specific afaics and Mandrake gets much less non-x86 testing than RedHat or Debian does. Mandrake doesn't develope at all for the m68k architecture, alas... I looked deeper into it, it is the assignment to error.all which barfs the compiler. Translated to RTL this assignment is apparently too complicated for the register life analysis to grok and it won't set a REG_DEAD note to error.all where it should.. somewhere the strict_low_part is in the way. As a workaround try to declare char xerr assign to xerr and return xerr. I patched the sources and I'm trying to compile them as I write this message... Do you know if the same problem would arise with older gcc version (I was thinking to compile it with gcc-2.95.3...) ? If you got a file server (ftp, sftp, web) where to get them, I'd prefer that way (faster now that I got an ADSL link ;-)... well I didn't get ADSL, the sourceforge site is still available of course. There are no SRPMS in it though... Or do I look in the wrong place ? Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Wed, 20 Aug 2003 10:55:50 +0200, Richard Zidlicky wrote: On Wed, Aug 20, 2003 at 01:22:19AM +0200, Thierry Godefroy wrote: Hi ! In an attempt to bring more pre-compiled packages for the ShoeString distribution, I tried to compile the latest Linux kernel (with the crypto API patch and the SuperMount patch). I was using loop-AES with additional ciphers which worked reliably for the last few months. I'm using the full crypto-API (with all the ciphers; AES being a rather weaker one than Serpent, for example...). What is the advantage of SuperMount over autofs? It's 100% automatic, doesn't need for any demon, and it doesn't hog the processor/drives by checking every few seconds that a new medium was inserted... As soon as an access is requested to a supermounted medium, then a check for changed/absent medium is made transparently for the user. It's the standard 'automounter' for Mandrake and I just love it. :-) Alas, the compiler stops with an internat error; I tried twice, to check it was not due to a corrupted memory or processor overheating error (unlikely as my 060 is quite cool, equiped as it is with a heatsink+fan). I assume it's a gcc bug... Did anyone else encountered it ? Did anyone compiled a newer gcc version (Richard, perhaps ? :-) it is a compiler bug, the new ide core included since 2.4.21-rc6 triggers it and I didn't succeed to fix it in gcc-3.2. Hmm... Strange... Mandrake's patched version of gcc v3.2.2 doesn't got this problem on i586 Linux... Perhaps would it be worth rebuilding the Mandrake gcc package for Linux-Q60 ? I am currently testing gcc-3.3.1. The gcc in ShoeString is not very good anyway. I have compiled gcc-3.2 and glibc-2.2.x (as well as 2/3 of RH 8.0) which appeared to work remarkably well (with patches) but something got terribly screwed up just before I could made a release - the compiler no longer bootstrapped :( Eeeps... ;-( I can mail you a CD with many new packages If you got a file server (ftp, sftp, web) where to get them, I'd prefer that way (faster now that I got an ADSL link ;-)... which would be useful for development purposes only, I can't spend any time to create update or installation routines when a few essential packages are broken (gnome-2.x) or have strange quirks (rpm-4.x) Gnome2 is a real nightmare and it sucks big time !!! Man, was I pissed off when I installed Mandrake v9.1 to update my good ol' Mdk 7.2 on my PCs... This stupid new Gnome is not only utterly broken, but it's a Hell to configure (they made the configuration 'simpler' by removing most of the options: the net result is that you can't get it to work your own way. If the default behaviour is fine with you then it's alright, else, you can spend hours trying to figure out what to do to obtain what you want !). Plus it eats 24Mb more memory than Cnome 1.2 on my PCs and is utterly sloww: it's definitely a no-no for a Q60, forget it altogether and stick with Gnome v1.4... or better, use a lighter, standalone WM, like Icewm (v1.0.9 available on my website), Blackbox or the like... I never had problems with rpm 4.0 on Mandrake, but they pretty much changed everything compared to rpm v3... Even the databases are incompatible... Who said upward compatibility ? It looks like this concept was lost and forgotten a couple of years ago already... :-( Thierry ([EMAIL PROTECTED]).
