Re: Mailutils+nullmailer: sender full name
Op 19-10-2023 om 21:50 schreef Greg Wooledge: Once the spam stops coming from your system, then you can try to get your IP address removed from all of the DNS spammer lists. Usually there's a web form you can fill out. Or the listing may expire after a while. I've seen many postings over the years from people trying to get their IP off of a blacklist. Their success was discouraging. (I suppose I don't know about people for which this was a seamless experience, as they would have no reason to post.) Kind regards, Gertjan.
Re: Mailutils+nullmailer: sender full name
Op 20-10-2023 om 05:10 schreef David Wright: On Thu 19 Oct 2023 at 13:30:53 (+0200), Gertjan Klein wrote: I don't intend to send mail from this machine myself, I want mail from the system (e.g. unattended-upgrades) delivered to my personal mailbox. I wouldn't expect /then/ to see my name, or likely anything at all from /etc/passwd. Rather, I would expect system programs to set their own From: address, either read from configuration file or hard-wired into the program itself I wouldn't expect my gklein changes to be used by system mails either. Just for fun, I did try to configure .mailrc for root, but that made no difference (at least for unattended-upgrades). But the default root@ address, with or without a name, is fine with me. I did have to add a root@ mail alias in my provider settings though, otherwise it rejects the system mail. It would be interesting to know whether the correct addresses were being generated by /system/ emails when you were still using mailutils; and whether they are, now that you're using bsd-mailx. II did not receive system emails when I was still using mailutils. I reconfigured unattended-upgrades to always send mail, and forced a run: $ sudo unattended-upgrade -d This gets me a mail with From being just "r...@parvos.nl". I don't really mind. Kind regards, Gertjan.
Re: Mailutils+nullmailer: sender full name
Op 19-10-2023 om 15:00 schreef Greg Wooledge: Traditional Unix terminal- or command-line-based MUAs inject new messages into the outgoing mail queue by piping them to /usr/sbin/sendmail. That means, as I believe Stefan pointed out, that they leave authorization to this single program, for all users of the system. For me personally that doesn't matter. But I wonder if this would nowadays be considered unsafe. I have, for now, configured nullmailer with my username and password at my provider (over TLS, of course). My provider's MTA (a receiving MTA then) therefore accepts mail from my VPS. As an alternative, I can use the mailing system of my VPS supplier. This requires me to add stuff to the DNS of my domain, stating that mailer can send mail on behalf of my domain. I believe nullmailer could then use that server without (other) authorization. I suppose that latter is more secure, as it doesn't require a configured password. But setting this up is considerably more difficult. Things get ridiculously complex in the real world. Yes. Wasn't IT supposed to make life simpler? ;) Kind regards, Gertjan.
Re: Mailutils+nullmailer: sender full name
Op 18-10-2023 om 18:30 schreef David Wright: On Tue 17 Oct 2023 at 19:41:43 (+0200), Gertjan Klein wrote: gklein@parvos:~$ cat /etc/passwd | grep gklein gklein:x:1000:1000:Gertjan Klein,,,:/home/gklein:/bin/bash On my (bullseye) system, that field is what is used to get my full name. It's what I'd expect to be used, unless configured otherwise. (Note that I don't personally send mail this way—I use mutt, of course.) I don't intend to send mail from this machine myself, I want mail from the system (e.g. unattended-upgrades) delivered to my personal mailbox. No, my system uses mailutils: As you may have seen in my response to Greg, replacing mailutils with bsd-mailx (and adding a configuration line) did solve the issue. I think this at least proves that nullmailer did not mess with the From header. I don't know why your mailutils works when mine doesn't. Perhaps a difference between the bookworm and bullseye versions, perhaps a configuration setting somewhere. I gave up; I've spent way more time on this than I should already. The mail will all be sent to me; it's ultimately irrelevant what name is in the header. It was just an itch. (I did learn a few things along the way, though, so it wasn't a waste of time!) I don't know much/anything about nullmailer, or why you chose it. (But then, the only reason I use exim4 is because I know how to # dpkg-reconfigure exim4-config it.) I used to use exim4, and I have instructions written down for configuring it. But exim4 is a full-fledged mail server, and I don't need that (or feel competent to maintain it), so I went looking for something more lightweight. Nullmailer seemed adequate for my needs. Thanks, kind regards, Gertjan.
Re: Mailutils+nullmailer: sender full name
Op 17-10-2023 om 23:20 schreef Greg Wooledge: On Tue, Oct 17, 2023 at 09:50:13PM +0200, Gertjan Klein wrote: I do appreciate it. If I switch to bsd-mailx I have something that should work. Although I'm concerned by the statement (on the Debian package page) that it doesn't speak SMTP. This is how I send the mail on to my internet provider with mailutils. I wouldn't know how else to do it. The way Unix mail works is by dividing the workload between an MUA and an MTA. The MUA (Mail User Agent) provides the user interface. It's the program you use to send and/or read mail. Examples include elm, pine, mutt, mailx, Thunderbird, and so on. The MTA (Mail Transport Agent) (or Transfer) is the back end. It's the part that does the actual deliveries, including sending and receiving messages over the Internet. [...] Thanks for this explanation. I should have realized this, but got confused by that above statement. If a MUA uses a MTA for transport, the MUA doesn't need to speak SMTP, I'd say, so why emphasize that it indeed doesn't? A command-line MUA like mailx sends mail to the MTA by invoking the /usr/sbin/sendmail (traditionally /usr/lib/sendmail) program, which is a hook provided by the MTA. I'm configuring bookworm; nullmailer on it provides both. So, it's not *expected* that your MUA will speak SMTP directly. That's not its job. Indeed. But: [...] This is different from when an MTA accepts a message directly from a MUA. That's usually called a "submission", and can use either SMTP or /usr/sbin/sendmail. So a submission from a MUA can use SMTP as well... The MTA could then be bypassed. I suppose e.g. Thunderbird would do this. So it does perhaps make sense that a MUA explains whether it needs a MTA. (More extensive explanation deleted -- thanks!) I skimmed parts of it. It appears to read ~/.mailrc if it exists. You could try putting commands in there and seeing what happens. The Debian package comes with an example configuration file, which I copied to .mailrc. I added the line you suggested; it made no difference. The configuration documentation (*), BTW, uses a completely different syntax, resembling JSON. I got fed up. I installed bsd-mailx and purged mailutils. That didn't work out of the box either. I don't understand why not, but there's a lot I don't understand. But the setting from your earlier message did the trick. Now the From header looks like I believe it should look by default, and I can move on to the next problem. Thanks again, kind regards, Gertjan. *) https://mailutils.org/manual/html_section/mail.html
Re: Mailutils+nullmailer: sender full name
Op 17-10-2023 om 20:40 schreef Greg Wooledge: On Tue, Oct 17, 2023 at 05:43:55PM +0200, Gertjan Klein wrote: While this is more an annoyance than a showstopper for me, I would like the From address to look like "My name ". Does anyone here know which program to persuade, and how to persuade it? You mean the "From:" header. This is provided by the MUA (Mail User Agent), which in your case is whatever program "mail" links to. Yes, I've drawn this conclusion from Geert's reply as well. On my system, mailx points to bsd-mailx: On Geert's as well. I wonder why. I installed nullmailer, and it automatically pulled in mailutils. I stayed with it because I don't know any better. You and Geert apparently decided on something different. May I ask why? The bsd-mailx(1) documentation is EXTREMELY confusing, and it took me 8 tries to get this, so I hope you appreciate it: I do appreciate it. If I switch to bsd-mailx I have something that should work. Although I'm concerned by the statement (on the Debian package page) that it doesn't speak SMTP. This is how I send the mail on to my internet provider with mailutils. I wouldn't know how else to do it. I've found the mailutils documentation impenetrable as well. More searching and trying ahead, I guess. Kind regards, Gertjan.
Re: Mailutils+nullmailer: sender full name
Op 17-10-2023 om 19:10 schreef Geert Stappers: On Tue, Oct 17, 2023 at 05:43:55PM +0200, Gertjan Klein wrote: I am configuring a new VPS, and decided to try nullmailer to send mail. I don't want to receive mail on the VPS, I just want the mail the system generates to end up in my mailbox elsewhere. This works, but the mail from address looks like this: "gklein ". This irks me. My account has my full name configured; Where exactly is the full name configured? I meant the user account on that machine: gklein@parvos:~$ cat /etc/passwd | grep gklein gklein:x:1000:1000:Gertjan Klein,,,:/home/gklein:/bin/bash |$ command -v mail |/usr/bin/mail |$ dpkg -S /usr/bin/mail |dpkg-query: no path found matching pattern /usr/bin/mail |$ ls -l /usr/bin/mail |lrwxrwxrwx 1 root root 22 Oct 12 2012 /usr/bin/mail -> /etc/alternatives/mail |$ ls -l /etc/alternatives/mail |lrwxrwxrwx 1 root root 18 Oct 12 2012 /etc/alternatives/mail -> /usr/bin/bsd-mailx |$ ls -l /usr/bin/bsd-mailx |-rwxr-xr-x 1 root root 112968 Apr 14 2022 /usr/bin/bsd-mailx |$ dpkg -S /usr/bin/bsd-mailx |bsd-mailx: /usr/bin/bsd-mailx |$ Did it help? That shows that your mail executable is actually bsd-mailx. If you also use nullmailer, that means mailutils is the culprit here: gklein@parvos:~$ command -v mail /usr/bin/mail gklein@parvos:~$ ls -l /usr/bin/mail lrwxrwxrwx 1 root root 22 Mar 3 2023 /usr/bin/mail -> /etc/alternatives/mail gklein@parvos:~$ ls -l /etc/alternatives/mail lrwxrwxrwx 1 root root 23 Mar 3 2023 /etc/alternatives/mail -> /usr/bin/mail.mailutils My mail is from package mailutils, as described, and it doesn't (by default) appear to use the full name from /etc/passwd. I had expected this to 'just work', seeing as "Mailutils is a swiss army knife of electronic mail handling". I can, of course, switch to a different MTA. But it's difficult for me to believe this can't be done with this 'Swiss army knife'. Kind regards, Gertjan.
Mailutils+nullmailer: sender full name
I am configuring a new VPS, and decided to try nullmailer to send mail. I don't want to receive mail on the VPS, I just want the mail the system generates to end up in my mailbox elsewhere. This works, but the mail from address looks like this: "gklein ". This irks me. My account has my full name configured; why isn't it used? I am testing this as follows: $ echo "this is a test" | mail -s Subject gkl...@parvos.nl I am unclear about which of GNU mailutils or nullmailer is responsible for this header. I've tried various things the internet suggested; none made any difference at all. While this is more an annoyance than a showstopper for me, I would like the From address to look like "My name ". Does anyone here know which program to persuade, and how to persuade it? Kind regards, Gertjan.
Re: Is this smart HD partitioning?
On Wed, 25 Aug 1999 20:42:57 +0800, Hans van den Boogert <[EMAIL PROTECTED]> wrote: >Now I find that the hard drive is constantly "accessed and reset." I mean >that it seems the disk is being accessed for a second, then goes back to >inactivity with an almost crackling noise. This most likely is the harddisk recalibrating itself. Some HD's do that more often than others, and especially laptop HD's appear to exhibit this annoying behaviour. I have two harddisks for my laptop, an IBM and a Toshiba, and both do this (the Toshiba the worst). Gertjan.
Re: how to format mySeagate ST33210A
On Fri, 20 Aug 1999 08:12:07 -0400, Ralph Winslow <[EMAIL PROTECTED]> wrote: >doesn't detect it, either. I also notice that the HDD light on my >generic (Kenitec) case stays constantly lit when the new drive is >installed. I don't know what to do about it, though. There's not much point in trying to install Linux to a drive that isn't recognised by the BIOS, you'd better get that sorted first. The HD light being on constantly could indicate a faulty drive or the cable being connected the wrong way around. As someone else already mentioned, setting the drive to slave mode when there is no master may also give problems; try setting it to master or (if present) single mode (in which case, when it works, it will have to be accessed as /dev/hdc). Gertjan.
Re: Save me: LILO!
On Sun, 15 Aug 1999 18:22:57 +0200, Dennis Schoen <[EMAIL PROTECTED]> wrote: >You could also try "fdisk /mbr" on windows, its not documented but >sometimes it can restore your old mbr Actually, what this does is rewrite the standard MS-DOS MBR software to the MBR (without altering the partition table). It does not help restoring LILO. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: [Debian: Install] Harddisk partitioning
On Fri, 13 Aug 1999 13:23:27 +0100, Michelle Konzack <[EMAIL PROTECTED]> wrote: [...] >Now I like to install Debian 2.1 on it but I do not know, >in which partitions. > >My problem is, that I do not know the size of the root and use prtition, >because I need to install many source for compiling and Software development. > >Where must I put all the source codes ??? >In the root partition or usr partition ??? [...] This will probably attract a few flames, but if you are running anything but a heavy-load server, I'd suggest putting _everything_ on one partition. This will solve all problems like this (on which partition should I put xxx), and has the added advantage that you have less "slack" (the extra space you allocate to each partition so it doesn't run out if you add an extra file to it). (If resizing ext2 partitions was easy and reliable this could be different, of course, but I don't know of any program that does this.) Meanwhile, I think the most logical place to put your personal source code would be /usr/local/src/. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Restore disk
I have bought a new harddisk for my laptop and want to transfer Debian (2.1) from the current to the new harddisk. As this is a laptop I can't connect both drives at the same time, so I created a .tar.gz file that I stored on a different computer on the network. In order to extract this file to the new harddisk, I need to boot Linux and have available tar, gzip, and network connectivity. An extra complication is that I have a PCMCIA network card, so I need everything related to that as well. How can I go about this? I've tried to create a boot/root disk combination using yard, but I can't get everything I need on 1.44 MB, and formatted to larger size the floppies become unbootable. The debian (2.0) boot disk (or rather, bootable CDROM) I have doesn't seem to have PCMCIA or tar on it. I have a parallel port zip drive if that helps, but I don't know how to boot from it. TIA, Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Memory Recognition Problem
On Fri, 9 Jul 1999 18:59:52 -0400, "Jonathan D. Proulx" <[EMAIL PROTECTED]> wrote: >The bios reports 3716k RAM with >1M memory checking enabled >there's 4 30pin simms installed. > >Linux sees 1936k available (free and top). > >Anyone know what can be causing this? The memory reported does not include the memory occupied by the kernel. I had similar readings on a similar machine, and it was practically unusable. I'd advise you to compile a custom kernel (on a different machine!) with only what you need in it, and of that the stuff you don't need all the time moved to modules. Dpkg makes it easy to make a debian package of the custom kernel and modules, to install on the low-mem machine. My 4M 386 now has 3260K available memory, and functions without problems as an IP-masqerading host. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Autofs for root only??
On Fri, 25 Jun 1999 19:54:22 -0500 (EST), Brian Servis <[EMAIL PROTECTED]> wrote: >You don't need to do it everytime, just once. The mounted disk keeps >the permisions you set for it. Example with a ext2 floppy: [Sound of coin dropping] Ah, now I see! The permissions are saved somewhere on the filesystem itself. Yes, this worked - thanks very much! On with the next problem (Samba - I'll struggle with the documentation some more before bothering the list with it ;-) Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Autofs for root only??
On Fri, 25 Jun 1999 16:47:29 -0400 (EDT), William T Wilson
<[EMAIL PROTECTED]> wrote:
>If you want to change the permissions of the volume's / directory, change
>them with chmod once it's mounted.
Under normal circumstances that would merely be an annoying
inconvenience, but since the filesystem is supposed to be automounted I
don't see how I should do that. How do people normally do this? A lot
of people use extensive partitioning and mount the partitions
automatically (from /etc/fstab). Does everyone chmod the permissions
afterwards? Is it unreasonable to want an extra filesystem automounted
owned by root:disk, so certain users can access it? ("Certain users" in
this case merely means me, as this is for my home system, but I don't
want to have to be root all the time in order to access the partition.)
TIA,
Gertjan.
--
Gertjan Klein <[EMAIL PROTECTED]>
The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Autofs for root only??
On Wed, 23 Jun 1999 16:14:04 -0500 (EST), Brian Servis <[EMAIL PROTECTED]> wrote: >mount -t ext2 /dev/hda6 /test -o suid,gid=,umask=002 Unfortunately, the filesystem ext2 recognises neither the gid= nor the umask= options, and refuses to mount! I can find no similar options for ext2. I really don't understand why mount removes the permissions I set on the directory I want to mount on. What else could I do? TIA, Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Autofs for root only??
I am trying to convince autofs to allow others than root to access the automounted filesystems, and I'm failing miserably. I can find no information on this subject in the man pages. It appears the problem is not directly related to autofs, though, because I fail with standard mount as well. Here is what I did to test: asterix:/# mkdir test asterix:/# chown root:disk test asterix:/# dir test drwxrwxr-x 2 root disk 1024 Jun 23 21:56 test asterix:/# mount -t ext2 /dev/hda6 /test -o user,suid,exec asterix:/# dir test drwxr-xr-x 3 root root 1024 Jun 22 19:31 test asterix:/# dir /dev/hda6 brw-rw 1 root disk 3, 6 Jul 21 1998 For some reason, the mount command changes the permissions of /test right back to what they were. If I log in as a user and try to access (write to) the mounted filesystem I'm denied access. The same happens with autofs mounted filesystems. What can I do to fix this? TIA, Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: lilo and win98
On Tue, 22 Jun 1999 13:29:53 -0500 (CDT), Brad <[EMAIL PROTECTED]> wrote: >Ah, when you said "File System is 32-bit" i thought you meant just that, >and not the filesystem io. Ah, but this isn't about what _I_ mean, but what terminology W9x uses... >Checking, the io is indeed 32 bit. Also, as a further test i created a FAT >partition on hda3 (windows is on hdb1 and hdb5). Drive C was still hdb1, >but drive D became hda3 and drive E was hdb5. The way W9x assigns drive letters to partitions is, as far as I know, unchanged from how DOS used to do it (although I don't know how the new partition types fit into the picture). These rules are a bit complicated, and can be found in the Boot Control documentation if anyone is interested (see my .sig). It is interesting to see, though, that apparently W98 recognises drive swapping and implements it in it's own driver. I'll have to do some experiments with this as soon as I've got sufficient hardware for testing. (Currently my only PC with two HDs is a 386 with 4 MB, and I'm not even going to try installing W98 to that; it is running Debian, functioning as an IP masquerading Internet gateway for my local network, without any problems. Beat that, W9x or NT!) Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Kernel Compiling Problem
On Tue, 22 Jun 1999 14:52:18 -0500 (CDT), Brad <[EMAIL PROTECTED]> wrote: >Have you tried running "make-kpkg clean" or removing the stamp-configure >file? The problem you describe sounds exactly like the problem solved by >these two solutions, as given in the make-kpkg manpage. ... which makes me wonder if perhaps a bug report should be filed against make-kpkg. This issue comes up here so often, and this behaviour is so counter-intuitive... Even if there is a reasonable explanation for make-kpkg ignoring the --revision option (I can't think of one, really), it should probably do so with loud noises, bells, and messages that _don't_ scroll out of view before you've got a chance to read them (or Control-C out of the whole thing to do a clean first). Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: lilo and win98
On Mon, 21 Jun 1999 14:28:54 -0500 (CDT), Brad <[EMAIL PROTECTED]> wrote: >On Mon, 21 Jun 1999, Gertjan Klein wrote: > >> Interesting to see that this works for W9x. Just out of curiousity: if >> you go to Control Panel -> System and press the device tab, does it say >> the File System is 32-bit? > >i haven't explicitly checked, but logically it must. Before i installed >Linux the filesystem was FAT32 and i did no reformatting of the windows >partition. If it were not reading a FAT32 filesystem, windows wouldn't >even boot because it could not possibly find any file correctly. Would you mind checking? The information on that tab doesn't actually apply to the filesystem itself, but to the disk I/O driver. W9x says the filesystem is 32 bit if it has completely replaced the BIOS disk drivers with its own, protected mode (32-bit) drivers. Reasons for not doing so include the presence of older, 16-bit drivers in config.sys. W9x does some tests when booting: it reads a couple of sectors through BIOS, and then the same sectors by directly accessing the harddisk. If it encounters differences, (i.e., doesn't get the same sectors back from both reads), it will keep on using the BIOS routines for disk I/O. There are two reasons why W9x could support the drive swapping that LILO does on your system. It could recognise the actual swapping for what it is and implement it in it's own (32-bit) driver. Alternatively, it could see that something is messing with the drive mapping and leave it alone; it would keep on using the BIOS for disk I/O. In the latter case, it would report the filesystem as 16-bit. I'm just curious what it does. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: lilo and win98
On Mon, 21 Jun 1999 17:39:56 +0200, "Sander Balkenende" <[EMAIL PROTECTED]> wrote: >I resolved the problem of booting Linux by making my win98 drive hda again >and reinstalled Debian on hdb (at the moment, I am just experimenting with >Linux). This works fine, I have to fine-tune loadlin, but that works. >When trying to load loadlin from config.sys with the [menu] command, it >works the first time, but after that, windoze has rewritten the config.sys >and erased the line that loads linux.bat (which activates loadlin). Has >anyone experiences with that? Weird. You may want to try installing LILO in the MBR of the first harddisk, so you can choose before W98 even start and won't need loadlin. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: lilo and win98
On 20 Jun 1999 23:43:06 +0200, Rui Zhu <[EMAIL PROTECTED]> wrote: >other=/dev/hdb1 >label=win >map-drive=0x80 > to=0x81 >map-drive=0x81 > to=0x80 Interesting to see that this works for W9x. Just out of curiousity: if you go to Control Panel -> System and press the device tab, does it say the File System is 32-bit? Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: lilo and win98
On Sat, 19 Jun 1999 21:23:38 -0230, Greg Starkes <[EMAIL PROTECTED]> wrote: >I believe that Windows 98 (like DOS and Windows95) must be on the first >partition of the first hard drive. There is no requirement that W98 be on the first partition, but none of DOS/W95/W98 directly support being booted from a second harddisk. I've got it to work for DOS once, but it required patching the DOS partition bootsector, and I don't know how to do that for W9x (the bootsector is different). Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Two installations on the same system
On Wed, 16 Jun 1999 12:52:31 +0930, John Pearson <[EMAIL PROTECTED]> wrote: >The disadvantage to this is that *both* /dev/hda1 and /dev/hda2 have to fall >within the first 1024 cylinders cylinders for this to work. With the BIOS harddisk mode set to LBA this shouldn't be a problem, as the harddisk won't _have_ cylinders over 1024 then. (An exception is harddisks over 8 GB.) Nevertheless, your suggestion works just as well. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Two installations on the same system
On Mon, 14 Jun 1999 21:59:30 +0200 (CEST), Bruno Goncalves Russo <[EMAIL PROTECTED]> wrote: [Two Linux partitions] >This is exactly what I want to do. I just tried to do it, but wasn't >totally successful because I didn't configure lilo correctly. >I was using the unstable version and when I tried to switch back to >stable, lilo loaded the incorrect kernel and some things didn't work >because of that. How should I configure it in this case? It's advisable to set up LILO on both partitions. Use the LILO on the stable partition (I'm assuming /dev/hda1) for the boot menu. E.g.: boot=/dev/hda root=/dev/hda1 delay=50 image=/vmlinuz label=Stable read-only other=/dev/hda2 label=Unstable (Note: this probably isn't a full working configuration, this is just to give you an idea.) Then, in the unstable Debian (I'm assuming /dev/hda2), configure LILO to boot from the bootsector of it's own partition: boot=/dev/hda2 root=/dev/hda2 delay=0 image=/vmlinuz label=Stable read-only The advantage of this setup is that if you recompile your kernel on your unstable partition, all you have to do is rerun LILO (which make-kpkg will do for you) to keep things working (the same goes for the stable partition, of course). HTH, Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: BE MORE SIMPLE!!!!
On Mon, 14 Jun 1999 09:54:01 -0500, "Keith G. Murphy" <[EMAIL PROTECTED]> wrote: >I would add that GUI does not equate to ease-of-use. Look at the >oft-derided dselect: it's actually quite a good wizard (takes you >through everything you need to do step by step). The bad parts of it >are probably the slowness and (moreso) the unconventional keystroke >bindings. I agree that GUI does not automatically mean ease of use. In general, though, when configuring an application, clicking a checkbox is a lot easier than reading through an outdated manpage or (horror!) using info to find out the exact syntax of a specific configuration file line. When installing a Linux distribution there are so many applications to be configured, so many man pages to be read, that a new user can easily and justifiably feel intimidated. I've played with Linux (mostly Debian) for a couple of years now, and still find myself putting things off because it's so much work and so much reading. Whatever you think of W95, it has a lot less of these problems. Dselect is IMHO not a very good example of a good interface, because it is difficult to understand. I _still_ get confused when to use the Enter key and when to use the space bar, for example. I also find the separation in categories like misc, optional, non-free etc. completely arbitrary to me. I'd like to see all the networking-related packages together; if you can configure dselect to do that, I haven't found how. Of course, it is no longer practical to use dselect anyway, not with the huge amount of packages Debian comes with nowadays... I think an interface comparable with W95 explorer would work well for package selection, although this is hard to implement in text mode. >"The people who manage the creation of software-based products are >typically > either hostage to programmers because they are insufficiently >technical, or they are >all too sympathetic to programmers because they are programmers >themselves." That is one of the main points of the entire book: that programmers are the ones that design the user interface of programs. Programmers have a very different view of computing that arbitrary users. They subconsciously tend to assume that users of their programs have the same view as they themselves have. I hear that attitude in the oft-heard phrase "teach a man to fish...". Though true in itself, many people are either not interested in or don't have the capacity to configure large, complicated applications; they just want to type their letters, and do the other stuff their bosses tell them to do. Cooper points out that the interaction design should be geared towards the people actually using the program, instead of the people that program it. Self-evident as this may seem, it appears that this is hardly ever the case. >Personally, I think that explains a lot of "Y2K": A .sig I read somewhere: "Trust programmers to abbreviate the year-2000 problem to Y2K. It is this attitude that got us into this mess in the first place!" ;-) Gertjan (programmer, in case anyone was wondering ;-) -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: IP Masquerading
On Mon, 14 Jun 1999 07:47:36 +0100, [EMAIL PROTECTED] wrote: >Is there any Debian specific documentation on IP Masquerading? I've read >the mini how-to, but debian seems to have this extra /etc/ipmasq.conf file >so I'm looking foe the correct way to configure debian IP Masquerading >before I start asking any stupid questions. If there isn't any should we >consider writing some? I got it working solely with the mini-howto, and I don't have that file on my system... Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: BE MORE SIMPLE!!!!
On Sat, 12 Jun 1999 21:04:56 +0930 (CST), Michael Talbot-Wilson <[EMAIL PROTECTED]> wrote: A few phrases of your mail: "Contemptible complaints and demands", "self-important and self-serving claim", "laughable", "a shithead", "completely bogus", "intolerant and demanding", "a lame and inefficient user". I don't think this was justified, and I don't want to be dragged into a flame war, so I won't respond other than saying that my mail, although bearing critisism, was intended constructive, while yours obviously was intended demeaning. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: BE MORE SIMPLE!!!!
On Fri, 11 Jun 1999 23:25:14 -0400, "Kristopher Johnson" <[EMAIL PROTECTED]> wrote: >My reaction was to >the people who are glad that Linux isn't too easy, because they enjoy the >challenge. Adversity builds character, I guess. Well said. In addition, the reverse also seems to apply; point-and-click interfaces suck, because they are too easy. Windows could learn a lot from Linux in terms of performance, power and stability, but Linux doesn't even come close to the ease of installation and use you'll find with Windows. This is not something to be proud of, or something to blame on (new) users. It would be nice if the people you mention above realize that the vast majority of computer users in general are absolutely not interested in learning about operating systems, file systems, the files in /etc, and so on - they just want to get a job done, as quickly and easily as possible. There is absolutley nothing wrong with that. >If you like to do things the hard way, then fine. But it doesn't really >mean that you're more intelligent or more knowledgeable than people who >click a few buttons in a GUI to accomplish the same thing. Even if it did mean that, so what? Alan Cooper has written an interesting book about user interface design (he prefers to call it interaction design). It addresses a lot of the issues that users have to deal with when operating high-tech equipment like computers; these issues are universal, and apply to interacting with Linux as well. A sample chapter is available online at amazon: http://www.amazon.com/exec/obidos/ts/book-excerpt/0672316498/vbtechniques/002-1455712-0642063 It is a really interesting read; it wouldn't hurt if the die-hards read it ;-) Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: WinNT boot code
On Fri, 11 Jun 1999 14:52:07 -0600, "Omniflux" <[EMAIL PROTECTED]> wrote: >"Invalid Partition Table" Turns out, the WinNT boot code halts if you have >more then one partition marked "active", which I now had. Unmarking the >partition solved the problem. I was just thinking it might be nice to put >in a check for Microsoft boot code and warn you about that when you try to >mark a second partition active, at least during the initial installation. Actually, in this case WinNT is completely right, and if the debian code marks a partition active without clearing the mark on the others, it is broken. At most one partition should be marked active; the active flag signals the MBR code to boot this partition, and you can't boot more than one partition at the same time. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Random partitioning questions
On Tue, 8 Jun 1999 10:06:33 -0500 (CDT), Brad <[EMAIL PROTECTED]> wrote: >On Tue, 8 Jun 1999, Gertjan Klein wrote: > >> The only thing that needs to be below the 1024th cylinder is the >> kernel (vmlinuz) and LILO's second stage boot loader > >Yes, but the kernel needs to be able to access mount in /bin, init in >/sbin, the libraries in /lib to run those two, and the config files >(init.d/, fstab, etc) /etc, and /dev to find the extra partitions to >mount. The kernel can access all these files even if they are above the 1024 cylinder limit. I'm not suggesting you shouldn't put them together; I merely pointed out the strictly technical requirements. >The problem with the partition spanning the 1024th cyl, what if installing >a new kernel chooses a part of the partition above the limit? Therefore, >it seems safest to keep the entire partition under the line. True. Like I said, LBA mode is one way to achieve that; partitioning is an equally valid one. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: How do I access dos partitions?
On Sat, 5 Jun 1999 22:01:44 -0400, "hammy" <[EMAIL PROTECTED]> wrote: >Also, is there any program that will let me choose which operating system to >boot up with? Several boot managers exist that you could try; Linux comes with LILO. For some alternatives look at: http://www.linuxapps.com/browse.html?category=util-boot Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Recovering the original boot sector
On Sun, 06 Jun 1999 02:03:40 +0200, "Jean-Yves F. Barbier" <[EMAIL PROTECTED]> wrote: >They're (unfortunately) right, MacroSOB products don't care about other OS; >making 'fdisk /MBR' will bring you back to the beginning... winbrock only... You are not doing Linux or yourself any favors by displaying your ignorance about other operating systems. More importantly, you are doing the poster of the question you responded to a serious disservice. See my reply to his question for a more accurate answer. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Recovering the original boot sector
On Sat, 5 Jun 1999 18:53:38 -0500 (CDT), Jor-el <[EMAIL PROTECTED]> wrote: > When I purchased my PC, it came with Win95 preloaded. After >installing linux on it, lilo did back up the original bootsector and >stored it in /boot, but over the past two years, and after a couple of >Linux reinstalls, I lost the original bootsector (blush). Now, I am >planning to reorganize my Win95 partition again, and I need to recover the >original bootsector. From your description I take it that when you say bootsector you actually mean master boot record. They are not the same. The master boot record is the very first sector of the harddisk, containing the partition table; a bootsector is the very first sector of a partition, (possibly) containing the partition boot code. What reorganization do you plan for your W95 partition, and why would you want to recover the original MBR for it? The partition table is not altered by LILO, and that's the only thing W95 cares about. LILO doesn't change the W95 bootsector. > They did say that 'fdisk /MBR' would recreate the original >bootsector. So here is what I propose to do : The (undocumented) MS-DOS command "fdisk /mbr" restores the original MS-DOS MBR software, but leaves the partition table as it is. Effectively, it gets rid of LILO. Is this what you want? If so, you may also want to use (DOS or Linux) fdisk to set the active flag to the partition you want to boot. >1. Take backups of th existing bootsector. Create Linux bootdisk. Both are always a wise thing to do. >2. Run 'fdisk /MBR' from within Win95. This should wipe out my existing >partition table in the MBR (first 512 bytes). Your partition table will not be altered, just the MBR software (wiping out LILO instead). >3. Reboot using my Linux boot disk. Now create a copy of the old (backed >up) bootsector (file A). >4. do 'dd if=/dev/hda of=/boot/B bs=446 count=1' >5. do 'dd if=/boot/B of=/boot/A bs=446 count=1' All this is redundant, and probably doesn't do what you think it does anyway. HTH, Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Low memory installation
I have a 386/4M that I want to install Debian on. I have copied all the required boot files (directory disks-i386) to the 386 through a parallel cable. When booting (using the standard install.bat) the process stops with the message "invalid compressed format (err=1)". As I've used this image to install Debian on another PC, I assume this problem is caused by too little memory. The documentation gives instructions for low memory installs, but unfortunately they require a floppy drive which this machine doesn't have. Is there any way I can install Debian on this machine? It has plenty of disk space I could use for virtual memory, if only it booted into Linux... TIA, Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Partitioning
[EMAIL PROTECTED] wrote: > It seems that NT probably does the same thing - if you happen to have an > OS/2 HPFS partition (id #9), then NT thinks it is an NTFS partition(id #9). > If you are unlucky, then this partition will be in such a place that it is > assigned drive letter C. NT will then get confused as it can't actually > understand what's on C: God, I *love* mount points - and I *loathe*, > *hate*, *despise* drive letters :-) Now, now ;-) Drive letters aren't _that_ bad - MS and IBM just managed to screw up majorly by using the same partition ID for their filesystems. Actually, before DOS 6, MS supported the subst, join and assign utilities that allowed things similar to mount points (although _still_ not as powerful). For reasons unknown to me they removed support for join and assign in DOS 6 and above, leaving only subst supported. I still use that one heavily, though. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Partitioning
[EMAIL PROTECTED] wrote: > Fdisk does the partition table only, use lilo for the MBR. The partition table is part of (contained in) the MBR. Assuming you refer to the MBR _software_: if fdisk doesn't find a boot sector signature in the MBR, it _will_ install it's own software to the MBR. If the signature is present, it will leave the software alone and just update the partition table. This sounds like perfectly reasonable behaviour to me. The (unfortunately undocumented) switch '/mbr' makes fdisk overwrite the MBR software regardless of the presence of a signature. Gertjan. --- -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Partitioning
Chuma Agbodike <[EMAIL PROTECTED]> wrote: > One thing still puzzles me that I hope you can clear up for me. > Supposing I buy a brand new hard disk. IDE, SCSI or whatever. > To use it, I have to partition it, using a utility like FDISK . > FDISK writes the MBR and Partition Table. Right ? Yes. (The MBR contains the partition table). > If I go and start copying files to any of the partitions, the data can't > be read. Because I have to format or initialize the partition before > writing to it . Right ? Yes. The partition table points to the location on disk where the partition starts, and also holds it's size and type - but what's actually on the partition is of no concern to fdisk. > So how come the system can write/read the MBR and partition table ??? The system can read/write the partition too - it just can't access a file system on the partition, because there isn't one yet. When you "format or initialize" the partition, you are actually putting a file system on it. For DOS that means creating and writing the boot sector, placing two empty FATs, an empty root directory - all the bookkeeping stuff that DOS needs. (Don't be fooled by DOS format "formatting" the whole partition - writing the filesystem only takes a second. The rest is verifying if it can actually access all sectors, i.e. checking for bad blocks). For Linux (or any other OS) it is basically the same: before the system can actually use a partition, a filesystem must be created with e.g. mke2fs. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Partitioning
[EMAIL PROTECTED] (Robert D. Hilliard) wrote: > An interesting anomaly is that the DOS command "fdisk /status" > will (sometimes?) show Linux partitions with DOS drive letters. These > do not show when fdisk is run for the specific partition however. It must be sometimes then, because it doesn't do that here. I'll try to run that command more often, on more machines, to see if I can duplicate that. I've often heard people complaining about fdisk, but I've never actually encountered one myself. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Partitioning
"Adam Heath" <[EMAIL PROTECTED]> wrote: [Snip requirements of W95 to boot from a partition] > Not true. Look below. All cut and pasted from Win95. [Snip partition setup] I gave the short version of the requirements, which I expected to satisfy most readers ;-) I must admit I never thought of using an _extended_ partition MBR to get to LILO, though. To give the more precise list of requirements (that also explains why your setup works): DOS (and W95) require to be booted from drive C: (ignoring floppies again). During booting, at some stage before processing config.sys, it switches from loading files from the actual boot drive to loading them from drive C:. If these are not the same, weird things can happen (processing of config.sys of another partition, or refusing to load command.com because it has the wrong version number). The way DOS assigns drive letters is this: * All non-DOS partitions are completely ignored. This includes OS/2's hidden DOS partitions. * Each _active_ primary DOS partition on each subsequent drive is assigned the next drive letter, even if it is not the first primary DOS partition. If a drive has no active (DOS) partition, its _first_ primary DOS partition is assigned a drive letter. If no primary DOS partition exists on the drive, no drive letter is assigned in this stage. * All _extended_ partitions on all subsequent drives are assigned drive letters in turn. * Lastly, all remaining primary partitions on all subsequent drives are assigned drive letters in turn. As can be seen from this, if the active flag is _not_ set on the first harddisk (or if it is set to something DOS doesn't recognise as a valid boot partition, like the extended partition MBR), the _first_ primary partition will be called C: and can be booted from. This explains why your setup works. Another consequence is that if there are no primary DOS partitions on the first drive (e.g. because a boot manager hid them), DOS should be able to boot from the second drive, since the first (or active) DOS partition on that drive would be called C:. Note the ``should'': format.com and sys.com set the boot drive number in the bootsector incorrectly, so it needs a small patch to get this working. Also note that the W95 installation program can't handle this. (If you really need W95 on HD2, make the second HD the first one, install W95, make it the second one again and patch the bootsector (change the byte at offset 0x24 to <0x80 + zero-based drv number>, e.g. 0x81 for the second harddisk). Then use LILO or another boot manager to boot it, and don't do it through the MBR of the second HD (as the default DOS MBR software can only boot partitions on the first drive). I have done this, and it works.) Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Partitioning
[EMAIL PROTECTED] wrote: > Is it possible to boot 95 from a logical partition? On a seperate note, is > it possible to *install* (from CD) 95 onto a logical HD. To my knowledge, no - but I've never actually tried it. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Partitioning
[EMAIL PROTECTED] wrote: >> - BIOS imposes the current partitioning scheme opon us, and limits the >> number of primary partitions to four (not true - BIOS knows nothing >> about partitions and doesn't care either). > It does have the "1024 cylinders" problem though. Only because of backwards compatibility. Two ways to deal with the problem exist on modern BIOSes: - CHS translation, effectively moving the limit from 504 MB to about 2 GB, without losing compatibility with DOS. - A new BIOS interface, moving the limit to about 2 TB, losing compatibility with DOS. Take your pick. What many people seem to be confused about is that many, if not most, decisions concerning this stuff are driven by market forces requiring backward compatibility. Let me state _again_ that the BIOS is nothing but a piece of software in a PROM - it can easily be altered should the market so request. The design of the PC is flexible enough here. > As I understand it, (at least with DOS/windows/OS2), you can only "see" one > primary partition _per disk_. This was also what various HOWTO's seemed to > say. No, no, NO! How many times do I have to say this: I HAVE MULTIPLE PRIMARY DOS PARTITIONS, AND BOTH DOS AND WINDOWS '95 SEE ALL OF THEM! What does it take to convince you that I'm not lying?! Do I need to mail an output of DOS fdisk perhaps? Or would you then think I forged that?The only problem with multiple primary DOS partitions that both DOS and W95 have, is that their fdisk refuses to create more than one. For a workaround, and more details, see the docs of my boot manager (see sig). Once created, they are seen and accesible. > The fact that windows (95 and NT) cannot use partitions properly - they > *require* that they are on the first primary partition on a disk - means > that partitioning is _alot_ of hard work (trust me - I've spent a week > reinstalling things and messing around). I doubt if you've spend as much time partitioning as I have developing my boot manager ;-) I have very little experience with NT, but I know for a fact that Windows '95 does _not_ require to be installed to the first primary partition of a harddisk - on my harddisk, it is installed on the fourth. The requirements are: - It must be installed on the first harddisk. This requirement goes for both DOS and W95; for DOS 6.22 and 7.0 (the DOS part of W95) there is a workaround if there are no primary DOS partitions on the first harddisk. - The active flag must be set to the booted partition. If W95 is booted from the fourth partition, but the active flag is set to the first, it will hang. > One feature I look for in a design is easy modification in the future > (which is normally always needed for one reason or another). The PC having come this far, I'd say it apparently was modifyable enough to give us Pentium PCs without losing the ability to run DOS. Your list of things you object to is not exhaustive, and some of it I agree with; I am not defending everything to do with PCs, I just hate to see misinformation - especially on a list otherwise so helpful and accurate. > - allowing spaces in filename - *completely* *braindead* kilu:~$ > "Filename with spaces" kilu:~$ ls Filename with spaces I assume you are now going to tell me that the Linux "design" is completely braindead too? Or perhaps different rules apply to operating systems you like than to operating systems you don't like? Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian/WindowsNT partitioning
Bill Leach <[EMAIL PROTECTED]> wrote: > Because of what you say, I feel as though > it borders on "FM" but possibly it has something to do with the BIOS of > the particular machines where this has workded? "FM"? Fdisk uses standard BIOS calls to access the harddisk, so it's unlikely this has something to do with the BIOS. I don't know what could be the cause, though. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Partitioning
Bill Leach <[EMAIL PROTECTED]> wrote: > On Wed, 10 Dec 1997, Gertjan Klein wrote: > Obviously > these are judgement calls and opinions but when the original hard disk code > was written decisions were made concerning such things as sizes for device > storage parameters. While what you have said about the cost of 10Meg HDs > and the like is true, that fact did not seem to influence others in such a > limiting way about how to deal with the matter. More importantly, I > think, is that it has taken many years to finally to address this issue. The original harddisk code was written for (relatively) cheap hardware. SCSI harddisks, using block addressing, were of course around, but much more expensive. Nevertheless, even though the partition table entries specify the location of partitions in cylinder, head, and sector parameters, they _also_ specify them in logical block numbers. Using these numbers a harddisk of 2 TB (2048 GB) can be described. Note, again, that the partition table layout has nothing to do with the BIOS. The BIOS provided an interface for cheap hardware; if demand would have been higher for better quality hardware, like built-in support for SCSI drives, it would have been there. Nothing in the PC design prevents this - in fact, my BIOS directly supports (NCR) SCSI controllers. On top of that, the PC design allows for _really_ non standard (for PC's, anyway) hardware to have it's own BIOS to take over the standard BIOS calls. >> I'm not exactly sure what you think is the nightmare part of the >> original design (and frankly, I don't care). There are a ... > And if you don't care then we are probably both wasting our time. No - because I am not trying to change your _opinion_ on PC hardware, I am just trying to stop you from spreading misinformation about it. I realize very well that a lot of compromises have been made with PC design over the years, there is enough to complain about - so if you want to do that, go ahead, but get your facts straight. >> * There is a limited number of primary partitions available in the MBR. >> This limitation is no serious problem, as many modern OSes don't object >> to being installed in an extended partition (of which there can be as >> many as required). > Yes, many often incompatible workarounds exist. What do you mean with "incompatible workarounds"? What's incompatible about booting from an extended partition? > No there is nothing brain dead about partitioning a drive and I see no way > that anyone could conclude from anything that I have said that I think > otherwise. It is the arbitrary decision to create the "tiered" partition > types (primary, extended, and logical) abstraction that I object to. Since the partition table resides in the MBR, with limited space, _some_ limit had to be set to the number of entries in the table. Four, at the time, was a reasonable limit. When the limit became - well, limiting, MS introduced extended partitions - which is nothing other than a way to arbitrarily expand the partition table. It seems like a reasonable solution to me. > These "modern BIOSes" have finally caught up with BIOSes of more than > twenty years ago. Are you suggesting that had different decisions > concerning how to deal compatibly with the various limitation that were > arbitrarily built into the original design had been handled differently > that the PC would not be as popular or have such a favorable > performance/price ratio as it currently has? Yes. (I don't want to get into this, though, because there is no way to prove one way or the other). > I have "lost it". In as much as I really do not wish to mislead anyone > then by "misinformation" are you talking about my assertions with respect > to the BIOS design (and indeed design evolution) upon the overall > filesystem design, or rather my (admitted) failure to even mention that > there are new BIOS designs that do not themselves impose this scheme, or > both? Your misinformation was that: - BIOS imposes the current partitioning scheme opon us, and limits the number of primary partitions to four (not true - BIOS knows nothing about partitions and doesn't care either). - DOS, Windows and OS/2 don't see other primary partitions than the one they booted from (not true - DOS and Windows see other primary DOS partitions just fine, and OS/2 won't even boot when they are present and not "hidden"). - fdisk /mbr will wipe out everything on the drive (wrong - it just replaces (or installs) the MBR software without touching the partition table). - (A point I hadn't addressed yet:) loadlin uses BIOS calls for drive access (wrong - it uses DOS calls, which can, but don't have to, tra
Re: Problem installing Debian 1.3
<[EMAIL PROTECTED]> wrote: > Thanks, the thought here is that if a partition is a primary Linux > partition rather than a Linux partition sitting in a DOS extended > partition, perhaps a virus looking for DOS partitions will leave the LINUX > partitions alone. Whereas, viruses would recognise the extended partition > as a DOS partition and reek havoc on the DOS, thus trashing any Linux > partition residing within. > Thus a rescue floppy might allow you to at least recover Linux. > Any thoughts on this? I think I detect some confusion here - if not, I apologise for explaining the obvious. A Linux partition "sitting in a DOS extended partition" can only exist if the extended partition has a DOS (FAT) filesystem, with umsdos installed to it. I presume this is not what you mean. In general, extended partitions are not linked to DOS in any way. An entry for an extended partition in the MBR's partition table points to *a second partition table* in a secondary MBR, somewhere else on disk. This table can contain up to two entries: one for a normal partition (of any type - e.g. DOS, type 6, or Linux, type 83) and an optional extended partition entry that points to the next partition table. (If this means anything to you, this system resembles a linked list). As you can see, if Linux is installed to an extended partition, it will have a partition of type 83, as usual - you just won't find it in the MBR, but in some extended MBR somewhere. If a virus is specifically looking to destroy a _DOS_ filesystem it won't touch Linux (it wouldn't go through the partition table anyway, it doesn't need to). Of course, if it destroys the information on where the partitions reside (i.e., the partition table of the MBR of any subsequent extended MBRs), then Linux won't be able to find the partition it is installed to anymore and can't boot. This could theoretically be fixed by booting from a recue floppy and restoring the partition structure to it's original state. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian/WindowsNT partitioning
Bill Leach <[EMAIL PROTECTED]> wrote: > If you can boot a DOS session, you might want to try doing a fdisk/mbr on > that drive. Not being sure just exactly what you are trying to do though, > realize that issuing the above command _will_ wipe out everything on the > drive. The (undocumented) fdisk /mbr command replaces the MBR software of the first harddisk with the standard MS-DOS software. It does not alter the partition table in any way, so all present partitions will remain accessible. It also doen't change anything _in_ those partitions. If a boot manager program such as LILO was installed in the MBR, it will of course be removed (in fact, this is one thing the command is often used for). Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Partitioning
Bill Leach <[EMAIL PROTECTED]> wrote: > In scsi (and I suspect IDE), the drive responds to the block > address and "knows nothing" about partitions, logical or otherwise (or > for that matter, clusters). IDE drives (at least, the older ones) are addressed in cylinder, head and sector numbers, but you are right, partitions are logical divisions of the drive that the drive itself know nothing about. > Though it depends upon what one might mean by the term "knows", the PC > BIOS _IS_ the implementation of this particular filesystem abstraction. You constantly confuse the issue. The BIOS 'knows' how to load a sector from disk to memory or vice versa. This has _nothing_ to do with filesystems. Filesystems define how data is ordered and stored on these sectors. > The decisions as to how to deal with the initial design limitations from > the original and even subsequent BIOS designs is what has "given" us this > "nightmare" design. I'm not exactly sure what you think is the nightmare part of the original design (and frankly, I don't care). There are a couple of limitations that we have to live with, given the fact that the PC was designed in days where a harddisk of 10 MB was way to expensive to consider, and that manufacturers still want to maintain backwards compatibility with software written in those days. A few of these are: * The standard MS-DOS MBR software is not capable of addressing harddisk sectors as logical block numbers (i.e., it uses a cylinder / head / sector addressing scheme). Modern BIOSes are capable of using sequential block numbers, though, and e.g. W95 _will_ install MBR software that uses these (and install itself on a partition with a type that MS-DOS doesn't understand) if installed on a HD/partition of above (I believe) 2 GB. * There is a limited number of primary partitions available in the MBR. This limitation is no serious problem, as many modern OSes don't object to being installed in an extended partition (of which there can be as many as required). Of course the MS-DOS MBR software does not support booting them, but should modern PC hardware be judged by old software? There are plenty decent boot mangers around. * The IDE hardware interface limitations, combined with the older BIOS interfaces, limited the addressable (through BIOS) size of a harddisk to 504 MB. As early as '92 the first workarounds for this problem appeared; they are (confusingly) known as Large or LBA mode, and basically work by translating cylinder, head and sector numbers in such a way that the limit is increased to 2 GB. Meanwhile, newer BIOS interfaces are present on all modern BIOSes that don't even have this limitation, and modern OSes are capable to use these interfaces. > Linux, for very practical reasons, chooses to honor this brain dead, > convoluted drive abstraction. There is nothing brain-dead about partitioning a drive - it is a perfectly logical way of having multiple independent filesystems and/or operating systems on one disk. > As to lilo -- IT IS lilo that has the problem. While under Linux, lilo > determines and stores the block locations for the files that it must > access to boot the machine, when the boot occurs those blocks must be > accessible through BIOS calls. It is the limitations of the BIOS calls > that started this whole mess! Not in modern BIOSes. It is backward compatibility that makes LILO use the old-style BIOS calls, but it is probably (by now) capable of making the newer style calls if told to (I can't check that as I don't have the latest version here). (Note that it is also backward compatibility that made the PC to what it is now: powerful hardware for very low prices). > I repeat: There is _nothing_ inherent in Linux that requires any of this > "grew like topsy", screwball "design". Ignoring your qualifications here, I never said there was. I was objecting to your misinformation about the basic PC hardware and BIOS. > As can no doubt be discerned, I detest the basic PC design. I have no desire to change your opinions on the basic PC design, but if you want to comment on it (and especially if you start answering other peoples questions), at least get your facts straight. > I would be > willing to defer to your claims that I am wrong concerning primary > partitions being visible in DOS, but am having some trouble with that. > My experience with DOS and Windoz is _very_ limited. Mine is quite extensive. Why do you not believe me, when you yourself say that your experience here is _very_ limited, and I am telling you I have the very thing you claim to be impossible running on my system (and on quite a few others, I might add)? Why do you combine lack of experience with such strong opinions? Gertjan. -- Gert
Re: Problem installing Debian 1.3
Dale Scheetz <[EMAIL PROTECTED]> wrote: > Logical partitions created with DOS > fdisk are completely unusable by Linux, and often will result in cfdisk > reporting a broke partition table. In general, it is wise to assume human error or misunderstanding when problems with partition tables appear. I've _always_ used DOS fdisk to create _all_ of my partitions [*], and have never encountered any problems. This includes many extended partitions, that were perfectly visible by Linux. Personally, I'd sooner distrust cfdisk than DOS fdisk anyway. > I have had reports from others who > have thought they were "getting ahead of the game" by creating their > partitions in DOS before beginning the Debian install, and were disturbed > to find that Debian didn't think there were any partitions available, or > worse yet that their partition table was broken. I've done that many times, and never had any problem. I'd like to see a partition table, created with DOS fdisk, with these 'problems'. Gertjan. [*] Since DOS fdisk has severely limited capabilities, I used to have it create a DOS partition, and then change (with a disk editor) the type to whatever I wanted it to be. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Partitioning
bleach <[EMAIL PROTECTED]> wrote: > Paul, Linux doesn't recognize or even care about "primary" partitions. > "fdisk", "cfdisk", etc. recognize them but only because BIOS deals with > drives and partitions in this fashion. Wrong. BIOS has no notion of partitions at all. Linux _does_ 'care' about partitions - it just isn't particular about which _type_ of partition it is installed to (like you wrote). > The reason why there can only > be four primary partitions is due to the design of the PC BIOS. Wrong again - it is due to the design of the partition table, and was (presumably) done by MS. It has _nothing_ to to with the BIOS. When they ran into the limitation [*], they created extended partitions, of which there can be as many as you like. > Even lilo > ignores the DOS, Windoz, OS2, characteristic of "not seeing" the > "inactive" primary partitions (of course OS2 boot manager effectively does > also). Wrong again - DOS and Windows have no problem whatsoever with seeing inactive primary partitions. I have four primary DOS partitions on my first HD, and DOS sees all of them and assigns them drive letters. Only OS/2 has this silly limitation, and OS/2's Boot Manager 'hides' (changes the type from 4 to 0x14, or 6 to 0x16) all other primary DOS partitions when booting one. The reason LILO doesn't care about partition tables is that it creates a list of the physical locations of sectors to load when booting. Gertjan. [*] Actually, the real reason extended partitions were created was as a quick fix for the (then) MS-DOS limitation of not being able to access disks that were larger than 32 MB. They removed this limitation around DOS 4.0, IIRC. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: NFS: mount clntudp_create: RPC: Program not registered
[EMAIL PROTECTED] wrote: > If everything worked fine, you will need to configure /etc/hosts.allow > on host kilu . It did - and although the /etc/hosts.allow files were equivalent on both machines, I found that changing "ALL: ALL" to "ALL: PARANOID" (as it was on host judy) on host kilu solved the problem. Thanks a lot! Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
NFS: mount clntudp_create: RPC: Program not registered
I'm trying to get NFS working between two PCs hooked up with a paralell cable. The networking itself seems to work: ping, telnet and FTP work as expected. I can mount the root directory of the second PC (judy) on the first (kilu), but not the other way around. The error I get is: mount clntudp_create: RPC: Program not registered As far as I can tell the configuration on both sides is equivalent: kilu:/etc/exports: / judy (ro) judy:/etc/exports: / kilu (ro) kilu: ps -axu | grep rpc: daemon 118 0.0 0.7 832 368 ? S 21:25 0:00 /usr/sbin/rpc.portm root 167 0.0 0.9 888 440 ? S 21:25 0:00 /usr/sbin/rpc.nfsd root 169 0.0 0.9 852 432 ? S 21:25 0:00 /usr/sbin/rpc.mount judy: ps -axu | grep rpc: daemon 108 0.0 2.4 832 368 ? S 21:06 0:00 /usr/sbin/rpc.portm root 129 0.0 3.1 892 472 ? S 21:06 0:00 /usr/sbin/rpc.nfsd root 131 0.0 2.9 860 448 ? S 21:06 0:00 /usr/sbin/rpc.mount There is some difference in the output of rpcinfo, but I'm told that's harmless (I'll include it here for completeness): kilu: rpcinfo -p: program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 132 udp 2049 nfs 132 tcp 2049 nfs 151 udp770 mountd 152 udp770 mountd 151 tcp773 mountd 152 tcp773 mountd judy: rpcinfo -p: program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 132 udp 2049 nfs 132 tcp 2049 nfs 151 udp732 mountd 152 udp732 mountd 151 tcp735 mountd 152 tcp735 mountd Both systems have been installed from the same CD (Debian 1.3.1); the kernel configuration options concerning networking are equal. I can mount judy on kilu with: kilu: mount judy:/ /mnt -t nfs ...but going the other way: judy: mount kilu:/ /mnt -t nfs .. gives the above error (no matter what order I do the commands, or start up the PCs). Does anyone have any idea what could be the problem? What does "RPC: Program not registered" mean? Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Where is "-Adobe-Helvetica-Bold-R-Normal--*-120-*-*-*-*-*-*"?
Mark Phillips <[EMAIL PROTECTED]> wrote: >> When I try to run either fr (filerunner) or tkman, it comes up with >> similar messages, both complaining about the lack of the font: >> "-Adobe-Helvetica-Bold-R-Normal--*-120-*-*-*-*-*-*" I don't know what causes this. You could try this: $ (for d in /usr/X11R6/lib/X11/fonts/* ; do echo $d ; cat $d/fonts.dir ; done) > fonts (all on one line) to create a file that shows all fonts installed on your system. There you can see if the font is actually installed (it is here). A (perhaps) related problem: Script started on Sat Dec 6 18:16:10 1997 $ cd /usr/X11R6/lib/X11/fonts/misc/ $ ls 9x15* 9x15.pcf.gz 9x15B.pcf.gz $ xterm -fn 9x15 Warning: locale not supported by C library, locale unchanged $ xterm -fn 9x15B Warning: locale not supported by C library, locale unchanged xterm: unable to open font "9x15B", trying "fixed" $ exit Script done on Sat Dec 6 18:17:19 1997 Does someone have an idea what could cause this? Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: mtools
<[EMAIL PROTECTED]> wrote: >> A much bigger problem of mtools is that when copying *to* an MS-DOS >> file system, it writes long filename entries to the directory. > It does that only when the file is not acceptable to normal FAT. So if you > don't like the so called `VFAT' don't use those names, that would fail in > normal FAT anyway. If I copy a (e.g. too long) filename to a DOS partition with the normal Linux cp command, it just truncates it - which is exactly what should happen if the partition is not mounted as vfat. This also should be possible with mtools. Even if I copy the file "pietje", with mtools I still get a long filename directory entry, because it is not in uppercase. This is annoying - I don't want to have to type all filenames that should go on a DOS partition in uppercase, and truncate them by hand, and I also don't feel like creating wrapper scripts around all mtools commands. I just don't use it anymore. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Making Debian bootable from hard disk
> boot=/dev/hda1 This line tells LILO to install itself to the bootsector of the first harddisk partition. In order for LILO to actually run, the MBR software must boot this partition (i.e., the active flag must be set to it). Alternatively, you may choose to install LILO to the MBR: boot=/dev/hda > root=/dev/hdc1 > The error message I am getting from liloconfig: > Warning: BIOS drive 0x82 may not be accessible > The 0x82 is the BIOS drive number, and has nothing to do with the partition type. As most older PC BIOSes only support two harddisks, LILO is trying to warn you here that you may not be able to access this disk at boot time. If you are sure you can, you can safely ignore this message. BTW, are you certain it is /dev/hdc, not /dev/hdb? Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: simple questions
Britton <[EMAIL PROTECTED]> wrote: > In my experience this works, but not nicely. You have to install Win95 > first, and when it gets itselft all screwed up you can't reinstall it > without scrapping your master boot record again, which I'm sure is a real > pain if not a castrophe. Although the W95 installation code overwrites the MBR without asking or even telling you, it does not alter the partition table. Simply reinstalling the MBR fixes the problem - a pain, yes, but hardly a catastrophe. > I've also found (though it probably should have > been obvious) that letting Win95 automagically reboot whill mess up your > MBR to where you have to go in with a rescue disk. I have not had this experience. When W95 reboots, it does nothing to the MBR here. > As for my > DOS partition, I have to go and run DOS fdisk to get to that, and I know > this could be done better, but perhaps not with Win95 on the same system. > Anyone got their setup working better? If you have different partitions for W95 and DOS, the problem you run in to is that both require the active flag in the MBR set to the partition they booted from. This requires rewriting the MBR at boot time. My version of LILO (19) can't do this, because the code turned out to be buggy and was disabled. Perhaps later versions (are there already?) can - look for the REWRITE-TABLE option. Alternatively, you could try my Boot Control (see sig). Although the installation program is an MS-DOS executable, it installs an MBR that doesn't depend on any particular OS, and (unlike LILO) doesn't use any other disk space. It allows you to boot the primary partitions and rewrites itself to disk. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
mtools
Jens B. Jorgensen wrote: > You can pipe the file through "tr -d '\r'". Ignore the other message > about mcopy. This is restrictive since it *assumes* that the file > is on a floppy disk (or other FAT volume). A much bigger problem of mtools is that when copying *to* an MS-DOS file system, it writes long filename entries to the directory. Apparently it assumes that everyone using DOS filesystems is using Windows '95. This is not just the default; you can't turn it off (at least, I found no way to do so - if anyone knows how please let me know). Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Commands Manual
Remco Blaakmeer <[EMAIL PROTECTED]> wrote:
> I think his needs are far more basic than that. He seems to be wanting a
> list of utility-names, as most first-time Linux users (including me) want.
> There are not many things more frustrating than thinking "I know it can be
> done, but I don't know how and I don't even know with what utility, so I
> don't know what man page to look at" -- if you have already discovered the
> very existance of the 'man' utility.
I remember in my early days of Linux trying to create such a list, by
printing out a directory listing of /bin and /usr/bin, and running man
for each of the files I found there. I made a file (by hand!) with
one-line descriptions for each program I found that way. Imagine how I
felt when I heard about apropos!
To get an idea of what's available, the original poster may want to
try something like:
apropos -r '*' | awk '$2 ~ (1) {print}' | less
Gertjan.
--
Gertjan Klein <[EMAIL PROTECTED]>
The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: to find fastest debian mirror
Andrea Mennucci <[EMAIL PROTECTED]> wrote: > This message is in MIME format. Yuk - as this was normal text, this wasn't necessary. > this script takes as its argument the file README.mirrors > (that can be downloaded from the debian ftp sites), extracts the list > of hosts and pings them all (it takes roughly 30 seconds, since > it parallelizes) then sorts the output by fastest time I had some trouble running your script, because `ulimit -u` was set at my system to 32 (for whatever reason), and I ran it under X - so I got lots of "fork: try again" messages. They seemed to prevent your script from terminating normally. Not knowing (then) how to solve the maximum processes problem, I tried to change your script so it would be configurable how many pings could run in parallel. I added MAX_PINGS=5 to the top, and changed: # we do not want to flood the net; we test 30 sites at a time # then we wait 8 seconds so that most of the pings will be done if [ `expr $n % 30 ` = 0 ] ; then sleep 8 ; fi to: while [ `ps -axu | grep -v grep | grep ping | wc --lines` -gt $MAX_PINGS ] do sleep 1 done This seems to limit the number of pings while not waiting longer than necessary. (Please note that I'm not good at shell scripts; there may be a much better way to do this - it just worked for me). > I think it would be fantastic if this script could be made > part of dpkg-ftp , (lets say, as an option when in dselect > you choose Access and then ftp); It would need some additional work to make it more resistant to problems like the ulimit -u thing, though. E.g., there is an unknown host (debian.med.miami.edu) in README.mirrors, and the ping error message regarding this host should be killed, I think. I also noticed during testing that there is a big difference in results between subsequent runs of the script - perhaps it would be better to make ping run a little longer. Lastly, it would be nice if the script FTPed the README.mirrors file itself (from ftp.debian.org) if not present. Other than the above, I found your script very useful, and I'll save it here - it may be useful to check Simtel, sunsite, etc. mirrors too ;-) Gertjan. --- -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: using dpkg to "see" the contents of a package
Lindsay Allen <[EMAIL PROTECTED]> wrote: > On Wed, 19 Nov 1997, Gertjan Klein wrote: [Upgrading mc] >> Why? My current version works for me - are the later versions so much >> better? > Yes. 3.5.17-1 has real troubles - in particular it is slow and the screen > flashes black at times. The later versions run smoothly and have a little > more in the way of functions - e.g. background transfers. > BTW, The unoffical mc_4.1.11-0.1_i386.deb is libc5 and thus bo compatible. Great - I downloaded it and it seems to work OK; I'll try to explore the new features later. Thanks! Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: using dpkg to "see" the contents of a package
Lindsay Allen <[EMAIL PROTECTED]> wrote:
> IIRC you add this snippet to /etc/mc/mc.ext
> regex/\.deb$
> Open=%cd deb:%d/%p/
> View=%view{ascii} dpkg-deb -c %f
Yes, that works! Great! It is really nice to be able to browse
inside the packages on the CD-ROM, especially the /usr/doc parts of
them.
> Better yet is to get an unofficial later version.
Why? My current version works for me - are the later versions so much
better?
Gertjan.
--
Gertjan Klein <[EMAIL PROTECTED]>
The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: using dpkg to "see" the contents of a package
Martin Bialasinski <[EMAIL PROTECTED]> wrote: > I heavily use mc to enter a deb package. Then I can even examine the > contents of the files inside without the need of dpkg --extract. It is > pretty neat. How do you do this? My mc (3.5.17, from Debian 1.3.1) doesn't seem to support .deb packages by default, and neither the .ar files that they really are (just .tar files). Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: starting xdm
"Oliver Elphick" wrote: > Will Lowe wrote: >> I'd like my system to come up running xdm or kdm. What is the proper >> place to do this? Right now I'm just logging in and doing "sudo kdm", >> but I've a feeling that there's probably a correct runlevel or something >> to do this in. > In /etc/X11/config, you need the line >start-xdm > as explained somewhere in the Debian documentation for X. Note that if, when installing X, you answered "no" to the question whether you wanted xdm to start at boot time, there will be no server in the file /etc/X11/xdm/Xservers, even though the script comments claim this should happen: # X servers are automatically added to this file by the Debian # xbase and xserver configuration scripts. I had a hell of a time figuring out what was wrong; it turns out I had to add a line like the following to that file: :0 local /usr/X11R6/bin/X After setting this (and changing "no-start-xdm" and "no-xdm-start-server" to "start-xdm" and "xdm-start-server" in /etc/X11/config), things worked like expected. I guess I should try to figure out how to file a bug report, as the absent line in Xservers seems a bug to me. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Problems working with bash.
"Karl M. Hegbloom" <[EMAIL PROTECTED]> wrote: > Open up your info reader; Don't get me started on info! > and read the 'readline' > manual, which you've obviously not heard of yet... ? I see no reason in my post for you to make such an assumption. > And here's a copy of the ~/.inputrc I have been using; I think I > obtained it under similar circumstances. :-) Why did you send it? It does not do what I wanted. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Problems working with bash.
Michel Beland <[EMAIL PROTECTED]> wrote: > Second, if you have not already typed something on the command line, > history-search-backward does not match any previous command in the > history and just beeps. 4DOS and tcsh just match all the commands > instead and show you the first match. But this was my whole point! I knew about history-search-backward, and already use it - but I still need two keys to be able to get just the previous command, or the previous command starting-with-something. The 4DOS behaviour is so increadably handy that knowing tcsh also has it may make me switch to that shell. > I have read that this is fixed > in bash 2.0, at last, but did not try it yet. Me neither, and I'm a bit afraid to as messages on the list suggest that it breaks a lot of existing scripts. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Problems working with bash.
Kai Grossjohann <[EMAIL PROTECTED]> wrote: > If you type, say, "g" then M-p repeatedly you get > all command lines that begin with "g". I use this *all* the time, as > an alternative to "!g" because it lets me see if I got the right > command line before I hit Enter. Still, none of this even begins to compare with the ease of use of (horror! shock!) the DOS command interpreter 4DOS! Why use separate keys like M-p for this, when you've got the arrow keys? The principle is this: if you have an empty commandline and you type the up arrow, you get the previous command. If you've already typed something, you get whatever previous command starts with that. This combines the two functions that bash uses (and needs two keys for) into one. I wish I could convince bash to work like this! Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: HELP! partition table messed up -- (DOS okay but linux is not!)
"Arup Mukherjee" <[EMAIL PROTECTED]> wrote: > I'm under the impression (from the debian fdisk man page, among other > things) that DOS/W95 store a copy of the partition table in their boot > sectors, and use its info in preference to that from the MBR. Assuming > that's true, I'd just like to make the MBR consistent with what DOS > and W95 already believe is the reality. DOS and W95 do not store partition information in the boot sector. The information you see in DOS fdisk is based on the partition table in the MBR, nothing else. DOS does store filesystem information in it's boot sector, and that includes the exact position _of that partition_. I don't know what happened, but all this sounds like you have an older version of Disk Manager or EZ-Drive installed. These programs are used on systems with an older BIOS, that doesn't know the LBA or Large translation mode for big harddisks (> 504 MB). It is software that is installed in the MBR, and loads itself in memory at boot time, providing a run-time translation of disk parameters. Linux will overwrite the program and use it's own drivers. Later versions are recognised by Linux, and then it will take over the translation, but older versions had problems. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html
Re: Help! Messed up my MBR part 2
[EMAIL PROTECTED] (Brian Hutchinson) wrote: > Here is some more information on my sad state! [All information zapped...] >From what you've written, I gather that you inadvertedly told LILO to overwrite the boot sector (_not_ the MBR) of your DOS partition. DOS keeps some important bookkeeping information in it's boot sector, among which the size of the partition, the number of sectors in a cluster, etc. LILO has overwritten this information, so DOS can no longer boot from this partition. I know of no easy solution to this problem. There are no tools that I know of, that rebuild a DOS bootsector without also destroying all information on the partition. The simplest thing to do is to reformat the DOS partition, and reinstall your software. If you have some absolutely vital information on this partition, I am willing to try to create a new bootsector for you. For this, I need all partitioning information (use the Debian rescue disk to run cfdisk). Don't expect results very soon, though, as it is quite a bit of work (and I can't guarantee success...) Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Help with disk partition.
[EMAIL PROTECTED] (Jose Antonio Martin Guerra) wrote: > I would like to use 500MB for Linux and 1.500MB for DOS, WINNT, WIN95. > How do I go about creating partitions and formatting the disk, taking > into account the problem with > 1024 cylinders. > I am starting from scratch so I can reformat the whole disk. Turn on LBA or Large mode in your BIOS setup. Linux understands and supports this, and it gets rid of the 1024 cylinder problem for all operating systems you mention. You can then partition your HD any way you like. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- This message was delayed because the list mail delivery agent was down.
Re: Umsdos support?
Giuliano Procida <[EMAIL PROTECTED]> wrote: > It is possible to fool the installation process roughly as follows: > You need a DOS partition, say /dev/hda1, umssync, and perhaps other > things (it's been a while). Replace the boot-floppy kernel with one > that has FAT and UMSDOS compiled in. Ah, you make it sound so easy ;-) I can't seem to get this right. I copy the kernel to the file linux and run ./rdev.sh. This script tries to run "rdev /mnt/linux /dev/ram0" - and there is no /dev/ram0. Why does the script ask for something Debian doesn't supply? Anyway, if I ignore this error or run the command manually with /dev/ram (which I do have), and boot the floppy, it stops here: RAMDISK: compressed image found at block 0 VFS: Mounted root (minix filesystem) Root is mounted from /dev/ram /etc/rc done. And then it just sits there. I can get a shell at Alt-F2, but obviously something must be wrong so I didn't try going any further. What could cause this? The other instructions you gave seem easy enough to follow, but unfortunately I didn't get that far :-( >> Unfortunately, after a message of VFS: Mounted umsdos >> filesystem as root (or similar), the system hangs in an endless loop >> continuously reading the harddisk. > You seem to have got most of the way. What messages does it give? Just that. Perhaps this was caused by the remounting in /etc/init.d/boot? I didn't know I had to change that. In the mean time I deleted the test harddisk partition so I can't easily try again. > As an alternative, you could try my modifications to the boot-floppies > package to handle UMSDOS installs. There has just been a new > boot-floppies release, so I'll have do some merging before I have a > proper set of patches ready. Have a look at > ftp://pootle.magd.cam.ac.uk/ if you are interested (patches against > boot-floppies 1.2.5). My mirror doesn't carry 1.2.5, only 1.2.4. It seems there's some stuff specific to your system in the patch (I saw some copying of loadlin); was I too early downloading it? > In your other message you mentioned a ZIP drive, can't you format a > disk as ext2? Or is that not a possibility for you? Not really. I want Debian to run from the ZIP disk so I can take it to my father's place and run Linux there. This way, I don't need a special boot floppy, or files on his harddisk. I just insert the ZIP disk and get Linux. This is only possible using umsdos. (I am a bit surprised, actually, that Debian doesn't support installation to umsdos). Thanks for your help, Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Help: problem with booting from HD
In article <[EMAIL PROTECTED]>, R <[EMAIL PROTECTED]> wrote: > "LILO Loading Linux > Uncompressing Linux..." > "crc error > System halted" Apparently, LILO was installed correctly, and accessed the /vmlinuz file without (disk i/o) errors. It seems, though, that the correct data wasn't loaded, which could mean a disk geometry problem (in fact, that's the only thing I can think of). I asked you this before: do you have LBA mode or Large mode turned on in the BIOS settings for your harddisk? How many cylinders does it say your HD has? If this number is bigger than 1024, you're in trouble. If either Large or LBA mode is on, try the other one (and prepare to reinstall!). (The BC manual explains all this in the section on Cylinder-Head-Sector translation). If you have to reinstall, hold off on W95 and try Linux first; W95 will overwrite your MBR, but BC is easy to reinstall. Your lilo.conf looks OK to me - and from the above messages, LILO itself appears to be working fine (it's the kernel uncompression code that complains). Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
In article <[EMAIL PROTECTED]>, Philippe Troin <[EMAIL PROTECTED]> wrote: > On Wed, 08 Jan 1997 15:42:27 +0100 Gertjan Klein ([EMAIL PROTECTED]) > wrote: >> One of my most serious criticisms is the fact that in spite of the >> dependencies being known, packages aren't installed in the right order. >> If package 1 depends on package 2, then package 2 *must* be installed >> *first*. This isn't done; I consider this a bug, that should be >> reported. > Not a bug. What you describe is pre-dependencies. It's a bit too long > to explain here, but you can find all the details in the Debian > policy manual. > Dpkg does the work right... so far. Interesting. I looked in /usr/doc/debian, and found no policy manual. I finally found a policy.html _directory_ in /usr/doc/dpkg; I read all the files in it and couldn't find "all the details" there... But perhaps there already is a misunderstanding, as you're talking about dpkg, and I was talking about dselect. (Or maybe I don't understand the interaction between the two). Dselect knows the dependancies between the packages it has to install, and should should present them to dpkg in the right order. I don't want to start word games here, but in my opinion a bug is an unintended or undesired feature. I can hardly imagine the debian developers finding it desirable to present an unexpecting installer with lots of error messages about dependancies, but if they do, I urge them to reconsider this point of view. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Help: problem with booting from HD
R <[EMAIL PROTECTED]> wrote: > i made > four primary partition (500mb for linux native, 500mb for linux native, > 64mb for linux swap, and 900somethinb mb for DOS-32 bit) and marked all > but the linux swap as bootable. Install went thru without problem. This is a serious error: only _one_ partition may be marked bootable. If cfdisk let you do this, report this as an error to it's author. I doubt if LILO cares very much, but W95 would probably choke, and anyway it's against the specifications. Your best bet is to mark the W95 partition as bootable, and the others not. Just to make sure: you _did_ turn on Large mode (or LBA mode) in your BIOS setup of your harddisk, didn't you? Both LILO and W95 need to use BIOS to load themselves, and using BIOS you can't access cylinders greater than 1024. The above modes fix this problems, and Linux can handle them in it's own drivers as well. > Now the problem is I can't boot from the hard drive. I can boot from the > custom boot floopy without problem, and log in as root, etc, and /dev/hda > is already mounted at that point. I did du and see that the install used > about 15MB, which i assume is correct. if i do shutdown, and reset the pc > or turn off and back on the pc, it will produce various kinds of errors. > most of the time it will get as far as "lilo, uncompress linux" and give > me a "crc error -- system halt" and at that point I can't even > alt-ctrl-del. Boot from floppy again, go to the mounted harddisk, and check /etc/lilo.conf. (If you can't fix the problems, include this file in your next post). If it is ok, rerun LILO thus (assuming your /dev/hda1 is mounted on /mnt): lilo -C /mnt/etc/lilo.conf (or, if lilo isn't present on your boot floppy, /mnt/sbin/lilo -C /mnt/etc/lilo.conf). Your /etc/lilo.conf should look something like this: boot=/dev/hda root=/dev/hda1 delay=50 image=/vmlinuz label=Linux read-only other=/dev/hda4 label=W95 table=/dev/hda The image= should of course point at your kernel. Note that the W95 installation program will overwrite the MBR that LILO installs, so after installing W95 you'll have to boot from floppy again and rerun LILO. You may also want to try Boot Control (see address in my sig). It comes with documentation that describes the boot process a bit better. You'd still need LILO, but you could then install it to the Linux partition's boot sector (i.e., change the above boot=/dev/hda to boot=/dev/hda1). Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] >From miss Received: from mongo.pixar.com (138.72.50.60) by master.debian.org with SMTP; 8 Jan 1997 16:14:23 - Received: (qmail 15372 invoked from network); 8 Jan 1997 15:22:12 - Received: from primer.i-connect.net (HELO master.debian.org) ([EMAIL PROTECTED]) by mongo.pixar.com with SMTP; 8 Jan 1997 15:22:12 - Message-Id: <[EMAIL PROTECTED]> Date:Wed, 8 Jan 1997 10:23:05 -0500 From: Ami Ganguli <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Organization: Ganguli Consulting Inc. X-Sender: Ami Ganguli <[EMAIL PROTECTED]> X-Mailer: Mozilla 4.0b1 (Win95; I) MIME-Version: 1.0 To: [EMAIL PROTECTED] CC: Martin Konold <[EMAIL PROTECTED]>, Ben Gertzfield <[EMAIL PROTECTED]>, Debian-Users Subject: Re: Maintaining multiple Debian boxes X-Priority: Normal References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"gtZ513.0.0x.vkxqo"@master.debian.org> Resent-From: debian-user@lists.debian.org Resent-Reply-To: debian-user@lists.debian.org X-Mailing-List: archive/latest/2840 X-Loop: debian-user@lists.debian.org Precedence: list Priority: non-urgent Importance: low Resent-Sender: [EMAIL PROTECTED] Has anybody used GNU cfengine? I don't really know what it's capable of, but it's a free part of Debian. I was considering using it myself, but I haven't had time to investigate it properly. ... Ami. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Pete Templin <[EMAIL PROTECTED]> wrote: > On Tue, 7 Jan 1997, Martin Konold wrote: >> Actually why is the maintainer so silent? > Perhaps you would be silent if discussions about your package were turning > into some semi-serious bash N trash sessions. If s/he (or you) interprets at least _my_ remarks as "bash N trash sessions", we've misunderstood each other. I have no desire to put down dselect and friends; I think the Debian package management is wonderful, especially the dependency checking. I do, however, have seconded some remarks (and made some myself) about serious problems with the current user interface and functionality. As far as I'm concerned, these remarks are intended in a positive way, i.e. to let the maintainer know what problems were found, and to suggest improvements. One of my most serious criticisms is the fact that in spite of the dependencies being known, packages aren't installed in the right order. If package 1 depends on package 2, then package 2 *must* be installed *first*. This isn't done; I consider this a bug, that should be reported. Perhaps it is important to recognize that different viewpoints lead to different evaluations. I'm sure dselect does everything the maintainer feels it should do, and in the right way - and from his/her viewpoint s/he is probably right. My viewpoint is one of a *nix newbie, used to DOS (is may not be much of an OS, but lots of *nix programs can learn a lot about user-friendliness from DOS programs). It is important for me to have an errorfree, even warning-free install - because I don't know what to do with all these warnings. And I'm a commandline person - imagine what it's like for someone used to W95? > Keep in mind that we are all getting a generally fantastic product for the > best price anyone could ask for. Please don't bring in that "but it's free" stuff. I have great respect for the fact that Debian is developed entirely by volunteers (in fact, it being non-commercial is one of the reasons I chose this distribution even though it would have cost me the same to get e.g. redhat). Nevertheless, a lot of people depend on it now, and may expect the maintainers to strive for improvement. (I second the "generally fantastic" bit, BTW). > That said, who is willing to coordinate efforts toward gathering > suggestions for dselect, and what is the next step that we need to take? There - this is what we were talking about! Not bashing, but gathering suggestions for dselect! In my opinion, though, the next step is for the maintainer of dselect to come out of hiding ;-) and tell us what s/he thinks about the suggestions and problem reports so far. Gertjan. [PS - please don't Cc me in your messages directly - I'll get it via the mailing list, thank you] --- -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: List of installation problems for 1.2
Dale Scheetz wrote: > This is my weekly publication of the list of known problems with the 1.2 > release of Debian. I've seen it mentioned here before, but didn't find it on the list: when initially installing, there are no device files for SCSI cdrom or tape. Not knowing enough of *nix to fix this myself, I was lucky I had moved my old slackware stuff to another partition, so I could steal it's MAKEDEV script. Debian should either simply include _all_ device files (how big are they anyway), or include a MAKEDEV-alike script (and document it's existence!) so users can do this themselves. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Kirk Hilliard wrote: [A nice list of suggested dselect improvements, which I mostly agree with] In addition, I think the following improvements are important: - Create a log file containing *everything* that is output to the screen (stdout and stderr). I noticed more than one package complaining it couldn't fully configure itself for one reason or other, and telling me I could redo the configuration manually by running "xxx". It is not nice to have to write this down. If people are concerned about disk space, a menu choice could be to clear the log file. - Whenever a package returns an error when installing, present the user with the option to stop installation entirely (so the problem can be delt with), or continue with the next package. - Most important of all, build a dependancy list for the selected package, and start installing at the low end (the packages not depending on anything else). I did a fresh install and ran into tons of error messages about dependancies not being fulfilled. Rerunning dselect a few times solved (most of) these problems, as the stuff the problematic package depended on was installed by then, but this is _ugly_. I made a concious choise for Debian, having heard lots of nice things about the package management and ease of installation. I'm still happy with my choise, but even Debian has a long way to go before it will convince the average W95 user that Linux is usable for non-wizards. > I. Less clutter > A. Present packages like a folding editor, so the initial > presentation is quite compact. The kernel 'make menuconfig' is a nice example. > Unless a group like this is already in place, I propose that we form a > working group to initially hash out how dselect should be improved, > and then to actually implement those improvements. With the disclaimer that I'm not exactly a *nix guru, I'd like to contribute to such a group. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Install questions
In article <[EMAIL PROTECTED]>, "Terrence M. Brannon" <[EMAIL PROTECTED]> wrote: > - install MBR on /dev/hda > - how do I uninstall it so I can load DOS again? > - how do I allow DOS to be booted from a LILO prompt? To re-install an MS-DOS MBR, boot DOS from a floppy and type 'fdisk /mbr'. Lilo can boot any partition you like; check it's man page. If you don't like the lilo interface, you may want to check the page in my .sig; Boot Control provides alternative MBRs that give an (IMHO) nicer user interface. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
