Menu
▾
▴
linux-apus-user
|
From: Kulwant B. <kb...@bl...> - 2003-12-06 21:46:29
|
Hello all, My question: Which is the best version of the kernel boothack and anything else I need to get LinuxPPC running on my machine: A1200 with BlizzardPPC with 35Gb SCSI storage (& 420Mb IDE), 128Mb RAM, BVision Permidia2 3DGFX (8Mb RAM) PCMCIA Ethernet card. Please be specific with the versions of each and if possible where to get each from. The stuff from http://ftp.no.debian.org//debian/dists/woody/main/disks-powerpc/current/apus/ has an old boothack which complains about "compressed image too large" and the one from sourceforge starts booting but kernel panics when initialising the PCMCIA ethernet card. With some other version it panic'd when trying to set the h/w clock. Kind regards, Kulwant |
|
From: Andreas <aw...@sw...> - 2003-12-10 06:02:55
|
Hi Kulwant On Sat, 2003-12-06 at 22:46, Kulwant Bhogal wrote: > Hello all, > > My question: > > Which is the best version of the > > kernel > boothack Use the latest boothack available. > but kernel panics when initialising > the PCMCIA ethernet card. Hmm, hasn't there been a problem in recent kernels with apne? I think it got fixed in kernel 2.4.21 (search the apus devel archive for thread "Kernel 2.4.21". The posts are from july/august 2003.). If it doesn't work at all, remove the pcmcia network card. Though I guess you want some kind of ethernet connection.. ;) > With some other version it panic'd when trying to set the > h/w clock. Don't know about this one. -- Best wishes, Andi |
|
From: Kulwant B. <kul...@bt...> - 2003-12-10 22:16:53
|
Hello Andreas, Thanks for you mail. > Use the latest boothack available. yes that has helped in this instance. > Hmm, hasn't there been a problem in recent kernels with apne? I think it > got fixed in kernel 2.4.21 (search the apus devel archive for thread > "Kernel 2.4.21". The posts are from july/august 2003.). err, where is the devel arch? > If it doesn't work at all, remove the pcmcia network card. Though I > guess you want some kind of ethernet connection.. ;) Well the PCMCIA ethernet problem doesn't surface in 2.4.20 so I will try Alan's suggestion of an older kernel and if that solves the clock problem then I will have to tackle whatever other problems that throws up as and when they occur. Kind regards, Kulwant |
|
From: Andreas <aw...@sw...> - 2003-12-11 00:05:31
|
Hi Kulwant On Wed, 2003-12-10 at 23:16, Kulwant Bhogal wrote: > Hello Andreas, > > Thanks for you mail. You're welcome! > > Use the latest boothack available. > > yes that has helped in this instance. Ok, so first problem solved. :) > > Hmm, hasn't there been a problem in recent kernels with apne? I think it > > got fixed in kernel 2.4.21 (search the apus devel archive for thread > > "Kernel 2.4.21". The posts are from july/august 2003.). > > err, where is the devel arch? http://sourceforge.net/mailarchive/forum.php?forum_id=7161 And there finally seems to be a possibility to search the archive. :) > > If it doesn't work at all, remove the pcmcia network card. Though I > > guess you want some kind of ethernet connection.. ;) > > Well the PCMCIA ethernet problem doesn't surface in 2.4.20 so I will try > Alan's suggestion of an older kernel and if that solves the clock problem > then I will have to tackle whatever other problems that throws up as and > when they occur. Hmm, if I understand you right, 2.4.20 fails because of the clock stuff but pcmcia would work, and other kernels fail because of the apne stuff? Btw., which kernel did you use to install the system? Maybe you want to turn off the /etc/init.d/hwclock.sh script to temporarily stop the system from writing to the clock registers during startup/shutdown. It gets called in rcS.d as well as in rc6.d if I'm right. -- Best wishes, Andi |
|
From: Kulwant B. <kul...@bt...> - 2003-12-13 16:09:05
|
Hello Andi, > Hmm, if I understand you right, 2.4.20 fails because of the clock stuff > but pcmcia would work, and other kernels fail because of the apne stuff? Yes, but I haven't been through all of the old kernels yet. I'm hoping to give that a go this weekend. Will report my findings. > Btw., which kernel did you use to install the system? 2.4.20. > Maybe you want to turn off the /etc/init.d/hwclock.sh script to > temporarily stop the system from writing to the clock registers during > startup/shutdown. It gets called in rcS.d as well as in rc6.d if I'm > right. Haven't got a clue how to do that - not even where to start. Could you post step by step instructions please? Thanks for all your advice so far. Kind regards, Kulwant |
|
From: Andreas <aw...@sw...> - 2003-12-14 01:51:00
|
Hi Kulwant
On Sat, 2003-12-13 at 17:08, Kulwant Bhogal wrote:
> Yes, but I haven't been through all of the old kernels yet. I'm hoping to
> give that a go this weekend. Will report my findings.
>
> > Btw., which kernel did you use to install the system?
>
> 2.4.20.
Interesting. Since it fails during writing to the harware clock, this
means you never got past the first phase of the installation?
> > Maybe you want to turn off the /etc/init.d/hwclock.sh script to
> > temporarily stop the system from writing to the clock registers during
> > startup/shutdown. It gets called in rcS.d as well as in rc6.d if I'm
> > right.
>
> Haven't got a clue how to do that - not even where to start. Could you post
> step by step instructions please?
Hmm, since normal booting doesn't work for you, boot with the install
image:
1) go directly to the step of the installer where you can mount
partitions. There, you choose your root partition. IIRC it gets mounted
under /target/.
2) go to the step where you can open a shell. Then
# cd /target/
# cd etc/rcS.d/
# mv S50hwclock.sh offS50hwclock.sh
"S50hwclock.sh" is in fact a link to "../init.d/hwclock.sh".
To prevent troubles during shutdown, do something similar for
rc6.d:
# cd ../rc6.d/
# mv K25hwclock.sh offK25hwclock.sh
BTW: I have no idea why it tries to write to the clock at boot time at
all.
If it doesn't work yet, you could also rename the hwclockfirst.sh call,
although it doesn't seem to write to the clock.
# cd etc/rcS.6/
# mv S18hwclockfirst.sh offS18hwclockfirst.sh
But I would heavily advise against it, because then nothing is setting
the system clock (system clock != hardware clock), which could lead to
strange behaviour of the system.
--
Best wishes,
Andi
|
|
From: Kulwant B. <kul...@bt...> - 2003-12-14 03:02:35
|
Hello Andi, > Hmm, since normal booting doesn't work for you, boot with the install > image: > 1) go directly to the step of the installer where you can mount > partitions. There, you choose your root partition. IIRC it gets mounted > under /target/. > 2) go to the step where you can open a shell. Then > # cd /target/ > # cd etc/rcS.d/ > # mv S50hwclock.sh offS50hwclock.sh > "S50hwclock.sh" is in fact a link to "../init.d/hwclock.sh". > To prevent troubles during shutdown, do something similar for > rc6.d: > # cd ../rc6.d/ > # mv K25hwclock.sh offK25hwclock.sh > BTW: I have no idea why it tries to write to the clock at boot time at > all. OK, tried the above and I still get a kernel panic (which I can't capture with dmesg - it always says: "Searching for SAVEKMSG magic... Not found" I managed to write down this before it rebooted: System time was Sun Dec 14 02:45:22 UTC 2003 Setting the System Clock using the Hardware Clock as reference... NIP: C00DCA04 XER: 20000000 LR: C00DC988 REGS: c7c71d60 TRAP: 0300 There was a fair bit after that which I didn't catch. > If it doesn't work yet, you could also rename the hwclockfirst.sh call, > although it doesn't seem to write to the clock. > # cd etc/rcS.6/ > # mv S18hwclockfirst.sh offS18hwclockfirst.sh > But I would heavily advise against it, because then nothing is setting > the system clock (system clock != hardware clock), which could lead to > strange behaviour of the system. Hmmm, about to try this now....... Kind Regards, Kulwant |
|
From: Kulwant B. <kul...@bt...> - 2003-12-14 03:26:29
|
Hello Andi, > If it doesn't work yet, you could also rename the hwclockfirst.sh call, > although it doesn't seem to write to the clock. > # cd etc/rcS.6/ > # mv S18hwclockfirst.sh offS18hwclockfirst.sh > But I would heavily advise against it, because then nothing is setting > the system clock (system clock != hardware clock), which could lead to > strange behaviour of the system. Well, I did try that (because all else before that had failed) and I got: Congratulations, You have successfully installed Debian! and after the message about how to revisit the setup process (by running /usr/sbin/base-config) I got another kernel panic: Loading /etc/console/boottime.kmap.gz kernel access of bad area pc c00dca04 lr c00de9f8 address 70 tsk hwclock/230 task = c65dc000[230] 'hwclock' mm-> pgd c6e2c000 last syscall: 6 GPR00: 00001072 C65DDE10 C65DC000 00000001 00008000 00000000 C6E09D80 C980000 GPR08: 0000000B 00000000 C0180000 C67EC08C 2422 and then it rebooted before I could write down the rest of it. So I guess you were right about it leading to strange behaviour of the system :-) But it appears to be the furthest I have got so far :-) Kind Regards, Kulwant |
|
From: Andreas <aw...@sw...> - 2003-12-14 15:54:25
|
Hi Kulwant
On Sun, 2003-12-14 at 04:20, Kulwant Bhogal wrote:
> > If it doesn't work yet, you could also rename the hwclockfirst.sh call,
> > although it doesn't seem to write to the clock.
>
> > # cd etc/rcS.6/
> > # mv S18hwclockfirst.sh offS18hwclockfirst.sh
>
> > But I would heavily advise against it, because then nothing is setting
> > the system clock (system clock != hardware clock), which could lead to
> > strange behaviour of the system.
>
> Well, I did try that (because all else before that had failed) and I got:
>
> Congratulations, You have successfully installed
Yeah, so we've got one step further! :)
> and after the message about how to revisit the setup process (by running
> /usr/sbin/base-config) I got another kernel panic:
>
> Loading /etc/console/boottime.kmap.gz
>
> kernel access of bad area pc c00dca04 lr c00de9f8 address 70 tsk hwclock/230
> task = c65dc000[230] 'hwclock'
^^^^^^^^^
So you really seem to have a major problem with the hw clock!
Is the contact between the ppc board and the motherboard ok? Where does
the clock actually reside (motherboard or ppc)? Is it some strange
non-standard chip?
> mm-> pgd c6e2c000 last syscall: 6
>
> GPR00: 00001072 C65DDE10 C65DC000 00000001 00008000 00000000
> C6E09D80 C980000
>
> GPR08: 0000000B 00000000 C0180000 C67EC08C 2422
>
> and then it rebooted before I could write down the rest of it.
Can you add -d debug to your bootstrap line, and after the kernel oops
reboot run dmesg > ram:output in the shell (amigaOS side)? Post the
output here. I hope some of the kernel gurus can do something about it.
> So I guess you were right about it leading to strange behaviour of the
> system :-)
Well, this wasn't particularly what I've been thinking about w.r.t.
strange behaviour, because it seemed to crash again during an attempt to
read the hwclock.
> But it appears to be the furthest I have got so far :-)
Well, the goal would be to run, not just crash every other minute..
--
Best wishes,
Andi
|
|
From: Kulwant B. <kul...@bt...> - 2003-12-14 17:43:23
|
Hello Andi, >> kernel access of bad area pc c00dca04 lr c00de9f8 address 70 tsk >> hwclock/230 task = c65dc000[230] 'hwclock' > ^^^^^^^^^ > So you really seem to have a major problem with the hw clock! > Is the contact between the ppc board and the motherboard ok? Where does > the clock actually reside (motherboard or ppc)? Is it some strange > non-standard chip? I believe the contact between the PPC board and motherboard is good, otherwise I would expect instability on the Amiga side too. But the Amiga side is as stable as rock. I can have the machine running all day with IBrowse, SimpleMail, Amplifier (running WOS ppc mp3 decoding), MiamiDX, Samba (for occasional networking to PCs), Jabberwocky, Editpad, Classaction, Warp jpg Datatypes etc. in constant use with no lock-ups, crashes, freezes etc. I can even play Quake WOS and GL_Quake, Shogo, WipeOut and Freespace so if there was a PPC problem, I would expect it to manifest itself here. Although Freespace can occasionally lock-up, Shogo and Quake don't and neither does WipeOut, so I on that front I suspect the software rather than the hardware. The clock resides on the PPC board. The board AFAIK is a standard Phase5 BlizzardPPC (second hand - but I've had it since the year 2000 and not had any problems with it). The battery had nearly started to leak so I unsoldered it and soldered in a CMOS battery holder and replaced the battery. The clock still functions (i.e. saves and holds time) from the AmigaOS side, so if I had blown anything I would expect it not to work from the AmigaOS side either. I can open the Tower up and report the Revision number of the board (If I can find it) if it will help. > Can you add -d debug to your bootstrap line, and after the kernel oops > reboot run dmesg > ram:output in the shell (amigaOS side)? Post the > output here. I hope some of the kernel gurus can do something about it. Off to try it now. > Well, the goal would be to run, not just crash every other minute.. But of course :-). Thanks for all your help so far. Kind Regards, Kulwant |
|
From: Geert U. <ge...@li...> - 2003-12-15 09:31:35
|
On Sun, 14 Dec 2003, Andreas [ISO-8859-1] W=FCst wrote:
> On Sun, 2003-12-14 at 04:20, Kulwant Bhogal wrote:
> > > If it doesn't work yet, you could also rename the hwclockfirst.sh c=
all,
> > > although it doesn't seem to write to the clock.
> >
> > > # cd etc/rcS.6/
> > > # mv S18hwclockfirst.sh offS18hwclockfirst.sh
> >
> > > But I would heavily advise against it, because then nothing is sett=
ing
> > > the system clock (system clock !=3D hardware clock), which could le=
ad to
> > > strange behaviour of the system.
> >
> > Well, I did try that (because all else before that had failed) and I =
got:
> >
> > Congratulations, You have successfully installed
>
> Yeah, so we've got one step further! :)
>
> > and after the message about how to revisit the setup process (by runn=
ing
> > /usr/sbin/base-config) I got another kernel panic:
> >
> > Loading /etc/console/boottime.kmap.gz
> >
> > kernel access of bad area pc c00dca04 lr c00de9f8 address 70 tsk hwcl=
ock/230
^^
Looks like a NULL-pointer struct dereference.
Do you have a System.map? Can you look up the label (closest before) for
c00dca04 and c00de9f8?
> > task =3D c65dc000[230] 'hwclock'
>
> So you really seem to have a major problem with the hw clock!
>
> Is the contact between the ppc board and the motherboard ok? Where does
> the clock actually reside (motherboard or ppc)? Is it some strange
> non-standard chip?
How does the kernel detect your clock? A2000 or A3000 style?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org
In personal conversations with technical people, I call myself a hacker. =
But
when I'm talking to journalists I just say "programmer" or something like=
that.
-- Linus Torvalds
|
|
From: Andreas <aw...@sw...> - 2003-12-14 17:35:40
|
Hi Kulwant On Sun, 2003-12-14 at 04:20, Kulwant Bhogal wrote: > > If it doesn't work yet, you could also rename the hwclockfirst.sh call, > > although it doesn't seem to write to the clock. > > > # cd etc/rcS.6/ > > # mv S18hwclockfirst.sh offS18hwclockfirst.sh > > > But I would heavily advise against it, because then nothing is setting > > the system clock (system clock != hardware clock), which could lead to > > strange behaviour of the system. > > Well, I did try that (because all else before that had failed) and I got: Which means it already crashes when trying to simply READ the clock. > Loading /etc/console/boottime.kmap.gz > > kernel access of bad area pc c00dca04 lr c00de9f8 address 70 tsk hwclock/230 > task = c65dc000[230] 'hwclock' /sbin/hwclock tries to read the time from the RTC. You have to know that the system clock gets set by the hardware clock during boot, and afterwards the hardware clock is not going to be probed again (except during shutdown, when the hwclock.sh script tries to write back the system time to the hardware clock). The system clock generates it's own interrupts, so the hardware clock is mainly there to keep the time when the system is powered off. C.f. man hwclock. Though in /drivers/char/rtc.c there's a comment mentioning something about periodic syncs (every 11 min) by time.c (line 54).. So you're system should at least run for 11 min uninterrupted.. > mm-> pgd c6e2c000 last syscall: 6 > > GPR00: 00001072 C65DDE10 C65DC000 00000001 00008000 00000000 > C6E09D80 C980000 > > GPR08: 0000000B 00000000 C0180000 C67EC08C 2422 > > and then it rebooted before I could write down the rest of it. I have no clue here. According to http://lxr.linux.no/diff/drivers/char/rtc.c?a=ppc;diffval=2.4.18;diffvar=v the rtc driver got changed between 2.4.18 and 2.4.19, but no difference between 2.4.19 and 2.4.20. Though there may also be some apus specific changes not documented here. The changes seem to have something to do with sysctl, though I don't know what exactly (sysctl stuff seems to got added to 2.4.19). What you could also do is to # mv /sbin/hwclock /sbin/OFFhwclock although this is really really ugly!! But it should prevent the system from interacting with the hardware clock. Afterwards set the system clock using # date 1214200003 (for December 14 (1214), 8 p.m. (2000), 2003 (03)). You'd have to do run date every time you boot your system. But this is definitely not how a productive system should be run! So, try to get the dmesg output anyway and post it. -- Best wishes, Andi |
|
From: Kulwant B. <kul...@bt...> - 2003-12-14 17:57:27
|
Hello Andi, > Which means it already crashes when trying to simply READ the clock. Yes, it would appear so. >> Loading /etc/console/boottime.kmap.gz >> >> kernel access of bad area pc c00dca04 lr c00de9f8 address 70 tsk >> hwclock/230 task = c65dc000[230] 'hwclock' > /sbin/hwclock tries to read the time from the RTC. You have to know that > the system clock gets set by the hardware clock during boot, and > afterwards the hardware clock is not going to be probed again (except > during shutdown, when the hwclock.sh script tries to write back the > system time to the hardware clock). The system clock generates it's own > interrupts, so the hardware clock is mainly there to keep the time when > the system is powered off. C.f. man hwclock. Makes sense. > Though in /drivers/char/rtc.c there's a comment mentioning something > about periodic syncs (every 11 min) by time.c (line 54).. So you're > system should at least run for 11 min uninterrupted.. hmmm.... > I have no clue here. According to > http://lxr.linux.no/diff/drivers/char/rtc.c?a=ppc;diffval=2.4.18;diffvar=v > the rtc driver got changed between 2.4.18 and 2.4.19, but no difference > between 2.4.19 and 2.4.20. Though there may also be some apus specific > changes not documented here. The changes seem to have something to do > with sysctl, though I don't know what exactly (sysctl stuff seems to got > added to 2.4.19). > What you could also do is to > # mv /sbin/hwclock /sbin/OFFhwclock > although this is really really ugly!! But it should prevent the system > from interacting with the hardware clock. > Afterwards set the system clock using > # date 1214200003 > (for December 14 (1214), 8 p.m. (2000), 2003 (03)). You'd have to do run > date every time you boot your system. > But this is definitely not how a productive system should be run! So, > try to get the dmesg output anyway and post it. I will try both and see what happens. Kind Regards, Kulwant |
|
From: Kulwant B. <kul...@bt...> - 2003-12-14 22:22:40
|
Hello Andi, > Though in /drivers/char/rtc.c there's a comment mentioning something > about periodic syncs (every 11 min) by time.c (line 54).. So you're > system should at least run for 11 min uninterrupted.. See below. > What you could also do is to > # mv /sbin/hwclock /sbin/OFFhwclock > although this is really really ugly!! But it should prevent the system > from interacting with the hardware clock. Ok, I did this. And no crashes. It went on to configuring the base system etc. But I didn't really know what I was doing so I have quit out of that without installing or deleting anything. I didn't get to a shell either so I couldn't set the date even manually (as you suggested below). > Afterwards set the system clock using > # date 1214200003 Well the system did run in the configure base system section for ages (I left it alone for over an hour) and I didn't get any problems associated with the 11 min interupt you suggested above. > But this is definitely not how a productive system should be run! So, > try to get the dmesg output anyway and post it. Try as I might I just don't get any debug output from dmesg. It simply says: Searching for SAVEBOOT magic... Not found I have tried starting wth no startup-sequence and before the reset from OS3.9 but still no joy. I inserted the -d in my start script like so: bootstrap --apus -k linux.bin -d -v root=/dev/hda2 rw nobats video=pm2fb:mode:1024x768-75 not sure what the -v is for. Is the -d in the right place? I did notice that I do get more prompts on running that script with the -d option in there. So I think it is doing something. But Dmesg doesn't find any debug information after a reset. The other question is, is there a way of resetting the Linux side which cleanly unmounts my hda2 partition? And is there a way of resetting which will save the debug information too? Kind Regards, Kulwant |
|
From: Andreas <aw...@sw...> - 2003-12-14 22:52:30
|
Hi Kulwant On Sun, 2003-12-14 at 23:16, Kulwant Bhogal wrote: > Hello Andi, > > > Though in /drivers/char/rtc.c there's a comment mentioning something > > about periodic syncs (every 11 min) by time.c (line 54).. So you're > > system should at least run for 11 min uninterrupted.. > > See below. > > > What you could also do is to > > > # mv /sbin/hwclock /sbin/OFFhwclock > > > although this is really really ugly!! But it should prevent the system > > from interacting with the hardware clock. > > Ok, I did this. And no crashes. Cool! > It went on to configuring the base system > etc. But I didn't really know what I was doing so I have quit out of that > without installing or deleting anything. I didn't get to a shell either so I > couldn't set the date even manually (as you suggested below). Just Ctrl-Alt-F2 and there should be a shell IIRC. > > Afterwards set the system clock using > > > # date 1214200003 > > Well the system did run in the configure base system section for ages (I > left it alone for over an hour) and I didn't get any problems associated > with the 11 min interupt you suggested above. This is good news! Also that this clearly isolates the system crashes to the hardware clock reads. > > But this is definitely not how a productive system should be run! So, > > try to get the dmesg output anyway and post it. > > Try as I might I just don't get any debug output from dmesg. It simply says: > > Searching for SAVEBOOT magic... > Not found > > I have tried starting wth no startup-sequence and before the reset from > OS3.9 but still no joy. I inserted the -d in my start script like so: > > bootstrap --apus -k linux.bin -d -v root=/dev/hda2 rw nobats video=pm2fb:mode:1024x768-75 > > not sure what the -v is for. The -v option stands for verbose IIRC (I guess it activates some additional information for boothack, NOT the kernel itself). > Is the -d in the right place? Don't know about the place, but there's definitely something lacking, you forgot to add the debug=mem part (or better, I didn't tell you about it..). Please do like this: bootstrap --apus -k linux.bin -v root=/dev/hda2 rw nobats video=pm2fb:mode:1024x768-75 -d debug=mem C.f. http://linux-apus.sourceforge.net/FAQ.html for full description. > I did notice that I do get more prompts on running that script with the -d > option in there. I guess that's correct. > So I think it is doing something. But Dmesg doesn't find > any debug information after a reset. Because you didn't tell it to save the stuff in the memory. Well, I guess it was me who forgot to mention it in the last mail anyway.. > The other question is, is there a way > of resetting the Linux side which cleanly unmounts my hda2 partition? After the crash? I don't think so. Except if you can get a debug monitor running maybe, but this is over my head ATM. > And is there a way of resetting which will save the debug information too? Well, I think debug=mem will do. It was just that this was lacking. Sorry for that! -- Best wishes, Andi |
|
From: Kulwant B. <kul...@bt...> - 2003-12-15 23:36:33
|
Hello Andi, > Just Ctrl-Alt-F2 and there should be a shell IIRC. I will try this. Although I think my biggest problem whilst configuring the base system was knowing what I wanted and what I didn't!! Not sure how to figure that out yet. In theory I would like to leave as much installed as possible and know what to install to get some sort of gui and maybe some apps like a browser etc installed - but I may be trying to run before I can crawl here...... not forgetting that the clock problem isn't really resolved yet (I'm reminding myself). I remember getting some dependency conflicts and not being able to resolve them. Maybe I will post details here later after I have had another go. > This is good news! Also that this clearly isolates the system crashes to > the hardware clock reads. Yes, I am glad that the problem seems to have been totally isolated. Thanks in no small part to you - nobody had made those suggestions before and this is the furthest I have ever got with trying to get Linux running on my machine. >> > But this is definitely not how a productive system should be run! So, >> > try to get the dmesg output anyway and post it. I will put the clock stuff back to how it was originally and collect some debug output to post here. Watch this space. > Because you didn't tell it to save the stuff in the memory. Well, I > guess it was me who forgot to mention it in the last mail anyway.. Don't worry, better late than never. And if my brain had retained any of the stuff I had been reading, I would have noticed that myself. >> The other question is, is there a way >> of resetting the Linux side which cleanly unmounts my hda2 partition? > After the crash? I don't think so. Except if you can get a debug monitor > running maybe, but this is over my head ATM. No, I meant before a crash. For example when running the installation program, if I chose "reboot the system" then when starting Linux again it would run a check on hda2 everytime because it would complain that the partition had not been cleanly unmounted. I am sure I even "unmounted" hda2 and still the revalidate ran afterwards - I will recheck that but I'm sure that's what happened. Thank you for all your help so far - I really appreciate it. Kind regards, Kulwant |
|
From: Andreas <aw...@sw...> - 2003-12-17 23:47:06
|
Hi Kulwant On Tue, 2003-12-16 at 00:30, Kulwant Bhogal wrote: > Hello Andi, > > > Just Ctrl-Alt-F2 and there should be a shell IIRC. > > I will try this. Although I think my biggest problem whilst configuring the > base system was knowing what I wanted and what I didn't!! Not sure how to > figure that out yet. In theory I would like to leave as much installed as > possible and know what to install to get some sort of gui and maybe some > apps like a browser etc installed - but I may be trying to run before I can > crawl here...... You maybe want to leave out tasksel and dselect completely, since I don't like them (and you may not like them too). I usually just skip them and install a usable system myself using apt-get install, since this lets you choose the packages you really want, and you don't get lots of (not needed) stuff installed like when using tasksel. The downside, of course, is that you have to know which packages you have to install to get a running system.. ;) If you'd like, I could send a comprehensive list of packages to install if you want to have things like xfree86 and gnome running. > not forgetting that the clock problem isn't really resolved > yet (I'm reminding myself). Yeah, but this mainly seems to be the only obstacle right now. > I remember getting some dependency conflicts and not being able to resolve > them. Maybe I will post details here later after I have had another go. D'oh. What did you try to install and from where? This shouldn't happen on a stable release (i.e. woody ATM). > > This is good news! Also that this clearly isolates the system crashes to > > the hardware clock reads. > > Yes, I am glad that the problem seems to have been totally isolated. Thanks > in no small part to you - nobody had made those suggestions before and this > is the furthest I have ever got with trying to get Linux running on my > machine. You're welcome. The renaming stuff was really a bit of last resort thing, but it helped to isolate the problem. > >> > But this is definitely not how a productive system should be run! So, > >> > try to get the dmesg output anyway and post it. > > I will put the clock stuff back to how it was originally and collect some > debug output to post here. Watch this space. Cool! Please do so!! Or at least try to look up the symbols in the System.map as Geert mentioned in another mail (I think there's a System.map delivered with the kernel lha for the amigaOS side). > > Because you didn't tell it to save the stuff in the memory. Well, I > > guess it was me who forgot to mention it in the last mail anyway.. > > Don't worry, better late than never. And if my brain had retained any of the > stuff I had been reading, I would have noticed that myself. Ok, so I'm relieved! :) > >> The other question is, is there a way > >> of resetting the Linux side which cleanly unmounts my hda2 partition? > > > After the crash? I don't think so. Except if you can get a debug monitor > > running maybe, but this is over my head ATM. > > No, I meant before a crash. For example when running the installation > program, if I chose "reboot the system" then when starting Linux again it > would run a check on hda2 everytime because it would complain that the > partition had not been cleanly unmounted. I am sure I even "unmounted" hda2 > and still the revalidate ran afterwards - I will recheck that but I'm sure > that's what happened. Hmmm, this is not normal! What type of filesystem did you choose for the linux partition(s)? I'd take ext3 anyway. I don't think this has something to do with the clock problem (though it may) since I once booted with the clock reset to 1978 (say hello to my clock battery..) and it did only complain about some module/kernel date mismatch. > Thank you for all your help so far - I really appreciate it. As I said, you're welcome. Always nice if I can help!! :) -- Best wishes, Andi |
|
From: Kulwant B. <kul...@bt...> - 2003-12-22 19:52:08
|
Hello Andi, > You maybe want to leave out tasksel and dselect completely, since I > don't like them (and you may not like them too). I usually just skip > them and install a usable system myself using apt-get install, since > this lets you choose the packages you really want, and you don't get > lots of (not needed) stuff installed like when using tasksel. The > downside, of course, is that you have to know which packages you have to > install to get a running system.. ;) <split> > If you'd like, I could send a > comprehensive list of packages to install if you want to have things > like xfree86 and gnome running. Yes please. As a side question what is the difference between xfree86 and gnome? A quick search on yahoo yields enough to tell me one is a gui system and another builds a desktop, but do I need both? >> I will put the clock stuff back to how it was originally and collect >> some debug output to post here. Watch this space. > Cool! Please do so!! Haven't had the chance to do this yet. > Hmmm, this is not normal! What type of filesystem did you choose for the > linux partition(s)? I'd take ext3 anyway. Yes I am using ext3. Kind regards, Kulwant |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X