No response from keyboard on Oldworld- possibly relevant kernelchange
Title: No response from keyboard on Oldworld- possibly relevant kernel change There were 2 lines added in to the rd.c kernel module in version 2.2.18 very close to the line where the user is requested to insert the floppy. These lines were also in 2.2.19, but disappeared in version 2.3.0. The (I think) bogus lines are shown at http://innominate.org/cgi-bin/lksr/linux/drivers/block/rd.c.diff?r1=1.1.1.9&r2=1.1.1.10&cvsroot=v2.2&only_with_tag=LINUX_2_2_18 >From the patch-2.2.18.gz pot file: diff -u --new-file --recursive --exclude-from /usr/src/exclude v2.2.17/drivers/block/rd.c linux/drivers/block/rd.c --- v2.2.17/drivers/block/rd.c Sat Sep 9 18:42:34 2000 +++ linux/drivers/block/rd.c Wed Nov 8 23:00:34 2000 @@ -614,9 +614,11 @@ #ifdef CONFIG_MAC_FLOPPY if(MAJOR(ROOT_DEV) == FLOPPY_MAJOR) swim3_fd_eject(MINOR(ROOT_DEV)); +#ifdef CONFIG_BLK_DEV_INITRD else if(MAJOR(real_root_dev) == FLOPPY_MAJOR) swim3_fd_eject(MINOR(real_root_dev)); #endif +#endif printk(KERN_NOTICE "VFS: Insert root floppy disk to be loaded into RAM disk and press ENTER\n"); wait_for_keypress(); I would normally look for something *after* the wait_for_keypress to have been changed, but I'm thinking maybe if the floppy doesn't get into the right state before the wait, the wait could last a very long time. When do we expect Debian to move into the 2.3 kernel territory? Then I might have a chance of a successful install on my Oldworld mac. -- Chris Tillman [EMAIL PROTECTED]
No response from keyboard on Oldworld: possibly relevant kernelchange
Title: No response from keyboard on Oldworld: possibly relevant kernel change There were 2 lines added in to the rd.c kernel module in version 2.2.18 very close to the line where the user is requested to insert the floppy. These lines were also in 2.2.19, but disappeared in version 2.3.0. The (I think) bogus lines are shown at http://innominate.org/cgi-bin/lksr/linux/drivers/block/rd.c.diff?r1=1.1.1.9&r2=1.1.1.10&cvsroot=v2.2&only_with_tag=LINUX_2_2_18 >From the patch-2.2.18.gz pot file: diff -u --new-file --recursive --exclude-from /usr/src/exclude v2.2.17/drivers/block/rd.c linux/drivers/block/rd.c --- v2.2.17/drivers/block/rd.c Sat Sep 9 18:42:34 2000 +++ linux/drivers/block/rd.c Wed Nov 8 23:00:34 2000 @@ -614,9 +614,11 @@ #ifdef CONFIG_MAC_FLOPPY if(MAJOR(ROOT_DEV) == FLOPPY_MAJOR) swim3_fd_eject(MINOR(ROOT_DEV)); +#ifdef CONFIG_BLK_DEV_INITRD else if(MAJOR(real_root_dev) == FLOPPY_MAJOR) swim3_fd_eject(MINOR(real_root_dev)); #endif +#endif printk(KERN_NOTICE "VFS: Insert root floppy disk to be loaded into RAM disk and press ENTER\n"); wait_for_keypress(); I would normally look for something *after* the wait_for_keypress to have been changed, but I'm thinking maybe if the floppy doesn't get into the right state before the wait, the wait could last a very long time. When do we expect Debian to move into the 2.3 kernel territory? Then I might have a chance of a successful install on my Oldworld mac. -- Chris Tillman [EMAIL PROTECTED]
cvs commit to boot-floppies/utilities/dbootstrap by dwhedon
Repository: boot-floppies/utilities/dbootstrap who:dwhedon time: Thu Apr 5 22:41:38 PDT 2001 Log Message: added support for installing woody, potato and slink debootstrap can't install sid right now. removed soem cruft from net-fetch.c Files: changed:extract_base.c net-fetch.c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies/scripts/rootdisk by dwhedon
Repository: boot-floppies/scripts/rootdisk who:dwhedon time: Thu Apr 5 22:41:38 PDT 2001 Log Message: added support for installing woody, potato and slink debootstrap can't install sid right now. removed soem cruft from net-fetch.c Files: changed:SMALL_BASE_LIST_all -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Processed: bugs
Processing commands for [EMAIL PROTECTED]: > tags 64565 fixed Bug#64565: base unpack should have progress bar Tags added: fixed > tags 93069 fixed Bug#93069: install manual refers to outdated license location Tags added: fixed > End of message, stopping processing here. Please contact me if you need assistance. Darren Benham (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies/debian by dwhedon
Repository: boot-floppies/debian who:dwhedon time: Thu Apr 5 20:34:51 PDT 2001 Log Message: bug 64565 is fixed as well Files: changed:changelog -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: bugs
Processing commands for [EMAIL PROTECTED]: > tags fixed 64565 Unknown command or malformed arguments to command. > tags fixed 93069 Unknown command or malformed arguments to command. > reassign 67118 debootstrap Bug#67118: base system does not contain /var/log/btmp Bug reassigned from package `boot-floppies' to `debootstrap'. > End of message, stopping processing here. Please contact me if you need assistance. Darren Benham (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#90967: proposed fix
Howdy,
I believe that this is caused by a bug in libfdisk. It does not
add hdg to the fdisk_disks list because the device_blocks[] array
does not contain the proper information for the hdg, hdh, hdi, or
hdj drives. The device number for hdg is 34 << 8, by using the
information in device_blocks it is 33 << 8 + 128. Since it isn't
in this table, it isn't added to the list of drives, hence isn't
displayed as an option.
The following patch should fix support for hdg and hdh, and add
support for hdi and hdj (it was already in place for hdk and hdl).
Matt
Index: utilities/libfdisk/fdisk.c
===
RCS file: /cvs/debian-boot/boot-floppies/utilities/libfdisk/fdisk.c,v
retrieving revision 1.52
diff -u -r1.52 fdisk.c
--- utilities/libfdisk/fdisk.c 2001/03/24 22:04:47 1.52
+++ utilities/libfdisk/fdisk.c 2001/04/06 03:10:27
@@ -520,11 +520,13 @@
{ 21 << 8, 2, 64 }, /* mfma - mfmb */
{ 22 << 8, 2, 64 }, /* hdc - hdd */
{ 28 << 8, 16, 16 }, /* ada - adp */
-{ 33 << 8, 4, 64 }, /* hde - hdh */
+{ 33 << 8, 2, 64 }, /* hde - hdf */
+{ 34 << 8, 2, 64 }, /* hdg - hdh */
{ 36 << 8, 4, 64 }, /* eda - edd */
{ 44 << 8, 16, 16 }, /* ftla - ftlp */
{ 45 << 8, 4, 16 }, /* pdaa - pdad */
{ 48 << 8, 256, 8 }, /* rd/c0d0 - rd/c8d31 */
+{ 56 << 8, 2, 64 }, /* hdi - hdj */
{ 57 << 8, 2, 64 }, /* hdk - hdl */
{ 65 << 8, 112, 16 }, /* sdq - sddx */
{ 72 << 8, 128, 16 }, /* ida/c0d0 - ida/c7d15 */
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies/debian by dwhedon
Repository: boot-floppies/debian who:dwhedon time: Thu Apr 5 20:20:05 PDT 2001 Log Message: indicate 93069 is fixed Files: changed:changelog -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies/documentation by dwhedon
Repository: boot-floppies/documentation who:dwhedon time: Thu Apr 5 20:18:11 PDT 2001 Log Message: The installation manual refered to /usr/doc/copyright rather than /usr/share/common-licenses when indicating the location of a GPL copy. patch from Matt Kraai <[EMAIL PROTECTED]> Files: changed:install.cs.sgml install.es.sgml install.fi.sgml install.fr.sgml install.hr.sgml install.ja.sgml install.pl.sgml install.pt.sgml install.ru.sgml install.sgml install.sk.sgml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#93069: install manual refers to outdated license location
Package: boot-floppies Version: N/A The installation manual refers to /usr/doc/copyright as the directory in which the GPL can be found. The following patch fixes it to point to /usr/share/common-licenses instead (and updates all the translations as well). Matt Index: documentation/install.cs.sgml === RCS file: /cvs/debian-boot/boot-floppies/documentation/install.cs.sgml,v retrieving revision 1.9 diff -u -r1.9 install.cs.sgml --- documentation/install.cs.sgml 2000/08/02 17:00:20 1.9 +++ documentation/install.cs.sgml 2001/04/06 02:37:26 @@ -99,7 +99,7 @@ licenci GNU General Public License. Licenci GNU General Public License najdete v distribuci Debian v -souboru /usr/doc/copyright/GPL nebo na WWW /usr/share/common-licenses/GPL nebo na WWW http://www.gnu.org/copyleft/gpl.html" name="GNU">. Mù¾ete o ní za¾ádat dopisem na adresu Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. Index: documentation/install.es.sgml === RCS file: /cvs/debian-boot/boot-floppies/documentation/install.es.sgml,v retrieving revision 1.9 diff -u -r1.9 install.es.sgml --- documentation/install.es.sgml 2001/01/11 01:45:12 1.9 +++ documentation/install.es.sgml 2001/04/06 02:37:26 @@ -99,7 +99,7 @@ Una copia de la Licencia Pública General de GNU (General Public License) está disponible en la distribución Debian GNU/Linux como -/usr/doc/copyright/GPL, o en la World Wide Web en /usr/share/common-licenses/GPL, o en la World Wide Web en http://www.gnu.org/copyleft/gpl.html" name="the GNU website">. Puede obtenerla también escribiendo a la Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. Index: documentation/install.fi.sgml === RCS file: /cvs/debian-boot/boot-floppies/documentation/install.fi.sgml,v retrieving revision 1.7 diff -u -r1.7 install.fi.sgml --- documentation/install.fi.sgml 2000/01/26 00:53:04 1.7 +++ documentation/install.fi.sgml 2001/04/06 02:37:27 @@ -117,7 +117,7 @@ tarkemmin asiaa käsitellään GNU General Public Licensessa. GNU General Public Licensesta on kappale &debian -levitysversiossa -tiedostona /usr/doc/copyright/GPL sekä /usr/share/common-licenses/GPL sekä http://www.gnu.org/copyleft/gpl.html" name="GNU:n seittisivustossa">. Voitte myös saada siitä kopion kirjoittamalla osoitteeseen Free Software Foundation, Inc., 59 Temple Place - Suite Index: documentation/install.fr.sgml === RCS file: /cvs/debian-boot/boot-floppies/documentation/install.fr.sgml,v retrieving revision 1.7 diff -u -r1.7 install.fr.sgml --- documentation/install.fr.sgml 2000/09/14 13:23:06 1.7 +++ documentation/install.fr.sgml 2001/04/06 02:37:29 @@ -98,7 +98,7 @@ Générale GNU pour plus de détails. Une copie de la Licence Publique Générale GNU est disponible dans -/usr/doc/copyright/GPL dans la distribution Debian GNU/Linux ou sur +/usr/share/common-licenses/GPL dans la distribution Debian GNU/Linux ou +sur le World Wide Web sur le http://www.gnu.org/copyleft/gpl.html" name="site Web GNU">. Vous pouvez aussi l'obtenir en écrivant à la Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA Index: documentation/install.hr.sgml === RCS file: /cvs/debian-boot/boot-floppies/documentation/install.hr.sgml,v retrieving revision 1.17 diff -u -r1.17 install.hr.sgml --- documentation/install.hr.sgml 2000/07/12 17:24:53 1.17 +++ documentation/install.hr.sgml 2001/04/06 02:37:30 @@ -99,7 +99,7 @@ odgovaranja odreðenoj svrsi. Za detalje pogledajte GNU Opæu javnu licencu. Primjerak GNU Opæe javne licence je dostupan kao -/usr/doc/copyright/GPL u Debian GNU/Linux distribuciji ili WWW-om +/usr/share/common-licenses/GPL u Debian GNU/Linux distribuciji ili WWW-om na http://www.gnu.org/copyleft/gpl.html" name="GNU-ovim stranicama">. Takoðer ga mo¾ete dobiti pisanjem na adresu: Free Software Foundation, Inc., 59 Temple Place — Suite 330, Boston, MA 02111-1307, Index: documentation/install.ja.sgml === RCS file: /cvs/debian-boot/boot-floppies/documentation/install.ja.sgml,v retrieving revision 1.11 diff -u -r1.11 install.ja.sgml --- documentation/install.ja.sgml 2000/07/05 16:16:31 1.11 +++ documentation/install.ja.sgml 2001/04/06 02:37:36 @@ -116,7 +116,7 @@ ¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï GNU °ìÈ̸øÍ»ÈÍѵöÂú½ñ¤ò¤ªÆɤߤ¯¤À¤µ¤¤¡£ GNU °ìÈ̸øÍ»ÈÍѵöÂú¤Î¼Ì¤·¤Ï¡¢Debian GNU/Linux ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Î -/usr/doc/copyright/GPL ¤ä¡¢WWW ¾å¤Ç¤Ï /usr/share/common-licenses/GPL ¤ä¡¢WWW ¾å¤Ç¤Ï http://www.gnu.org/copyleft/gpl.html" name="GNU ¥¦¥§¥Ö¥µ¥¤¥È
Re: initrd filesystem types/sizes
Tim Riker wrote: > > from 2.2.18pre21 with cramfs patch (links are still broken): > > timr@localhost:/lib/modules/2.2.18pre21/fs$ ls -l > total 524 > -rw-r--r--1 root root27057 Jan 23 22:42 cramfs.o > -rw-r--r--1 root root41336 Jan 23 22:42 fat.o > -rw-r--r--1 root root32516 Jan 23 22:42 minix.o > -rw-r--r--1 root root94164 Jan 23 22:42 nfs.o > -rw-r--r--1 root root 5280 Jan 23 22:42 nls_cp437.o > -rw-r--r--1 root root 3568 Jan 23 22:42 nls_iso8859-1.o > -rw-r--r--1 root root 6877 Jan 23 22:42 romfs.o > -rw-r--r--1 root root14874 Jan 23 22:42 vfat.o > > remember that vfat needs fat. > I didnt think of looking there, fat+vfat do add a fair bit of space, but i guess it is the best fs for compatability with other OS's. I think romfs initrd on a vfat formatted image would be good. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: initrd filesystem types/sizes
from 2.2.18pre21 with cramfs patch (links are still broken): timr@localhost:/lib/modules/2.2.18pre21/fs$ ls -l total 524 -rw-r--r--1 root root27057 Jan 23 22:42 cramfs.o -rw-r--r--1 root root41336 Jan 23 22:42 fat.o -rw-r--r--1 root root32516 Jan 23 22:42 minix.o -rw-r--r--1 root root94164 Jan 23 22:42 nfs.o -rw-r--r--1 root root 5280 Jan 23 22:42 nls_cp437.o -rw-r--r--1 root root 3568 Jan 23 22:42 nls_iso8859-1.o -rw-r--r--1 root root 6877 Jan 23 22:42 romfs.o -rw-r--r--1 root root14874 Jan 23 22:42 vfat.o remember that vfat needs fat. Glenn McGrath wrote: > > By the looks of it romfs is the clear winner for space savings. > > 180483 initrd.cram.gz > 161209 initrd.iso.gz > 161023 initrd.ext2.gz > 160621 initrd.minix.gz > 159622 initrd.rom.gz > > romfs adds about 4kB to the kernel when built in > cramfs adds ? > > the initrd filesystem will have to be builtin, which will be smaller > than module size, so these are only usefull for relative comparison to > other modules. > 44599 ext2.o > 30358 minix.o > 24729 isofs.o > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Tim Riker - http://rikers.org/ - short SIGs! All I need to know I could have learned in Kindergarten ... if I'd just been paying attention. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
initrd filesystem types/sizes
By the looks of it romfs is the clear winner for space savings. 180483 initrd.cram.gz 161209 initrd.iso.gz 161023 initrd.ext2.gz 160621 initrd.minix.gz 159622 initrd.rom.gz romfs adds about 4kB to the kernel when built in cramfs adds ? the initrd filesystem will have to be builtin, which will be smaller than module size, so these are only usefull for relative comparison to other modules. 44599 ext2.o 30358 minix.o 24729 isofs.o -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: slang, boot-floppies, and wide character support
> > I've read on this list that David Whedon has already packaged > the bf-utf directory itself. Is this already uploaded ? > Not yet, I'm hoping to sometime soon, it is currently at: http://people.debian.org/~dwhedon/debian/ By the way, if anyone would like to maintain the package that would please me. I only packaged it myself so as to be able to remove it from boot-floppies cvs, as the large size of the files was breaking pserver. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: slang, boot-floppies, and wide character support
Hi. In <[EMAIL PROTECTED]>, on "05 Apr 2001 00:58:56 -0400", with "Re: slang, boot-floppies, and wide character support", Adam Di Carlo <[EMAIL PROTECTED]> wrote: > Taketoshi Sano <[EMAIL PROTECTED]> writes: > > > Akira Yoshiyama <[EMAIL PROTECTED]> who made the patch for termwrap, > > has made the customized boot-floppies for potato used on NEC pc9800 > > series. It uses the patched slang and newt libraries in bf-utf and it > > can be used with Japanese encodings (euc-jp) using some tweaking in > > dbootstrap (euc-jp strings requires special treatment in line break, > > so it uses an auxiliary utility to shrink strings correctly). > > Ok, well, that "auxiliary utility" would need to be available. Can I create shrink_string subdirectory in utilities/dbootstrap/ and put this utility as ja.c ? As far as I see, the modification will be needed on Makefile and boxes.c in dbootstrap/ directory. If there aren't any objections, I'll commit the required modification into woody version. > > The package (in source and binary) is distributed from ftp site of > > Debian JP, and I think we can use the hack in it for woody i18n > > boot-floppies. > > I don't know what this package contains but let me make myself > clear: > > 1) I will *reject* a forked newt/slang being placed in the > boot-floppies sources > 2) the wide version of newt/slang that we need *must* be uploaded to > Debian main, and it must be done *now* I see. I think that forked version of boot-floppies for nec-pc98 just uses the old newt/slang in bf-utf8 without additional change, so if only we can provide the same version in Debian main, there may be no problem as for i18n boot-floppies and euc-jp version. > To restate, any forked or patched newt/slang or other requirements > *must* be placed in the distribution itself. It is no doubt that this is the biggest problem now. > If no one has the time to package the wide libraries, and any other > auxiliary stuff needed for boot-floppies, I have no problem shipping > woody w/o i18, although I think that would be a shame. Especially > after all the time put into it by folks here and by the translators. And we need them for utf-8 dialog, so if we can't provide them, we will not be able to provide the i18n version of the installer even when the debian-installer can replace the current boot-floppies. I had tried to create them before the potato release. But it was already frozen time for potato, and I couldn't rely on me that I did it correct on devel packages (libnewt-dev and slang1-dev), I have not uploaded them. I've read on this list that David Whedon has already packaged the bf-utf directory itself. Is this already uploaded ? If we provide the utf-8 support in base (for i18n'ed base-config) then we may need the slang and newt libraries with utf-8 support, I think. What is the best way ? Just use utf-8 in i18n boot-floppies (i.e. just in dbootstrap only), and ignore it on the installed Debian system, or use utf-8 in the main/installed Debian system as well as the installer ? > > yosshy said that he wishes to see his patches merged > > into the Debian official boot-floppies, but he does not have enough > > time to do it by himself. > > Well, I certainly don't have the time to do it for him. Sure. Since I wish to have i18n (and Japanese supported) installer for Debian, I'll try to extract the required modification from his work and commit them into our official boot-floppies source tree. > > We can support i18n in root disk of boot-floppies currently, > > but since woody debconf and base-config supports i18n, it > > will be nice if we can support i18n on base system as well. > > > > Can bogl-bterm be used for base system i18n in woody ? > > Are we safe to include it in base tar ball ? > > (Well, this is debootstrap topic, but it is needed for i18n > > goal of Debian installation, and this experience will work > > for debian-installer as well). > > I don't see any problem with this -- what are the risks? I don't know how well tested the bogl-bterm is. Just wonder. And I think the current packages including base-config has messages for Japanese in euc-jp, not in utf-8, so we need some work if we use utf-8 to show the messages with bogl-bterm. When slang/newt dialog is used in base-config (maybe via debconf ?), we also need utf-8 support from slang/newt in the installed (main) Debian system. > > And if we use utf-8 for all messages, then we have to use > > encoding conversion at somewhere since most packages have > > messages not in utf-8 but in euc-jp for japanese. > > I recall there was a reported problem also with config files written > by dbootstrap in i18n mode being writting as utf-8 files and that > messing up the desired configuration Well, so there may be softwares which can not handle the config files written in utf-8 encoding. If we use utf-8 as main encoding in Debian, we need to work on them. -- Taketoshi Sano: <[EMAIL PROTECT
Re: still not out of the woods with idepci / compact kernels
Hi. In <[EMAIL PROTECTED]>, on "05 Apr 2001 00:50:18 -0400", with "Re: still not out of the woods with idepci / compact kernels", Adam Di Carlo <[EMAIL PROTECTED]> wrote: > > BTW, I have heard that the boot option "video=vga16:off" works well. > > So I think we should note this option in the place of "video=vc:8" > > in $LANG/f5.txt above. > > Go ahead, patch it. OK, I'll try. > > frame buffer support is essential for bogl-bterm for utf-8 and > > jfbterm for euc-jp. So if there is no official kernel with frame > > buffer support, then i18n boot floppies will die before going real. > > The compact and idepci kernels have framebuffer support. Why would we > wanna turn that off ? Thanks. I want to make sure it. > My big worries is that we don't have a libnewt or a libslang at all > right now. Sure. -- Taketoshi Sano: <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#93054: eliminate wait after downloading files
Package: boot-floppies
Version: N/A; 2.2.22-2001-04-02
After downloading rescue.bin, drivers.tgz, and base2_2.tgz from
the network, dbootstrap waits for around two minutes. That is,
the progress indication screen indicates that the file is
completely downloaded, but the log message indicating that the
file is downloaded does not appear.
I believe that it is waiting for the connection to close, and when
the connection times out it returns and proceeds. Looking at
busybox wget, it appears that one solution is to send the
Connection: close
header to encourage the server to close the connection once it
finishes sending. The following patch implements this.
Matt
--- http-fetch.c.orig Thu Apr 5 14:11:10 2001
+++ http-fetch.cThu Apr 5 14:12:05 2001
@@ -321,13 +321,13 @@
/* changed \n\n to \r\n to better match the spec -randolph */
if (use_proxy) {
snprintf (buf, sizeof (buf) - 1,
- "GET http://%s:%d/%s/%s HTTP/1.1\r\nHost: %s:%d\r\n",
+ "GET http://%s:%d/%s/%s HTTP/1.1\r\nHost: %s:%d\r\nConnection:
+close\r\n",
server_host, server_port, remote_path, remote_filename,
server_host, server_port);
}
else {
snprintf (buf, sizeof (buf) - 1,
- "GET /%s/%s HTTP/1.1\r\nHost: %s:%d\r\n",
+ "GET /%s/%s HTTP/1.1\r\nHost: %s:%d\r\nConnection: close\r\n",
remote_path, remote_filename,
server_host, server_port);
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#92919: no subject)
Yes. You have saved us money and time - enable PNP is the fix. This does not appear in any documentation I found. Thank you. --Jeff On Wed, 4 Apr 2001, Hendrik Schaink wrote: > Helllo Jeffery, > > You, Jeffery Kline wrote: > > > Package: kernel-image > > Package: boot-floppies > > Version: kernel versions 2.2.12 thru 2.2.18pre21 > > > > Cannot install smc-ultra module. error includes: > > > > /lib/modules/2.2.17/net/smc-ultra.o: init_module: Device or resource busy > > Hint: insmod errors can be caused by incorrect module parameters, > > including invalid IO or IRQ parameters > > /lib/modules/2.2.17/net/smc-ultra.o: insmod /lib/modules/2.2.17/net/smc-ultra.o >failed > > /lib/modules/2.2.17/net/smc-ultra.o: insmod smc-ultra failed > > > > We have the correct io and irq params from each card (collected from dmesg > > while running slink and using the slightly different output we get when > > using the DOS utilities disk) -- we get the same error with both insmod > > (after installing 8390, of course) and modprobe. We have compiled new > > kernels with smc-ultra.o module and compiled smc-ultra support into the > > kernel. We have attempted every combination of io/irq settings available > > with modprobe and insmod (even settings we knew to be incorrect). We have > > tried using the safe-boot floppies. We reported this bug last July. Net > > searches produce minimal help and offer no new suggestions. Three of our > > staff have tried to solve this problem since April 2000. > > > > We are stumped. > > > > The cards _do_ work with slink. We have about 15 machines we wish to > > upgrade to potato. > > We had very much the same experiences with our SMC8416 NICs. The solution we found >that > worked was to *turn on* the SMC8416 Plug-and-Play setting and use the ISApnp >utilities to > initialize the card(s). The downside of this solution: if you perform a reboot >without > powering down the computer, the isapnp utilities fail to initialize the SMC NICs, so >a > full power down must be performed every time a reboot is necessary. Our SMC NICs >have been > performing well. > > Hope this helps you out. > > Hendrik Schaink > > > -- > Hendrik M. Schaink > Prop. & Chief Consultant > > InfoVision Consulting "Small Business Solutions & Dependable Service" > Calgary, Alberta, Canada > Phone: (403) 239-0099 > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Boot-floppies for Woody
Thomas Guettler <[EMAIL PROTECTED]> writes: > > Don't use the woody branch. > > That's what I did. I checked out the project boot-floppies without > parameters. If I read the Archive correctly this gives me the > woody-branch since some days. No, that's called the HEAD. Taht is indeed what you are supposed to be using. I still don't understand how you can be getting the error you say you're getting. > Is it recommended to use the > potato-branch for building woody-CD's (That's what I want to do)? Well, you could try it, if you just want something now. I know that the potato branch does build in potato, and the woody branch doesn't yet build at all. -- .Adam Di [EMAIL PROTECTED]http://www.onshored.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Woody installer for PARISC
Hello everyone,
Here are the changes I've made to the boot-floppies package to support
the PARISC architecture.
Makefile:
Added an entry for hppa support, make root.tar.gz
common.sh:
Small fixes to the functions that came up during debugging
rescue.sh:
- Define the hppa "floppy" type (ext2)
- Use the "write_m68kinfo" for install.sh generation
- Compress the kernel like powerpc/pmac arch
rootdisk.sh:
- Define the C library information for hppa
- Don't do library reduction (this was failing with our binutils)
utilities/dbootstrap/Makefile:
- Change the -DKVER="${KVER}" to -DKVER="${kver}" to reflect the proper
variable name.
utilities/dbootstrap/bootconfig.c:
- Support for PALO (our bootloader)
utilities/dbootstrap/extract_base.c:
- Change debootstrap cmd line to use file:%s instead of just %s.
utilities/dbootstrap/main_menu.c:
- Remove options that aren't applicable to PARISC.
(Make boot floppy, PCMCIA, etc..)
utilities/dbootstrap/partition_config.c:
- Add PALO message for partition creation.
There are a few more changes I needed to make to get a working installer
for PARISC, unfortunately some of them are because of limitations in
the current PARISC distribution (kernel.sh was modified to not require
a kernel .deb since we currently don't have one and the constantly
changing kernel makes it unwieldy to build kernel .debs). As well the
root.bin needs to be larger than 3700K on parisc though I am working
on reducing this number to hopefully fit in that limit.
I will post a diff to boot-floppies shortly.
- Paul
PGP signature
No Subject
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Boot-floppies for Woody
On Thu, Apr 05, 2001 at 12:48:43AM -0400, Adam Di Carlo wrote: > Thomas Guettler <[EMAIL PROTECTED]> writes: > > > I try to build boot-floppies for woody. I checked out the source from > > CVS. > > > I get the following error: > > > > E: no such library './lib/ld-2.1.3.so' > > E: ./rootdisk.sh abort > > Probably rootdisk.sh has an error. Poke around in there and try to > fix it. Perhaps it should be looking for ld-2.2.2.so ? Look at the > 'ldlib' var setting. > > Are you sure you're working from the HEAD of the CVS area? I don't > see anything setting ldlib to ld-2.1.3. > Don't use the woody branch. That's what I did. I checked out the project boot-floppies without parameters. If I read the Archive correctly this gives me the woody-branch since some days. Is it recommended to use the potato-branch for building woody-CD's (That's what I want to do)? I had problems with the potato-boot-disks for woody installation rescue.bin and drivers.tgz were missing. I build the CDs using the debian-cd package. -- Thomas Guettler <[EMAIL PROTECTED]> http://yi.org/guettli -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Unidentified subject!
unsubscribe [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: modconf doesn't support 2.4.2 kernel? critical typo corrected
The lines << were omitted from the previous transmission > Ivan If a PCMCIA LAN bus card is the issue, carefully read /usr/src/modules/pcmcia-cs/README-2.4, as the kernel Configure.help is not adequate in this instance. For support of my: # cardctl ident 1 product info: "3Com Corporation", "3CCFE575BT", "LAN Cardbus Card", "001" manfid: 0x0101, 0x5157 function: 6 (network) PCI id: 0x10b7, 0x5157 it was necessary to compile the kernel with: grep PCMCIA /boot/config-2.4.2 < # PCMCIA/CardBus support # CONFIG_PCMCIA is not set <<< after which one CAN still compile PCMCIA modules in the old 2.2.nn style, with my module support through: #lsmod Module Size Used by 3c575_cb 20032 2 cb_enabler 2736 2 [3c575_cb] ds 6768 2 [cb_enabler] i82365 23216 2 pcmcia_core43392 0 [cb_enabler ds i82365] The down side is that with the old 2.2.nn method the who zoo of PCMCIA support modules is generated, while if suffices to use: # PCMCIA/CardBus support # CONFIG_PCMCIA=y then only necessary modules can be specified for compiling. Once compiled and installed in the /lib/modules/2.4.nn tree modconf does properly perceive these modules. MarvS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: modconf doesn't support 2.4.2 kernel?
Ivan If a PCMCIA LAN bus card is the issue, carefully read /usr/src/modules/pcmcia-cs/README-2.4, as the kernel Configure.help is not adequate in this instance. For support of my: # cardctl ident 1 product info: "3Com Corporation", "3CCFE575BT", "LAN Cardbus Card", "001" manfid: 0x0101, 0x5157 function: 6 (network) PCI id: 0x10b7, 0x5157 it was necessary to compile the kernel with: after which one CAN still compile PCMCIA modules in the old 2.2.nn style, with my module support through: #lsmod Module Size Used by 3c575_cb 20032 2 cb_enabler 2736 2 [3c575_cb] ds 6768 2 [cb_enabler] i82365 23216 2 pcmcia_core43392 0 [cb_enabler ds i82365] The down side is that with the old 2.2.nn method the who zoo of PCMCIA support modules is generated, while if suffices to use: # PCMCIA/CardBus support # CONFIG_PCMCIA=y then only necessary modules can be specified for compiling. Once compiled and installed in the /lib/modules/2.4.nn tree modconf does properly perceive these modules. MarvS >[EMAIL PROTECTED] wrote: > > Hi, > > I have read that Modconf doesn't support 2.4.(0,1) kernels. As far as I > experienced, it doesn't work with the 2.4.2 neither. > > I wanted to know if there was a solution, cause I didn't find any, since I > don't even know the reason why it doesn't work with 2.4.x. > > Please let me know if there is a way to make Modconf work, or otherwise > where I can find how to configure my NIC since it is only recognized with > the latests kernels, and when I compile and install a new one, I don't have > any network anymore. > > Thanks a lot guys, > > see you, > > Ivan ROBAIN > ATOS - Support Projet > tél : 01 70 92 47 13 > e-mail : [EMAIL PROTECTED] > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anonymous CVS checkout broken?
Thu, Apr 05, 2001 at 02:15:23AM -0600 wrote: > On Sun, Mar 25, 2001 at 05:19:54PM -0500, Adam Di Carlo wrote: > > After that, all techniques are the same. Simply check out the > > sources. For the lastest Potato version, do: > > > >cvs co -r potato boot-floppies > > > > Note that Potato is on a branch now for maintenance only. > > While attempting to check out Potato boot-floppies to see if I can help > getting the "newworld" PPC machines to be bootable from dbootstrap, > I fumbled across this problem: > > > cvs server: Updating boot-floppies/utilities > cvs server: Updating boot-floppies/utilities/bf-utf > cvs [server aborted]: out of memory; can not allocate 34 bytes > cvs [server aborted]: out of memory; can not allocate 79 bytes > > It does this at the same point in the checkout every time. We only sort of solved this problem. It was solved for woody by removing the large font files tht pserver couldn't handle. I doubt we'll try to fix potato. It would be great to get some help. You can check out the trunk and help with woody. # cvs co boot-floppies David > > I assume the "[server aborted]" means the problem's not on my end, but > if I'm doing something wrong, let me know. I used the above information > from Adam to do the checkout. > > Otherwise, any workarounds for this? I thought I remembered seeing some > discussion of something similar last week or the week before on the > list, but I can't remember and couldn't find it in the archives. > > [Of course, I have no idea if I can even help much yet which is why I > was using anonymous pserver access -- I want to get familiar with the code > first, and don't know how long that'll take. There's probably little > chance I'll be able to get this into Potato, but one never knows... > I am somewhat familiar with the boot process on the newworld ppc machines > now that I have a new iMac in my little Debian family, but wouldn't say > I'm an "expert" by any means... but might as well give it a shot. Worst > that can happen is that I'll learn something while hopefully not wasting > too much of anyone's time.] > > p.s. It was a lot of fun to show off Debian running on FOUR platforms > (PA-RISC, i386, Sparc, PPC) at the Colorado Linux Info Quest convention > last week... anything to make the Debian installations better on the > "lesser used" platforms, I'm happy to try to do! > > -- > Nate Duehr <[EMAIL PROTECTED]> > > GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2 > Public Key available upon request, or at wwwkeys.pgp.net and others. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: modconf doesn't support 2.4.2 kernel?
Am Donnerstag, 5. April 2001 16:47 schrieb [EMAIL PROTECTED]: > Hi, > > I have read that Modconf doesn't support 2.4.(0,1) kernels. As far as I > experienced, it doesn't work with the 2.4.2 neither. > > I wanted to know if there was a solution, cause I didn't find any, since I > don't even know the reason why it doesn't work with 2.4.x. > > Please let me know if there is a way to make Modconf work, or otherwise > where I can find how to configure my NIC since it is only recognized with > the latests kernels, and when I compile and install a new one, I don't have > any network anymore. you can add deb-src ftp://ftp.de.debian.org/debian woody main contrib non-free to your /etc/apt/sources.list and do a apt-get --compile source modconf while beeing online, and you will get a uptodate modconf__.deb cu Bert [EMAIL PROTECTED] http://www.eye-pi.com Tel: 02174/768697 Fax: 02174/768699 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
modconf doesn't support 2.4.2 kernel?
Hi, I have read that Modconf doesn't support 2.4.(0,1) kernels. As far as I experienced, it doesn't work with the 2.4.2 neither. I wanted to know if there was a solution, cause I didn't find any, since I don't even know the reason why it doesn't work with 2.4.x. Please let me know if there is a way to make Modconf work, or otherwise where I can find how to configure my NIC since it is only recognized with the latests kernels, and when I compile and install a new one, I don't have any network anymore. Thanks a lot guys, see you, Ivan ROBAIN ATOS - Support Projet tél : 01 70 92 47 13 e-mail : [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#92907: [dbootstrap] net-fetch log message improvements
Matt Kraai <[EMAIL PROTECTED]> writes: > Out of curiosity, when are boot-floppies bugs closed (as opposed > to fixed)? With the next major release? When the version are installed into the archive, like any other package. -- .Adam Di [EMAIL PROTECTED]http://www.onshored.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NewWorld dbootstrap bootloader installation info
On Thu, Apr 05, 2001 at 02:15:23AM -0600, Nate Duehr wrote: > [Of course, I have no idea if I can even help much yet which is why I > was using anonymous pserver access -- I want to get familiar with the code > first, and don't know how long that'll take. There's probably little > chance I'll be able to get this into Potato, but one never knows... > I am somewhat familiar with the boot process on the newworld ppc machines > now that I have a new iMac in my little Debian family, but wouldn't say > I'm an "expert" by any means... but might as well give it a shot. Worst > that can happen is that I'll learn something while hopefully not wasting > too much of anyone's time.] OK here is the deal with NewWorlds: they have no form of bootblock/bootsector whatsoever, so one has to be made by creating an 800K type Apple_Bootstrap partition at the start of the disk preferably (so it will be used by default instead of any present MacOS partitions). this is currently fully the users responsibility along with the rest of the partitioning. i think it would be helpful to yell at the user if they forget to create the bootstrap partition correctly, since if they don't there is no way for `make bootable from disk' can ever work. dbootstrap needs to know the following: * which partition is the bootstrap partition, i imagine this should be found by looking for a type Apple_Bootstrap partition on the disk and confirming the choice with the user. (somewhat similar to the MBR location choice in lilo) * the disk being installed on (already known) * the root partition (already known) * the partition number of the root partition (ie the 3 from /dev/hda3) * the OpenFirmware device path to the root disk. this can be found by executing `ofpath /dev/hda` at this point dbootstrap can do one of two things: 1) run mkofboot passing all of the above information to it via command line switchs/arguments. mkofboot would then generate a minimal config on the fly to be installed into the bootstrap. this config however is ironically not complete enough to be used as an /etc/yaboot.conf and is not saved on the filesystem anyway (i am open to changing this behavior) 2) generate a /target/etc/yaboot.conf and execute `mkofboot -f -C /target/etc/yaboot.conf` i tend to think the second option is more appropriate, but an alternative to that is to fix mkofboot to generate a complete yaboot.conf and have an option to save the file somewhere, say --save /target/etc/yaboot.conf. i am not terribly enthusiastic about this idea but not totally opposed to it. mkofboot when provided the above information takes care of everything required to make the disk completely bootable, it installs the yaboot bootloader, the yaboot.conf file and a auto generated OpenFirmware script into the bootstrap partition and performs all necessary witchcraft to make OpenFirmware boot it from factory settings (assuming the bootstrap partition is the first bootable candidate on the disk) additionally mkofboot will explicity set the OpenFirmware boot-device variable to the bootstrap partition guarenteeing it will be booted on the next reboot. from the above information dbootstrap needs to know here is an example /target/etc/yaboot.conf that would need to be generated: in this example bootstrap = /dev/hda2 root = /dev/hda3 boot=/dev/hda2 device=hd: partition=3 timeout=20 install=/usr/lib/yaboot/yaboot magicboot=/usr/lib/yaboot/ofboot image=/vmlinux label=linux root=/dev/hda3 read-only root=/dev/hda3 can be moved to the global section if that is preferred. note that this is only going to work on a NewWorld PowerMac, Oldworlds need quik and they need some significant witchcraft and unholy incantations shot into the OpenFirmware configuration before they will even think about booting in many cases. i think we need an entire utility written to detect the particular oldworld model and determine what OF configuration and nvramrc patches are required (these patches are unfortunatly non-free) frankly i think a `make bootable' step that works on oldworlds is a pipe dream, its unlikely to ever be all that reliable given that oldworld OF is sooo b0rken. the other major powerpc sub arch is the IBM machines, they have a bootstrap partition where yaboot is simply dded to it, ybin 1.0 will do this as well now. but it currently does not have ofpath support for these, or nvram reconfiguration (which may not be needed anyway) we don't even have working boot floppies for these atm anyway. anyway if you or anyone else wants to persue this that would be great, feel free to ask me any questions, i am pretty much the resident expert on PowerMac bootloaders. i am also the upstream maintainer of ybin (mkofboot and ofpath are part of ybin). -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Anonymous CVS checkout broken?
On Sun, Mar 25, 2001 at 05:19:54PM -0500, Adam Di Carlo wrote: > After that, all techniques are the same. Simply check out the > sources. For the lastest Potato version, do: > >cvs co -r potato boot-floppies > > Note that Potato is on a branch now for maintenance only. While attempting to check out Potato boot-floppies to see if I can help getting the "newworld" PPC machines to be bootable from dbootstrap, I fumbled across this problem: cvs server: Updating boot-floppies/utilities cvs server: Updating boot-floppies/utilities/bf-utf cvs [server aborted]: out of memory; can not allocate 34 bytes cvs [server aborted]: out of memory; can not allocate 79 bytes It does this at the same point in the checkout every time. I assume the "[server aborted]" means the problem's not on my end, but if I'm doing something wrong, let me know. I used the above information from Adam to do the checkout. Otherwise, any workarounds for this? I thought I remembered seeing some discussion of something similar last week or the week before on the list, but I can't remember and couldn't find it in the archives. [Of course, I have no idea if I can even help much yet which is why I was using anonymous pserver access -- I want to get familiar with the code first, and don't know how long that'll take. There's probably little chance I'll be able to get this into Potato, but one never knows... I am somewhat familiar with the boot process on the newworld ppc machines now that I have a new iMac in my little Debian family, but wouldn't say I'm an "expert" by any means... but might as well give it a shot. Worst that can happen is that I'll learn something while hopefully not wasting too much of anyone's time.] p.s. It was a lot of fun to show off Debian running on FOUR platforms (PA-RISC, i386, Sparc, PPC) at the Colorado Linux Info Quest convention last week... anything to make the Debian installations better on the "lesser used" platforms, I'm happy to try to do! -- Nate Duehr <[EMAIL PROTECTED]> GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2 Public Key available upon request, or at wwwkeys.pgp.net and others. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
