[Fwd: Re: [expert] "EBDA too big"]
Original Message From: Tom Walsh <[EMAIL PROTECTED]> Subject: Re: [expert] "EBDA too big" To: civileme <[EMAIL PROTECTED]> BCC: [EMAIL PROTECTED] civileme wrote: > > On Sunday 12 August 2001 05:04, Tom Walsh wrote: > > Okay, I admit it: I am totally pissed that Mandrake would release such > > F@%$!@%$ A%(^*&&* garbage as Mandrake 8.0 to the general public without > > *HEAVY* warnings that this is *not a production release*!!! > > > > I can deal with the editing of the Makefile to set the CC to kgcc, then > > why? Because this RedHat distro has become infamous, there was enough talk on the mailing lists / talkbacks that "clued" me into this bit of trivia. After all, I have had the distro here on CD for about 3 months, been playing with the darned thing and it was not a 'production release' AFAIWK. If you cannot compile the kernel 'out of the box', then it is a BETA. > > > have to search the mailing list to find out that this release is so > > broken that it needs an mrproper to compile modules properly... > > Because there are some deps already defined This is not unusual. > Oh, and name another distro that has been release in the past five years that the generic install required a 'make mrproper' before the kernel could be successfully compiled. Come on, I dare you. > > > > After slogging my way through all this, I finally have something that > > compiles and installs, then fails to boot with some mysterious message > > of: "EDBA too big". Okay, I'm game what the F#@$ is an EDBA???!!! > > > > endbase address > > Your kernel is too large. OK, I will accept that a 980K kernel may have been too large... > > http://genericbooks.com/Literature/Documents/pdf/Books/lilo_user.pdf > > Look at the above link. More 'Trivial pursuit', so what is wrong with a /usr/src/linux/README.Mandrake to spell out this wonderous knowledge? Are you afraid that Linus is going to have a fit, or something? > > > This krap is going too far. I develop under uClinux with the 2.4.6 > > kernel and we don't encounter this ineptitude when it comes to releasing > > a version!!! What is this: "let's play Trivial Pursuit" or some such > > childish game? > > > > Very unfair comparison. We have at least an order of magnitude more to do with the >kernel > to make sure it works wih Reiser and other things, like USB and lm_sensors and such, >and > uClinux isn't even real linux--just an abbreviated copy--no virtual memory construct >available at > all. It runs only on DragonballEZs and ARMs without a lot of the peripherals we >have to accommodate. > And they most likely have more kernel hackers than we do, cause that is about all >they do. That is a poor reply to the question. You are not answering it, you are throwing up a smoke screen. The lack of an MMU / DMA is irrespective of the question of the quality of the work that you produce. Your stuff does not work without significant 'special knowledge', you blew it, you just won't admit it. You feel that just because RedHat does it this way that it makes it acceptable for You to shrug your shoulders and point to the "other guy". This is not why I switched to Mandrake, You made a decent system, You messed up, now admit it. > > > ARRRGGHHH! > > > > TomW > > For your info, this is not the flame mandrake list. > No? Then please give me the URL. I would like to let the packagers know just what the end-user thinks of your latest mistake! Just because Linus releases a version of the linux kernel and 'You follow the leader' (RedHat), this does not make it right. The GPL *allows* You the right to make changes to the code source, as long as it is distro'ed. What is the problem, You cannot do some of the simple work needed to make the installation of the system + compile of the kernel an easy experience? I have more to do with my time than to spend it slogging my way through mailing lists, and arcane knowledge-bases, to find out that the packagers messed up and are willing to place the onus on us, the end-user. At least with uClinux, we test our stuff to make sure it works "out of the box" before we release it! Your solution is vastly inferior, You rely upon making huge amounts of modules available in the hopes that no-one will have to ever compile the kernel. I needed to make changes to some of the 2.4.x IRDA drivers so I can interface to embedded systems, the changes are to add my own debugging info, so I chose my most reliable distro: Mandrake. Big mistake.. Let me ask you this: how many man-hours would it take to edit /usr/src/linux/Makefile to set CC=kgcc, then do a 'make mrproper' on the kernel before you distro it? :-P You messed up... Regards, TomW
[expert] /var/lock files empty.
Hello, This is odd! I did a new install of Mandrake 8.0, finally finished re-installing most of my software (kylix, StarOffice, m68k-elf tools, etc). I now find that kermit creates an empty /var/lock/LCK..ttyS0 file, it is zero length. Another program, one I wrote and run under Mandrake 7.2, also is creating empty lockfiles. Curiously, minicom is creating lockfiles with the correct data in them. I did install this system with "Medium Security".. Is there something new under 2.4 kernel based systems / glibc 2.2.2 that is now required to write data to the lockfile dir? Right now, I am hacking the minicom sources apart trying to see what it could be! Anyone have any ideas? Puzzled, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." Want to buy your Pack or Services from MandrakeSoft? Go to http://.mandrakestore.com
Re: [expert] /var/lock files empty.
Never mind. :-/ Adding more code to the routines:
if (write(lockfd, pid_str, 11) == -1) {
fprintf (stderr, "Cannot create lock: %s\n", strerror(errno));
}
show that "No space left on device!". Guess what? Yup! The /var
volume was maxed!
Why is it that you spend 2 hours looking for the solution and 5 minutes
after you post that you discover the solution? :-/
Regards,
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
Want to buy your Pack or Services from MandrakeSoft?
Go to http://.mandrakestore.com
Re: [expert] Resolution of rsh failure
"John J. LeMay Jr." wrote: > > Last week I was trying to troubleshoot and fix a problem where my LM8f1 machine > would not allow my LM72 client to rsh/ssh to the machine as ROOT. Other users > could gain access with no problem. My thanks to all why offered suggestions. > However, the only way I've found to enable rsh for root was to delete > /etc/securetty. Note I had tried adding rsh, rlogin, and rexec to the end of > /etc/securetty (one per line), but this did not help. After finding that > deleting /etc/securetty fixed the problem, I tried creating a new securetty file > in /etc containing the following entries: > > tty1 > tty2 > tty3 > tty4 > tty5 > tty6 > rsh > rlogin > rexec > > This did not work either. Again, root was denied permission to rsh to the > machine. Note that rlogin has always worked for root regardless of the status of > this file. All other users - so long as they have a .rhosts file - can access > the 80f1 machine with rsh. > Hello John, Thanks for the quick-fix, my other tape drive had died and it has been a couple of months before I got a replacement. In the meantime, I tore the workstation down, upgraded hardware and then install a clean copy of Mandrake 8. Now I am beginning to wonder about the wisdom in the upgrade, LM7.2 didn't exhibit this odd behaviour! I got the new tape drive in yesterday and I desperately needed to backup the server!!! That is when I encountered the same problem as you with rsh. IIRC, one of the distros required the ttyPn (or was it ttypn) entries in /etc/securetty before any root logins were allowed via ethernet. The same appears to be true for LM80, adding "pts/0" & "pts/1" to the /etc/securetty allows root logins via telnet, but it still stops the rsh from working. I suspect that there is some other subsystem that is stopping rsh from gaining access. It seems that the only way to resolve this issue is to get the rsh sources and start putting some printf's into it to see where rsh is dying?!! Meanwhile, thanks for the "work around", my badly needed backup is running smoothly now (one the workstation, fortunately, it is not accessable via the 'net =-O ). Regards, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] alias?
Michael Holt wrote: > > Hello all you experts out there! > I just started attending a local linux users group which meets once a > month. Last month I learned about using aliases; "ll" instead of "ls > -l". I just had my appendix out and so I've had to miss today's meeting > and I was hoping that someone here could refresh my memory and tell me > where I could find out the list of current aliases on my machine? Also, > what directory are they in? > Just type alias and it will show the list to you. Aliases are normally set in /etc/profile or /etc/bashrc. TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] alias?
Michael Holt wrote: > > Thank you so much Tom! It's funny how logical things can seem after you > hear the correct answer! > Also, do a 'man alias' for how it works. TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] Sticky bit on /tmp
Hello, This is really odd.. I had gotten my 18G SCSI drive back from warranty, fdisk'ed it, copied file systems from the IDE's I had been using over to the SCSI drive. But, on the old system and on my server, the /tmp dir has the sticky bit set, I cannot get the sticky to be set on /tmp when I boot the system. I have to manually set it. I assume that the sticky bit is necessary on /tmp? Why does /tmp have to be sticky? How can I set the sticky on that volume? TIA, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] Sticky bit on /tmp
David Guntner wrote: > > Tom Walsh grabbed a keyboard and wrote: > > > > I assume that the sticky bit is necessary on /tmp? Why does /tmp have > > to be sticky? How can I set the sticky on that volume? > > Not sure about the answer to your third question. In theory, once you've > set it, it should stay set - I don't know why it wouldn't still be set > after a reboot. But as to your first/second question, setting /tmp sticky > is really only important if you've got more than one user for your machine. > If you're the only one using it, it doesn't matter because you know if you > can trust yourself. :-) The sticky bit is important on a world-writable > directory when you've got multiple users for your machine, because with the > sticky bit set, only root and the user who created a file in that directory > can delete it. (Deletion is a function of directory permissions, not file > permissions.) Hi Dave, Yes, I kind of figured that out that the sticky would make it possible to only allow the user of an opened file to be seeing only their changes to the file, regardless if someone else attempts to change it. As to the sticky bit, I have evidence that the mode bits are stored someplace within the volume (superblock?). I had an experience when I made the /var directory too small on one installation and attempted to simply swap the mount points of the /tmp & /var partitions. The sticky bit showed up on the /var directory when I mounted the old /tmp partition to that new mounting point. It is somewhere in the filesystem that this attribute is specified and it would have to be mount that sees this mode bit. I have searched the /sbin, /usr/local/sbin and /usr/sbin directories and pulled up the manpages on the commands that I was not familiar with, but nothing I can find mentions any mount options embedded in the superblock. It looks like I will have to get the sources to the mount command and check in there, but, the kernel is also instrumental in mounting volumes. All that mount does is co-ordinate the mounting efforts of the kernal calls to sys_mount.. Regards, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
