Subject: Re: MOL things that are busting my butt
clerk@tbcnet.com
Date: Mon Feb 21 2000 - 05:31:47 MST
On Sun, 20 Feb 2000, Michael 'Mickey' Sattler wrote:
> (1) Why is my volume locked? The device isn't mounted from within LinuxPPC.
Check your /etc/molrc. This sounds like you forgot to set your r/w flags
for the disks your mounting.
> (2) Why does MOL sometimes dive into Slow Video mode and what can I
> do about it, other than killing it?
If your starting in X, and using MOL in a window, I believe other than
switching to the MOL console, there is nothing you can do.
> (3) Even when I run as root the new resolution doesn't take. I
> presume /usr/lib/mol/nvram/nvram.* writable by mol.
>
Sometimes, you have to wait until it gets further in the boot process. All
new MOL sessions start at a small res, but then, during the boot process,
it changes automatically.
> (4) Why does the Date & Time control panel think I'm in the Stockholm
> time zone? I like Stockholm (especially the Wasa), but I'd like my
> time zone to stay in San Francisco.
>
This is a bug, its known, and presumaby being worked on.
> (5) Does it matter that MOL bitches that it was complied against
> 2.2.14pre# and I'm running 14?
Not really.
>
> (6) What are the exact commands I must type to (a) patch the kernel
> and (b) give startmol the sticky bit so that any user may run MOL?
> --
>
Well, there are a number of ways to go about this. Most people will tell
you to just recompile your kernel. But, I for one, get kinda lazy about
kernel compiling. But, the good news is, with a minimum of effort, you can
patch things at boot time.
Step by step:
in /usr/lib/mol/bin:
You MUST modify the molpatching script to make sure that it has the FULL
path's for the other scripts it calls. Namely:
Change:
<snip>
function patch_apply() {
#
# Compare the System.map file with /proc/ksyms to make sure the
# devious user is not feeding us an irrelevant System.map file.
#
$PDIR./symchecker.pl $1
[ $? -ne 0 ] && return 1;
<snip>
to the following:
<snip>
function patch_apply() {
#
# Compare the System.map file with /proc/ksyms to make sure the
# devious user is not feeding us an irrelevant System.map file.
#
/usr/lib/mol/bin/symchecker.pl $1
[ $? -ne 0 ] && return 1;
<snip>
Then, there is one more path below to fix:
change:
<snip>
# Feed the symbols into the patching script...
#
echo Patching the kernel...
$PDIR./mpatch.engine 0x12345678 ${S[*]} 0x87654321
<snip>
to the following:
<snip>
# Feed the symbols into the patching script...
#
echo Patching the kernel...
/usr/lib/mol/bin/mpatch.engine 0x12345678 ${S[*]} 0x87654321
<snip>
Then, its off to your rc.local, add the following lines:
/usr/lib/mol/bin/molpatching
insmod -f /usr/lib/mol/modules/mol.o
insmod -f /usr/lib/mol/modules/sheep_net.o
Easy as one two three.
Notes:
1) Im doing this with a 2.2.15pre3 kernel, system map, and modules from
Ben H's page. My userland is LinuxPPC 1999 R5. So milage may vary.
2) the ONLY problem that doing this produces is when run for the first
time by a user, when quitting MOL, the script bitches it cannot kill mol
because its now the owner of the process. Im thinking its a SUID problem
with /usr/lib/mol/bin/mol that I've somehow overlooked. If anyone here
would be so kind as to help me with this one, id be eternally grateful. =)
Other than that, MOL runs great like this.
Christopher.
This archive was generated by hypermail 2a24 : Wed Mar 01 2000 - 00:06:20 MST