Re: The list of outstanding reports that should be closed
OKUJI Yoshinori writes: OY Here is the list of outstanding reports that should be OY closed. Gordon, if you have any question, feel free to ask me. OY * #42242: grub: GRUB no longer includes HTML documentation OY * #42273: Documentation files removed in update of grub OY That was not a bug at all. I need to keep these open, until I set up HTML generation from the Debian build files, because all Debian documentation is supposed to be in HTML. You don't have to worry about that, though. OY * #63727: grub: Doesn't recognize MaxBlast bootable floppy as OY executable OY That was a bug in MaxBlack but not in GRUB. Should we be so strict about the chainloader signature? I think there should at least be an option to disable the signature check. Let me know what you think, and I can implement it. -- Gordon Matzigkeit [EMAIL PROTECTED] //\ I'm a FIG (http://fig.org/) Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
Re: The list of outstanding reports that should be closed
From: Gordon Matzigkeit [EMAIL PROTECTED] Subject: Re: The list of outstanding reports that should be closed Date: 27 Jun 2000 10:36:14 -0600 I need to keep these open, until I set up HTML generation from the Debian build files, because all Debian documentation is supposed to be in HTML. You don't have to worry about that, though. Ok. Should we be so strict about the chainloader signature? I think there should at least be an option to disable the signature check. Let me know what you think, and I can implement it. The option does exist. In the file NEWS: New in 0.5.94 - 2000-03-06: [snip] * The command "chainloader" now accepts an option "--force", which is required if you want to chain-load a boot loader defective in the signature, such as SCO Unixware 7.1. Okuji
Re: The list of outstanding reports that should be closed
OKUJI Yoshinori writes: OY The option does exist. In the file NEWS: OY New in 0.5.94 - 2000-03-06: [snip] * The command "chainloader" OY now accepts an option "--force", Great! I'll close the report, -- Gordon Matzigkeit [EMAIL PROTECTED] //\ I'm a FIG (http://fig.org/) Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
Re: The list of outstanding reports that should be closed
3-Jun-00 14:34 you wrote: From: "Khimenko Victor" [EMAIL PROTECTED] Subject: Re: The list of outstanding reports that should be closed Date: Fri, 2 Jun 2000 23:11:09 +0400 (MSD) Someone can explain from WHERE this weird check come anyway ? That seems to be introduced by my incaution. The right implementation is in stage1. I'll fix the bug soon. Ok. Check from stage1 works just fine here. So LBA read/write functions are supported if and only if "DMA boundary errors handled transparently" ??? What a strange logic! Who's bright mind generated such a great check ? Thanks for your report, but I hate such a mordacity. Oops. Sorry if I hurt your feelings. It was not my wish (ok, it was not wish by iself to be exact - see below). In fact it was not even 100% modracity - I really wondered why such problem can be unnoticed for so long: I've seen quite a few reports where peoples said that GRUB's LBA check does not work for them; some distributions (Mandrake and Caldera) used GRUB with check disabled; there are even autoconf option to disable it (now it's grub-install option if I recall correctly). It was kind of hard to believe that with all this fuzz noone ever looked in interrupt list to verify if check is sane ! Why don't you send a bug report mildly? Ok. I've sent quite a few different bug reports to different mailing lists. Usual reaction to mildly and polite bug report is total disregardion. You can send 10 polite bug reports and still get no reaction at all. When you are sending VERY abrasive and caustic bug report you getting SOME reaction for sure. Since just answer "you are ill-manerred impudent bully" will be just flame and will sank answering person down to my level he(she) usually answer something about reported bug as well. That's my goal - usually I care much more about fixing bugs then about keeping good name. Don't you know etiquette? Yeah. I know about etiquette :-) I'm deliberately violate it (see above). Sorry about this once more - looks like it was not needed this time (on other side it was not pure mordacity as I've said before).
The list of outstanding reports that should be closed
Here is the list of outstanding reports that should be closed. Gordon, if you have any question, feel free to ask me. * #35414: grub: Doesn't detect hdc/hdd partition That was just because his BIOS didn't support more than two drives. Not a GRUB bug. * #35850: grub: stage1 does not work as MBR That was just because he forgot to specify the option `d' for the command `install'. Not a GRUB bug. In addition, we have already improved the documentation and added another installation command, so there is no good reason why the report should be open. * #42242: grub: GRUB no longer includes HTML documentation That was not a bug at all. * #42273: Documentation files removed in update of grub Likewise. * #61513: enabling `lba-support-bitmap-check' marks some systems unbootable That was just because he forgot to specify the option `--enable-lba-support-bitmap-check' for the configure script. Not a GRUB bug. Moreover, I've already changed the check to an installation-time option from a build-time option, so we don't have to keep it open. * #63727: grub: Doesn't recognize MaxBlast bootable floppy as executable That was a bug in MaxBlack but not in GRUB. * #35852: grub: should have way to install modified stage1.5 -and- stage2 GRUB 0.5.94 has the feature. * #60177: grub: Bios device swap Likewise. Regards, Okuji
Re: The list of outstanding reports that should be closed
3-Jun-00 02:35 you wrote: * #61513: enabling `lba-support-bitmap-check' marks some systems unbootable That was just because he forgot to specify the option `--enable-lba-support-bitmap-check' for the configure script. Not a GRUB bug. Moreover, I've already changed the check to an installation-time option from a build-time option, so we don't have to keep it open. Someone can explain from WHERE this weird check come anyway ? -- cut -- /* Make sure that LBA read/write functions are supported. */ if (drp.flags 1) -- cut -- Ok. From Ralf Brown's interrupt list: -- cut -- Bitfields for IBM/MS INT 13 Extensions information flags: Bit(s) Description (Table 00274) 0 DMA boundary errors handled transparently 1 cylinder/head/sectors-per-track information is valid 2 removable drive 3 write with verify supported 4 drive has change-line support (required if drive = 80h is removable) 5 drive can be locked (required if drive = 80h is removable) 6 CHS information set to maximum supported values, not current media 15-7 reserved (0) SeeAlso: #00273 -- cut -- So LBA read/write functions are supported if and only if "DMA boundary errors handled transparently" ??? What a strange logic! Who's bright mind generated such a great check ? P.S. Yes, I know: Ralf Brown's list is not official documentation. From past expirience I know though that if official documentation and Ralf Brown's interrupt list say different things then 9 times out of 10 interrupt list is correct and official documentation wrong. P.P.S. At least my Asus K7M motherboard return "0" there while LBA works just fine.
Re: The list of outstanding reports that should be closed
From: "Khimenko Victor" [EMAIL PROTECTED] Subject: Re: The list of outstanding reports that should be closed Date: Fri, 2 Jun 2000 23:11:09 +0400 (MSD) Someone can explain from WHERE this weird check come anyway ? That seems to be introduced by my incaution. The right implementation is in stage1. I'll fix the bug soon. So LBA read/write functions are supported if and only if "DMA boundary errors handled transparently" ??? What a strange logic! Who's bright mind generated such a great check ? Thanks for your report, but I hate such a mordacity. Why don't you send a bug report mildly? Don't you know etiquette? Okuji
