kernels was: Re: MOL compiling (cont)
mol-general@lists.maconlinux.org
mol-general@lists.maconlinux.org
Sun, 8 Sep 2002 14:35:28 -0400
> Message: 2
> Date: Thu, 05 Sep 2002 15:20:05 +1000
> Subject: Re: MOL Compiling (cont)
> From: Dan Brunet <danb@iprimus.com.au>
> To: <mol-general@lists.maconlinux.org>
> Reply-To: mol-general@lists.maconlinux.org
>
> on 5/9/02 5:55 AM, Arch & Cath at archandcath23@comcast.net wrote:
>
> > Finally got everything compiled and made and copied vmlinux and System.map
> > into /boot and vmlinux into linux Kernels folder in the Mac System folder.
> > Selected my new system in the BootX control panel. System starts to boot,
> > however, stops and asks me to sign in root because of file problems. When I
> > try the usual "fsck /dev/sdc" I get "Superblock could not be read or does
> > not describe a correct ext2 file system". When I go back to the old kernel
> > everything works.
> >
>
> That sounds a little troublesome.. What format is your root filesystem? Did
> you compile Second Extended AND ext3 filesystem support into the kernel?
>
> > I am still a bit confused about how the kernel works in a Mac. If it boots
> > from the kernel in the Mac System folder, why do we need the one in /boot?
>
> There's no need to install any kernels into /boot when using BootX.. However
> If you plan to use the Quik bootloader you will need to have a kernel in
> /boot.
>
> > All of the PPC kernel rebuild procedures I got off the web (Newbie & Linux
> > PPC Kernel) say to start in /usr/src/linux which is what I have done.
> > Belatedly I read the 2.4.xx READ ME and it says "Do NOT use the
> > /usr/src/linux area!" Have I farkeled the library header files in
> > /usr/src/linux?
>
> /usr/src/linux should be a symbolic link to the directory which your current
> source is located (/usr/src/linux-2.4.xx).. ls /usr/src/linux -l to view the
> symlink's target.
>
well i dunno which *nix u'r running but the option (the -l in this case) should come b4
the file; i.e. ls -l <foo>. on my system (POSIX C) i'd get an error from
ls <foo> -l .
> It's always a good idea to keep the symlink /usr/src/linux up to date with
> the current kernel source you're using as many programs rely on the headers
> in the kernel source for compilation.
>
> To create the symlink, use the command; ln -sf /usr/src/linux-2.4.xx
> /usr/src/linux
>
i'd add the -i option JIC; i prefer having it run interactive.
> > It appears to me that I now have kernel files in /usr/src/linux, /root and
> > the Mac System folder! Which one is actually being used? Should i start a
> > build over in some other file system? How do I restore the library headers?
>
> The only kernel being used is the one in your System Folder. When you boot
> from BootX the kernel file is copied into memory and then the file is left
> untouched.. I am not aware of any way to find the file name or location of
> the current kernel in use.
>
in BootX (the original one, not the one modified and compiled into MOL;
saw the code ;-) you can select the kernel thru the pop-up on the panel;
in quik it's in /etc/quik.conf; but to see which kernel is being used go
dmesg | more, or check the log file (here it's /var/log/messages).
near the top u can see the kernel version and so on. on what machine it
was compiled on should give you a clue on which kernel is loaded into
RAM. i hope this helps.
simon
> Good luck.
>
> Regards,
> Dan
>
>
> --__--__--
>
> Message: 3
> Date: Wed, 04 Sep 2002 23:17:08 +0200
> From: Lucien Knoepfli <lucienk@student.ethz.ch>
> To: mol-general@lists.maconlinux.org
> Subject: Re: MOL Compiling (cont)
> Reply-To: mol-general@lists.maconlinux.org
>
> Arch & Cath wrote:
>
> >Finally got everything compiled and made and copied vmlinux and System.map
> >into /boot and vmlinux into linux Kernels folder in the Mac System folder.
> >Selected my new system in the BootX control panel. System starts to boot,
> >however, stops and asks me to sign in root because of file problems. When I
> >try the usual "fsck /dev/sdc" I get "Superblock could not be read or does
> >not describe a correct ext2 file system". When I go back to the old kernel
> >everything works.
> >
> >I am still a bit confused about how the kernel works in a Mac. If it boots
> >from the kernel in the Mac System folder, why do we need the one in /boot?
> >
> >All of the PPC kernel rebuild procedures I got off the web (Newbie & Linux
> >PPC Kernel) say to start in /usr/src/linux which is what I have done.
> >Belatedly I read the 2.4.xx READ ME and it says "Do NOT use the
> >/usr/src/linux area!" Have I farkeled the library header files in
> >/usr/src/linux?
> >
> This is how I do it:
> I have a directory named after the kernel version
> ("/usr/src/linux-2.4.19") and a link to this dir. ("/usr/src/linux ->
> /usr/src/linux-2.4.19").
> So if any make or config script is looking for the kernel sources,
> there's always the link to the ones from the used kernel (if you update
> the link, after making a new kernel!).
> Another tip from the author of cdrecord is, to rename the directories
> scsi, linux, asm in /usr/include/ (ex: /usr/include/asm.old) and make
> links to /usr/src/linux/include/asm/ (is normaly a link, generated by
> teh first make config or make xconfig etc.),
> /usr/src/linux/include/scsi/ and /usr/src/linux/include/linux/. I never
> had problems doing so, but I don't know if this is really save, the idea
> is that all scripts (make ...) will link against your used kernel.
>
> hth luc
>
> >
> >It appears to me that I now have kernel files in /usr/src/linux, /root and
> >the Mac System folder! Which one is actually being used? Should i start a
> >build over in some other file system? How do I restore the library headers?
> >
> You boot with the kernel in the mac system folder (by the way: only if
> you are using bootx on an oldworld mac, otherwise you don't need a
> kernel in you system folder).
>
> >
> >HELP!
> >
> >Arch
> >
> >_______________________________________________
> >mol-general mailing list
> >mol-general@lists.maconlinux.org
> >http://lists.maconlinux.org/mailman/listinfo/mol-general
> >
> >
> >
>
>
>
>
> --__--__--
>
> Message: 4
> Date: Thu, 5 Sep 2002 06:55:33 -0400 (EDT)
> From: Stew Benedict <sbenedict@mandrakesoft.com>
> To: mol-general@lists.maconlinux.org
> Subject: Re: MOL Compiling (cont)
> Reply-To: mol-general@lists.maconlinux.org
>
>
> On Thu, 5 Sep 2002, Dan Brunet wrote:
>
> > on 5/9/02 5:55 AM, Arch & Cath at archandcath23@comcast.net wrote:
> >
> > > Finally got everything compiled and made and copied vmlinux and System.map
> > > into /boot and vmlinux into linux Kernels folder in the Mac System folder.
> > > Selected my new system in the BootX control panel. System starts to boot,
> > > however, stops and asks me to sign in root because of file problems. When I
> > > try the usual "fsck /dev/sdc" I get "Superblock could not be read or does
> > > not describe a correct ext2 file system". When I go back to the old kernel
> > > everything works.
> > >
> >
> > That sounds a little troublesome.. What format is your root filesystem? Did
> > you compile Second Extended AND ext3 filesystem support into the kernel?
> >
> > > I am still a bit confused about how the kernel works in a Mac. If it boots
> > > from the kernel in the Mac System folder, why do we need the one in /boot?
> >
> > There's no need to install any kernels into /boot when using BootX.. However
> > If you plan to use the Quik bootloader you will need to have a kernel in
> > /boot.
> >
> > > All of the PPC kernel rebuild procedures I got off the web (Newbie & Linux
> > > PPC Kernel) say to start in /usr/src/linux which is what I have done.
> > > Belatedly I read the 2.4.xx READ ME and it says "Do NOT use the
> > > /usr/src/linux area!" Have I farkeled the library header files in
> > > /usr/src/linux?
> >
> > /usr/src/linux should be a symbolic link to the directory which your current
> > source is located (/usr/src/linux-2.4.xx).. ls /usr/src/linux -l to view the
> > symlink's target.
> >
> > It's always a good idea to keep the symlink /usr/src/linux up to date with
> > the current kernel source you're using as many programs rely on the headers
> > in the kernel source for compilation.
> >
> > To create the symlink, use the command; ln -sf /usr/src/linux-2.4.xx
> > /usr/src/linux
> >
>
> Thsi advice does not always apply these days. Many distributions now ship
> kernel-headers that were used to build glibc as a seperate package, and
> the kernel-source symlinks no longer exist. In most cases it is better to
> build user-space programs using the same kernel headers that were used for
> your running glibc.
>
> Stew Benedict
>
> --
> MandrakeSoft
> PPC FAQ: http://www.linux-mandrake.com/en/ppcFAQ.php3
> IRC: irc.openproject.net #cooker-ppc
>
>
> --__--__--
>
> Message: 5
> From: samuel@ibrium.se
> Date: Thu, 5 Sep 2002 13:44:26 +0200
> To: mol-general@lists.maconlinux.org
> Cc: sbenedict@mandrakesoft.com
> Subject: Re: MOL Compiling (cont)
> Reply-To: mol-general@lists.maconlinux.org
>
> On Thu, Sep 05, 2002 at 06:55:33AM -0400, Stew Benedict wrote:
> > > It's always a good idea to keep the symlink /usr/src/linux up to date with
> > > the current kernel source you're using as many programs rely on the headers
> > > in the kernel source for compilation.
> > >
> > > To create the symlink, use the command; ln -sf /usr/src/linux-2.4.xx
> > > /usr/src/linux
> >
> > Thsi advice does not always apply these days. Many distributions now ship
> > kernel-headers that were used to build glibc as a seperate package, and
> > the kernel-source symlinks no longer exist. In most cases it is better to
> > build user-space programs using the same kernel headers that were used for
> > your running glibc.
> >
> > Stew Benedict
>
> True. I think there is consensus that the system should be set
> up as follows:
>
> 1. The directories
>
> /usr/include/linux
> /usr/include/asm
>
> should be the kernel headers used to build glibc. In other words,
> these should typically _not_ be symlinks to /usr/src/linux/include/*.
>
> 2. /usr/src/linux _may_ be a symbolic link to the currently running
> kernel. Many external kernel modules still assumes that this is the
> case. Avoiding this practice is however a good idea in my opinion.
>
> 3. /lib/modules/2.4.x/build should be a symbolic link to the 2.4.x
> source used in building the 2.4.x modules. When a custom kernel
> is build, this symlink will be installed during the 'make modules_install'
> step. Thus, this step should be perform even if everything essential
> is compiled directly into the kernel.
>
> MOL looks for the kernel headers using /lib/modules/2.4.x/build.
> If this symlink does not exist or is broken, it tries to use
> /usr/src/linux. Usage of /lib/modules/2.4.x/build is much prefered
> to /usr/src/linux. In particular, the risk of a version mismatch between
> the kernel and the kernel headers is substantially reduced.
>
> (MOL uses /lib/modules/2.4.x/build since 0.9.45 or 0.9.55).
>
> Cheers,
>
> /Samuel
>
>
> --__--__--
>
> Message: 6
> To: mol-general@lists.maconlinux.org
> Subject: Running MOL on IBM PReP machines (43p-140)?
> From: "Mati Ustav" <mati.ustav@ee.ibm.com>
> Date: Thu, 5 Sep 2002 17:28:23 +0200
> Reply-To: mol-general@lists.maconlinux.org
>
> This is an S/MIME signed message.
>
> ---------z23686_boundary_sign
> Content-Type: multipart/alternative; boundary="=_alternative 0054F70BC2256C2B_="
>
> This is a multipart message in MIME format.
> --=_alternative 0054F70BC2256C2B_=
> Content-Type: text/plain; charset="US-ASCII"
>
> Hello all,
>
> Has anyone tried running MOL on IBM PReP hardware?
> FAQ at www.maconlinux.org claims that "... MOL runs on any PowerPC
> hardware..." ;)
>
> However, i've had no luck getting it to run on my IBM 43p-140.
> It has:
> PPC604e @ 200Mhz
> Matrox G200 4MB video
> integrated ncr53c825a SCSI with a 2GB HD
> 160MB RAM
> 2 x AMD PCnet network cards
>
> The machine runs fine with PPC linux (using 2.4.20-pre5,
> BitKeeper/linuxppc_2_4_devel tree).
> MOL (bk, version 0.9.66 as of today) compiles fine, mol module loads
> fine...
> Running "startmol --test" gives me:
>
> kass:~ # startmol --test
> Mac-on-Linux 0.9.66 Copyright (C) 1997-2002 Samuel Rydh
> Config dir: /etc/mol
> Data dir: /usr/local/share/mol/0.9.66
> Loading Mac-on-Linux kernel module:
> /usr/local/lib/mol/0.9.66/modules/2.4.20-pre5-noav/mol.o
> Session 0. Lockfile: /var/lock/mol-0
> Debugger nub disabled
> The session save/restore feature is disabled
> Oops: kernel access of bad area, sig: 11
> NIP: CC03C0CC XER: 00000000 LR: CC03C0AC SP: C8E4BE80 REGS: c8e4bdd0 TRAP:
> 0300
> Not tainted
> MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> DAR: 00000008, DSISR: 40000000
> TASK = c8e4a000[512] 'mol' Last syscall: 201
> last math 00000000 last altivec 00000000
> GPR00: 00000000 C8E4BE80 C8E4A000 00000000 00000000 0000003C C8E4BED8
> 10063A20
> GPR08: 00000000 C8E4BE88 CC03C5C8 00000000 20000088 10064944 00000000
> 00000000
> GPR16: 00000000 00000000 00000000 00000000 00009032 08E4BF40 00000000
> C0005CD4
> GPR24: C0005A40 C8E4BED8 10060000 00000000 00000000 C8E4BED8 00000000
> 00000000
> Call backtrace:
> CC03C0AC CC03C30C CC03C5E8 C0005A9C 0FE5D944 1000706C 10002C4C
> 0FDFC680 00000000
>
>
> Any ideas?
>
> TIA,
>
> Mati
> --=_alternative 0054F70BC2256C2B_=
> Content-Type: text/html; charset="US-ASCII"
>
>
> <br><font size=2 face="sans-serif">Hello all,</font>
> <br>
> <br><font size=2 face="sans-serif">Has anyone tried running MOL on IBM
> PReP hardware?</font>
> <br><font size=2 face="sans-serif">FAQ at www.maconlinux.org claims that
> "... MOL runs on any PowerPC hardware..." ;)</font>
> <br>
> <br><font size=2 face="sans-serif">However, i've had no luck getting it
> to run on my IBM 43p-140.</font>
> <br><font size=2 face="sans-serif">It has:</font>
> <br><font size=2 face="sans-serif">PPC604e @ 200Mhz</font>
> <br><font size=2 face="sans-serif">Matrox G200 4MB video</font>
> <br><font size=2 face="sans-serif">integrated ncr53c825a SCSI with a 2GB
> HD</font>
> <br><font size=2 face="sans-serif">160MB RAM</font>
> <br><font size=2 face="sans-serif">2 x AMD PCnet network cards</font>
> <br>
> <br><font size=2 face="sans-serif">The machine runs fine with PPC linux
> (using 2.4.20-pre5, BitKeeper/linuxppc_2_4_devel tree).</font>
> <br><font size=2 face="sans-serif">MOL (bk, version 0.9.66 as of today)
> compiles fine, mol module loads fine...</font>
> <br><font size=2 face="sans-serif">Running "startmol --test"
> gives me:</font>
> <br>
> <br><font size=2 face="sans-serif">kass:~ # startmol --test</font>
> <br><font size=2 face="sans-serif">Mac-on-Linux 0.9.66 Copyright (C) 1997-2002
> Samuel Rydh</font>
> <br><font size=2 face="sans-serif">Config dir: /etc/mol</font>
> <br><font size=2 face="sans-serif">Data dir: /usr/local/share/mol/0.9.66</font>
> <br><font size=2 face="sans-serif">Loading Mac-on-Linux kernel module:</font>
> <br><font size=2 face="sans-serif"> /usr/local/lib/mol/0.9.66/modules/2.4.20-pre5-noav/mol.o</font>
> <br><font size=2 face="sans-serif">Session 0. Lockfile: /var/lock/mol-0</font>
> <br><font size=2 face="sans-serif">Debugger nub disabled</font>
> <br><font size=2 face="sans-serif">The session save/restore feature is
> disabled</font>
> <br><font size=2 face="sans-serif">Oops: kernel access of bad area, sig:
> 11</font>
> <br><font size=2 face="sans-serif">NIP: CC03C0CC XER: 00000000 LR: CC03C0AC
> SP: C8E4BE80 REGS: c8e4bdd0 TRAP: 0300</font>
> <br><font size=2 face="sans-serif"> Not tainted</font>
> <br><font size=2 face="sans-serif">MSR: 00009032 EE: 1 PR: 0 FP: 0 ME:
> 1 IR/DR: 11</font>
> <br><font size=2 face="sans-serif">DAR: 00000008, DSISR: 40000000</font>
> <br><font size=2 face="sans-serif">TASK = c8e4a000[512] 'mol' Last syscall:
> 201</font>
> <br><font size=2 face="sans-serif">last math 00000000 last altivec 00000000</font>
> <br><font size=2 face="sans-serif">GPR00: 00000000 C8E4BE80 C8E4A000 00000000
> 00000000 0000003C C8E4BED8 10063A20</font>
> <br><font size=2 face="sans-serif">GPR08: 00000000 C8E4BE88 CC03C5C8 00000000
> 20000088 10064944 00000000 00000000</font>
> <br><font size=2 face="sans-serif">GPR16: 00000000 00000000 00000000 00000000
> 00009032 08E4BF40 00000000 C0005CD4</font>
> <br><font size=2 face="sans-serif">GPR24: C0005A40 C8E4BED8 10060000 00000000
> 00000000 C8E4BED8 00000000 00000000</font>
> <br><font size=2 face="sans-serif">Call backtrace:</font>
> <br><font size=2 face="sans-serif">CC03C0AC CC03C30C CC03C5E8 C0005A9C
> 0FE5D944 1000706C 10002C4C</font>
> <br><font size=2 face="sans-serif">0FDFC680 00000000</font>
> <br>
> <br>
> <br><font size=2 face="sans-serif">Any ideas?</font>
> <br><font size=2 face="sans-serif"><br>
> TIA,<br>
> <br>
> Mati</font>
> --=_alternative 0054F70BC2256C2B_=--
>
> ---------z23686_boundary_sign
> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="smime.p7s"
> Content-Description: S/MIME Cryptographic Signature
>
> MIAGCSqGSIb3DQEHAqCAMIIUAAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISPjCCAsYw
> ggIvoAMCAQICEBMjUVlih6h6pQ7i2OzJ8/MwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpB
> MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh
> d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x
> JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
> c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDExMDEwMDAwMDBaFw0wMzA2MDkyMzU5NTla
> MEwxCzAJBgNVBAYTAlVTMRswGQYDVQQKExJFcXVpZmF4IFNlY3VyZSBJbmMxIDAeBgNVBAMTF0Vx
> dWlmYXggU2VjdXJlIEVtYWlsIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCeZ/4bODoB
> R+BTlesm8Dd2kqhtIbeGxvBuclR+bDX02mNwpoPV3HeLmFT+q8mllJ5R3x6IJgHZWUwz7stb4+zD
> NAjwd5jf3LEskadCZ+O6REJhpz7PRobxYhfdr9puYVpbBqOLUnmGwOt36fgPdXu1iq3jeu8C+F3+
> e6ka7hle0wIDAQABoyMwITASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG
> 9w0BAQQFAAOBgQBlqVclsMirnoq1hzPZqBbIkUqfyvNcOdo7aXv1fYZfx1e4u37OSPbfXpfHbFM7
> 0ODTHmtqHrS7Z2KVPtjRH/vW0YaRcNOgcjghlJFKyNryHTD3FMwvzefhjQ2zfEdz6OFWZARDY1uE
> V5SW6zZJwdgbvtLhltkDEJkA26tHcktEdDCCAsYwggIvoAMCAQICEBMjUVlih6h6pQ7i2OzJ8/Mw
> DQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
> BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl
> cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG
> cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe
> Fw0wMDExMDEwMDAwMDBaFw0wMzA2MDkyMzU5NTlaMEwxCzAJBgNVBAYTAlVTMRswGQYDVQQKExJF
> cXVpZmF4IFNlY3VyZSBJbmMxIDAeBgNVBAMTF0VxdWlmYXggU2VjdXJlIEVtYWlsIENBMIGfMA0G
> CSqGSIb3DQEBAQUAA4GNADCBiQKBgQCeZ/4bODoBR+BTlesm8Dd2kqhtIbeGxvBuclR+bDX02mNw
> poPV3HeLmFT+q8mllJ5R3x6IJgHZWUwz7stb4+zDNAjwd5jf3LEskadCZ+O6REJhpz7PRobxYhfd
> r9puYVpbBqOLUnmGwOt36fgPdXu1iq3jeu8C+F3+e6ka7hle0wIDAQABoyMwITASBgNVHRMBAf8E
> CDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQBlqVclsMirnoq1hzPZqBbI
> kUqfyvNcOdo7aXv1fYZfx1e4u37OSPbfXpfHbFM70ODTHmtqHrS7Z2KVPtjRH/vW0YaRcNOgcjgh
> lJFKyNryHTD3FMwvzefhjQ2zfEdz6OFWZARDY1uEV5SW6zZJwdgbvtLhltkDEJkA26tHcktEdDCC
> AyAwggKJoAMCAQICAhPgMA0GCSqGSIb3DQEBBAUAMEwxCzAJBgNVBAYTAlVTMRswGQYDVQQKExJF
> cXVpZmF4IFNlY3VyZSBJbmMxIDAeBgNVBAMTF0VxdWlmYXggU2VjdXJlIEVtYWlsIENBMB4XDTAx
> MTIyMTE2MTUzOVoXDTAzMDEwNDE2MTUzOVowgYQxCzAJBgNVBAYTAlVTMQwwCgYDVQQKEwNJQk0x
> ETAPBgNVBAsTCEVNUExPWUVFMRMwEQYDVQQDEwpNYXRpIFVzdGF2MRkwFwYKCZImiZPyLGQBARMJ
> ODI0NTAwNjAyMSQwIgYJKoZIhvcNAQkBFhVtYXRpLnVzdGF2QGVlLmlibS5jb20wgZ8wDQYJKoZI
> hvcNAQEBBQADgY0AMIGJAoGBANKplfxoDQbrmsr7xPOLS4fO8kMiTehqeLdKPb1Cw0Xjxb4NoP3c
> rWqsgaLGUJSJcVdcdIRofCHHfIG4g+/sYVFoUSodn8cKQ1n+qW4wOR2l+HbjZMBvRAhQziXzK5h5
> dhfapAVMWyYxn5eLbhWo6n094iwIXWMZUVdgZOqSfzCDAgMBAAGjgdcwgdQwDgYDVR0PAQH/BAQD
> AgTwMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly93d3cuZXF1aWZheHNlY3VyZS5jb20vZWJ1c2lu
> ZXNzaWQvY3JsL3NtaW1lNjRiLmNybDB2BgNVHSAEbzBtMGsGCWCGSAGG+kwBATBeMBcGCCsGAQUF
> BwICMAswBxYAMAMCAQEaADBDBggrBgEFBQcCARY3aHR0cDovL3d3dy5lcXVpZmF4c2VjdXJlLmNv
> bS9lYnVzaW5lc3NpZC9zbWltZV9jcHMuaHRtbDANBgkqhkiG9w0BAQQFAAOBgQAWk2gXeHfJWCNo
> CxrSuKthY/ZnqpJ+4xGeoeYDwIxpx6BrrIzi4UmA3XHhKqV1XzQWHpyeXkGU5s8FLavHdmlb+EZu
> CipSsrPT4hnzgLrgEPfIQAELsApc+YXL5DCZmKCxnjXJmJAo0D3EML2dDo1wve5ReypvC4W5ShSE
> /FZg8jCCAyAwggKJoAMCAQICAhPgMA0GCSqGSIb3DQEBBAUAMEwxCzAJBgNVBAYTAlVTMRswGQYD
> VQQKExJFcXVpZmF4IFNlY3VyZSBJbmMxIDAeBgNVBAMTF0VxdWlmYXggU2VjdXJlIEVtYWlsIENB
> MB4XDTAxMTIyMTE2MTUzOVoXDTAzMDEwNDE2MTUzOVowgYQxCzAJBgNVBAYTAlVTMQwwCgYDVQQK
> EwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRMwEQYDVQQDEwpNYXRpIFVzdGF2MRkwFwYKCZImiZPy
> LGQBARMJODI0NTAwNjAyMSQwIgYJKoZIhvcNAQkBFhVtYXRpLnVzdGF2QGVlLmlibS5jb20wgZ8w
> DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANKplfxoDQbrmsr7xPOLS4fO8kMiTehqeLdKPb1Cw0Xj
> xb4NoP3crWqsgaLGUJSJcVdcdIRofCHHfIG4g+/sYVFoUSodn8cKQ1n+qW4wOR2l+HbjZMBvRAhQ
> ziXzK5h5dhfapAVMWyYxn5eLbhWo6n094iwIXWMZUVdgZOqSfzCDAgMBAAGjgdcwgdQwDgYDVR0P
> AQH/BAQDAgTwMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly93d3cuZXF1aWZheHNlY3VyZS5jb20v
> ZWJ1c2luZXNzaWQvY3JsL3NtaW1lNjRiLmNybDB2BgNVHSAEbzBtMGsGCWCGSAGG+kwBATBeMBcG
> CCsGAQUFBwICMAswBxYAMAMCAQEaADBDBggrBgEFBQcCARY3aHR0cDovL3d3dy5lcXVpZmF4c2Vj
> dXJlLmNvbS9lYnVzaW5lc3NpZC9zbWltZV9jcHMuaHRtbDANBgkqhkiG9w0BAQQFAAOBgQAWk2gX
> eHfJWCNoCxrSuKthY/ZnqpJ+4xGeoeYDwIxpx6BrrIzi4UmA3XHhKqV1XzQWHpyeXkGU5s8FLavH
> dmlb+EZuCipSsrPT4hnzgLrgEPfIQAELsApc+YXL5DCZmKCxnjXJmJAo0D3EML2dDo1wve5Reypv
> C4W5ShSE/FZg8jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpB
> MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh
> d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x
> JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
> c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEyMzEyMzU5NTla
> MIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv
> d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNl
> cnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp
> BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJKoZIhvcNAQEB
> BQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpCLGMnn5V7S+9+
> GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11uenwMpUtVfwYZ
> KX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJ
> KoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7qEqWih9iQiOM
> Fw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8jJgmRgHPQFBve
> Q6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEB
> BAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBl
> IFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u
> IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0Ex
> KzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAw
> MDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw
> ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE
> CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv
> bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu
> Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59LQ2P
> exLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t
> 6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAP
> BgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+NYFhh
> rCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd5Jr9
> E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMYIBnTCCAZkC
> AQEwUjBMMQswCQYDVQQGEwJVUzEbMBkGA1UEChMSRXF1aWZheCBTZWN1cmUgSW5jMSAwHgYDVQQD
> ExdFcXVpZmF4IFNlY3VyZSBFbWFpbCBDQQICE+AwCQYFKw4DAhoFAKCBojAYBgkqhkiG9w0BCQMx
> CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA5MDUxNTI4MDNaMCMGCSqGSIb3DQEJBDEW
> BBQ3rtwBGtyucLVYp1f2SmqMKDz5zTBDBgkqhkiG9w0BCQ8xNjA0MAcGBSsOAwIdMA4GCCqGSIb3
> DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgG7SYNvJ
> 9aXG3QJ3Rlt7wLJrKZqn5Z7WYvlbsSl8RvJ2ibF8dY2nJTJ+pCAg0b8UeY7E+OehCqBcdALGKTIB
> 0YxhczpJBt9POF/jFfXcuLedjLm3dnYhlCLXniTyGwrWwWBcl+v5wwPxyT06M8gP2XXXr68iG2ho
> mCva47/+9dIPAAAAAA==
>
> ---------z23686_boundary_sign--
>
>
> --__--__--
>
> _______________________________________________
> mol-general mailing list
> mol-general@lists.maconlinux.org
> http://lists.maconlinux.org/mailman/listinfo/mol-general
>
>
> End of mol-general Digest