Re: prep with matrox millenium == out of scan range when booting kernel?!

2002-05-03 Thread Chris Tillman

On Fri, May 03, 2002 at 11:17:26AM +0200, Rubin wrote:
> Hello People,
> 
> As I've posted before, I have modern debian 3.0 booting succesfully on a 
>  Bull Estrella Series 300 (aka Motorola Powerstack II 4000/Pro).
> 
> After some investigations it turned out that the vga card is severely 
> out of date (a Cirrus Logic GD5446 /w 256k of ram ;-). Ofcourse, this 
> machine needs a cool graphics card so my first try was a Diamond FireGL 
> 3000 with fully loaded texture board (32mb)... The machine refused to 
> come up (probably because it is anything but "standard" vga"). So as a 
> second best, I chose my trusty Matrox Millenium II /w 4mb ram. The sytem 
> agreed, and comes up nicely into the openfirmware screen and presents 
> the usual bootup and diagnostics options.
> 
> But alas, it was all too good to be true; As soon as the bootloader (I 
> think quik) loads, the screen goes black and a second later my monitor 
> states "Out Of Scan Range"... Mmmm.. I tried and reproduced this with 
> the older (2.2 potato) and newer (3.0 testing).
> I'm pretty sure this has to do with the bootloader of debian but I don't 
> know how to resolve this!
> 
> Interresting enough, running the yaboot bootloader from the ydl 2.2 cd 
> inits the screen properly and presents me a boot: prompt; Alas, I seem 
> to be unable to use it to boot my system with as it always returns "No 
> Such File Or directory" or a "Corrupt Or Invalid Partition"..
> 
> If anybody has any suggestions, please let me know. I'll keep hacking at 
> it and post whatever I'll find out next ;-)

Addng video=ofonly to the boot arguments is worth a try.

I've also seen some sophisticated video boot arguments posted to 
-powerpc in the past, you might check out the archives.

-- 
*--v- Installing Debian GNU/Linux 3.0 v--*
|    |
|   debian-imac (potato):    |
|Chris Tillman[EMAIL PROTECTED]  |
|   May the Source be with you   |
**


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: About the infinite loop

2002-05-03 Thread Adam Warner

On Sat, 2002-05-04 at 12:14, Joey Hess wrote:

> It didn't help that the broken base-config was itself a rushed fix for
> an earlier broken base-config, which was itself a rushed workaround for a
> hasty change in the boot-floppies, so I did even less testing on that
> release than I usually manage for base-config.

Which fully explains how the broken package got into woody. Thanks Joey
for all your work. Let's hope the latest rushed fix is OK :-)

> We have to be aware that boot-floppies and base-config receive little or
> no testing before they enter testing. I am painfully aware of that. I am
> thinking about ways to do semiautomated base-config testing before I
> release it, but short of a full install it is hard to be sure testing it
> in a chroot or such hits all cases.

Perhaps plex86 developments will soon be helpful. You would then be able
to simulate an install in a virtual environment. You would probably even
be able to save a memory image at any point in time. So you could save
the image just before a new package you are testing is installed. You
might then be able to fire up the image and install the new package and
test it without having to go through all of the preliminary install
steps nor need a separate machine for testing.

Regards,
Adam



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: About the infinite loop

2002-05-03 Thread Joey Hess

Adam Warner wrote:
> How did this bug almost get into the offical release of Woody? Was the
> package tested before being distributed?

It didn't help that the broken base-config was itself a rushed fix for
an earlier broken base-config, which was itself a rushed workaround for a
hasty change in the boot-floppies, so I did even less testing on that
release than I usually manage for base-config.

We have to be aware that boot-floppies and base-config receive little or
no testing before they enter testing. I am painfully aware of that. I am
thinking about ways to do semiautomated base-config testing before I
release it, but short of a full install it is hard to be sure testing it
in a chroot or such hits all cases.

-- 
see shy jo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




cvs commit to boot-floppies/utilities/dbootstrap/po by jordi

2002-05-03 Thread Debian Boot CVS Master

Repository: boot-floppies/utilities/dbootstrap/po
who:jordi
time:   Fri May  3 16:00:36 PDT 2002
Log Message:
  Small fix.
  

Files:
changed:ca.po


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: About the infinite loop

2002-05-03 Thread Adam Warner

On Sat, 2002-05-04 at 02:14, Eduard Bloch wrote:



> > We know that the biggest problem with testing Debian installers is that
> > hardly anyone needs to use them. The idea of doing a new install instead
> > of using the package management system to perform an upgrade is foreign
> > to most users and developers.
> 
> What do you mean with "new install"?

Not doing a dist-upgrade of an existing system. Case in point: The only
reason I discovered this infinite loop and rushed to report it is
because I was replacing a FreeBSD install. If I had continued to do
dist-upgrades I would never have discovered that the woody install was
broken.

Regards,
Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




cvs commit to boot-floppies/documentation/ca by jordi

2002-05-03 Thread Debian Boot CVS Master

Repository: boot-floppies/documentation/ca
who:jordi
time:   Fri May  3 15:13:25 PDT 2002
Log Message:
  Catalan updates.
  

Files:
changed:hardware.sgml welcome.sgml


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




boot-floppies_3.0.22_sparc.changes REJECTED

2002-05-03 Thread Debian Installer


Rejected: a changes file with the same name already exists in the Done directory.
Rejected: install-doc_3.0.22_sparc.deb: old version (3.0.22) >= new version (3.0.22).
Rejected: can not overwrite existing copy of 'install-doc_3.0.22_sparc.deb' already in 
the archive.
Rejected: md5sum and/or size mismatch on existing copy of install-doc_3.0.22_sparc.deb.


===

If you don't understand why your files were rejected, or if the
override file requires editing, reply to this email.

Your rejected files are in incoming/REJECT/.  (Some may also be in
incoming/ if your .changes file was unparsable.)  If only some of the
files need to repaired, you may move any good files back to incoming/.
Please remove any bad files from incoming/REJECT/.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




[Patch] debian-installer/tools/ddetect : mdmdetect and memdetect

2002-05-03 Thread Thomas Poindessous

Hi, another patch (which works) :

Index: mdmdetect.c
===
RCS file: /cvs/debian-boot/debian-installer/tools/ddetect/mdmdetect.c,v
retrieving revision 1.3
diff -u -r1.3 mdmdetect.c
--- mdmdetect.c 2000/12/06 07:08:33 1.3
+++ mdmdetect.c 2002/05/03 18:54:06
@@ -6,7 +6,7 @@
 
 
 #include 
-#include 
+#include 
 #include 
 
 #include "mdmdetect.h"
Index: memdetect.c
===
RCS file: /cvs/debian-boot/debian-installer/tools/ddetect/memdetect.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 memdetect.c
--- memdetect.c 2000/11/25 21:13:55 1.1.1.1
+++ memdetect.c 2002/05/03 18:54:06
@@ -6,7 +6,7 @@
 
 
 #include 
-#include 
+#include 
 #include 



And just a thing, maybe it would be a good idea to auto-generate all the
.h in the makefile

Thanks.

-- 
Thomas Poindessous
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: [Patch] debian-installer/tools/ddetect/cddetect.c

2002-05-03 Thread Thomas Poindessous

Le ven 03/05/2002 à 17:10, thomas poindessous a écrit :
> Hi,
> another patch. In this patch, I have disabled isa_detect because for the
> moment, discover doesn't support it.

Ok, sorry for this one. Don't apply it, it's just wrong.
 
-- 
Thomas Poindessous
[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: prep with matrox millenium == out of scan range when booting kernel?!

2002-05-03 Thread Brett Carter

I'm not too familiar with PReP hardware, but the install page:
http://www.debian.org/ports/powerpc/inst/prep
claims that the kernel will fall back to a serial console if the video
is broken.  Sounds like you might need a newer bootloader, or maybe
even just a 'video=matroxfb' config line.
-Brett

> "rubin" == rubin  <[EMAIL PROTECTED]> writes:

rubin> Hello People, As I've posted before, I have modern debian
rubin> 3.0 booting succesfully on a Bull Estrella Series 300 (aka
rubin> Motorola Powerstack II 4000/Pro).


rubin> After some investigations it turned out that the vga card
rubin> is severely out of date (a Cirrus Logic GD5446 /w 256k of
rubin> ram ;-). Ofcourse, this machine needs a cool graphics card
rubin> so my first try was a Diamond FireGL 3000 with fully loaded
rubin> texture board (32mb)... The machine refused to come up
rubin> (probably because it is anything but "standard" vga"). So
rubin> as a second best, I chose my trusty Matrox Millenium II /w
rubin> 4mb ram. The sytem agreed, and comes up nicely into the
rubin> openfirmware screen and presents the usual bootup and
rubin> diagnostics options.


rubin> But alas, it was all too good to be true; As soon as the
rubin> bootloader (I think quik) loads, the screen goes black and
rubin> a second later my monitor states "Out Of Scan
rubin> Range"... Mmmm.. I tried and reproduced this with the older
rubin> (2.2 potato) and newer (3.0 testing).

rubin> I'm pretty sure this has to do with the bootloader of
rubin> debian but I don't know how to resolve this!


rubin> Interresting enough, running the yaboot bootloader from the
rubin> ydl 2.2 cd inits the screen properly and presents me a
rubin> boot: prompt; Alas, I seem to be unable to use it to boot
rubin> my system with as it always returns "No Such File Or
rubin> directory" or a "Corrupt Or Invalid Partition"..


rubin> If anybody has any suggestions, please let me know. I'll
rubin> keep hacking at it and post whatever I'll find out next ;-)


rubin> Grtz,

rubin> Rubin.


rubin> -- To UNSUBSCRIBE, email to
rubin> [EMAIL PROTECTED] with a subject of
rubin> "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




cvs commit to boot-floppies/documentation by cklin

2002-05-03 Thread Debian Boot CVS Master

Repository: boot-floppies/documentation
who:cklin
time:   Fri May  3 09:57:33 PDT 2002
Log Message:
  Syncing with English version 1.134
  

Files:
changed:release-notes.zh_TW.sgml


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




[Patch] debian-installer/tools/ddetect/cddetect.c

2002-05-03 Thread thomas poindessous

Hi,
another patch. In this patch, I have disabled isa_detect because for the
moment, discover doesn't support it.

Here is the patch :

Index: cddetect.c
===
RCS file: /cvs/debian-boot/debian-installer/tools/ddetect/cddetect.c,v
retrieving revision 1.2
diff -u -r1.2 cddetect.c
--- cddetect.c  2000/11/30 04:04:34 1.2
+++ cddetect.c  2002/05/03 15:04:42
@@ -6,10 +6,10 @@
 
 
 #include 
-#include 
+#include 
 #include 
 
-#include "cddetect.h"
+/* #include "cddetect.h" */
 #include "ddetect.h"
 
 int
@@ -17,22 +17,26 @@
 {
   struct bus_lst bus = { 0 };
   struct cdrom_info *cdrom = (struct cdrom_info *) NULL;
-  int i = 0;
+/*  int i = 0; */
 
   ddetect_getopts (argc, argv);
 
   sync ();
 
+  /* libdiscover doesn't support isa_lst */
+  /*
   while (lst[i].vendor)
 {
   lst[i].next = &lst[++i];
 }
   lst[i - 1].next = NULL;
-
+  */
   bus.ide = ide_detect ();
   bus.scsi = scsi_detect ();
-  if (!passive_detection)
+  /*
+   if (!passive_detection)
 bus.isa = isa_detect (lst);
+  */
 
 
   if (((cdrom = cdrom_detect (&bus)) != NULL) && (debug == 1))

===

Thanks.

-- 
Thomas Poindessous
[EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




[Patch] debian-installer/tools/ddetect : cpu_detect

2002-05-03 Thread thomas poindessous

Hi,

just a very little patch for cpu_detect and libdiscover. It works on my
system.

Index: cpudetect.c
===
RCS file: /cvs/debian-boot/debian-installer/tools/ddetect/cpudetect.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 cpudetect.c
--- cpudetect.c 2000/11/25 21:13:54 1.1.1.1
+++ cpudetect.c 2002/05/03 14:50:16
@@ -6,7 +6,7 @@
 
 
 #include 
-#include 
+#include 
 #include 
 
 #include "ddetect.h"


-- 
Thomas Poindessous
[EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Patch for debian-installer (switch to discover)

2002-05-03 Thread thomas poindessous

Hi, I read that you are switching from libdetect to discover. I tried to
compile ddetect and it didn't work because the switch wan't finished.

Here is a patch to switch to discover :

Index: Makefile
===
RCS file: /cvs/debian-boot/debian-installer/tools/ddetect/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- Makefile2002/04/27 19:42:08 1.9
+++ Makefile2002/05/03 14:19:43
@@ -11,8 +11,8 @@
 INSTALL=install
 STRIPTOOL=strip
 STRIP = $(STRIPTOOL) --remove-section=.note --remove-section=.comment 
-INCS=-I../cdebconf/src/
-LDFLAGS=-L../cdebconf/src/ -ldiscover -lisapnp -ldebconf
+INCS=-I../cdebconf/debian/build/src/
+LDFLAGS=-L../cdebconf/debian/build/src/ -ldiscover -ldebconf
 
 
 all: lst2header $(OBJS) $(PROGS)
@@ -30,7 +30,7 @@
$(CC) $< -o $@ $(OBJS) $(CFLAGS) $(INCS) $(LDFLAGS)
 
 lst2header: lst2header.c
-   $(CC) lst2header.c -o lst2header -ldiscover -lisapnp 
+   $(CC) lst2header.c -o lst2header -ldiscover
 
 clean:
$(RM) *.o $(PROGS) lst2header
Index: ethdetect.c
===
RCS file: /cvs/debian-boot/debian-installer/tools/ddetect/ethdetect.c,v
retrieving revision 1.9
diff -u -r1.9 ethdetect.c
--- ethdetect.c 2001/01/30 09:16:58 1.9
+++ ethdetect.c 2002/05/03 14:19:43
@@ -8,7 +8,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include "utils.h"
Index: lst2header.c
===
RCS file: /cvs/debian-boot/debian-installer/tools/ddetect/lst2header.c,v
retrieving revision 1.3
diff -u -r1.3 lst2header.c
--- lst2header.c2001/01/03 06:54:11 1.3
+++ lst2header.c2002/05/03 14:19:43
@@ -10,7 +10,7 @@
 #include 
 #include 
 
-#include "detect.h"
+#include 
 
 
 #define PATH_ISA_LST "lst/isa.lst"
@@ -65,7 +65,7 @@
 }
 
   /* Initialize hardware device list  */
-  lst = init_lst (PATH_ISA_LST, PATH_PCI_LST, PATH_PCMCIA_LST, PATH_USB_LST);
+  lst = init_lst (PATH_PCI_LST, PATH_PCMCIA_LST, PATH_USB_LST);
 
   time (&t);
   printf ("/* \tThis file generated on %s", ctime (&t));

--

I have changed the path to cdebconf because it didn't compile. But maybe I
didn't do the right thing (./debian/rules build in tools/cdebconf/)

And it would be a good thing if somebody write a doc about debian-installer
and a TODO list.

Thanks.

-- 
Thomas Poindessous
[EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: About the infinite loop

2002-05-03 Thread Eduard Bloch

#include 
Adam Warner wrote on Fri May 03, 2002 um 09:03:01PM:

> So the unstable check doesn't work for this package because the install
> disks only download woody anyway. But when something goes wrong we still

Yes. We should make a policy that every package build with Priority=high
or which is not supposed for daily use has to be built in a clean
(frozen/testing) environment and not on the maintainers system.

> "On the upside, woody itself is ready to be released."
> 
>http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200204/msg00020.html
> 
> But what _would_ be good timing for the release Eduard? Perhaps
> everybody is simply feeling pressure because it has been so long since
> the last release.

This pressure is caused by some kind wrong handling of development
threes. 

 - There is currently no unstable where you can really test new stuff
   without risking to get it into Testing.
 - OTOH Testing is expected to be allways in releaseable state while
   there is no chance to test some packages that are targeted for
   end-use, such as base-config.

> > > If there is no mechanism to roll back to earlier packages that are know
> > > to work when something really bad goes wrong, why not?
> 
> [Ouch. A hastily written sentence] Translation: Why is there no
> mechanism to roll back packages?

Who should implement this, and how would you _control_ a such mechanism?

> > The whole packagement system depends on the package versions. You cannot
> > just make the old package appear as an update without rebuilding it. And
> > exactly the build prozess was faulty in this case.
> 
> [It's not immediately apparent why the package indices can't link back
> to the older file]

Why? The indices are used to generate the dependenices, and they are
normally treat in one direction: up.

> We know that the biggest problem with testing Debian installers is that
> hardly anyone needs to use them. The idea of doing a new install instead
> of using the package management system to perform an upgrade is foreign
> to most users and developers.

What do you mean with "new install"?

Gruss/Regards,
Eduard.
-- 
Dass Geschwindigkeiten dimensionslos sind, hat lange Tradition und ist kein
Trick von Theoretikern. In Grimms Rotkaeppchen ist die Geschwindigkeit eines
Spaziergaengers 1, daher liegt Grossmutters Haus eine halbe Stunde vom Dorf.
(Norbert Dragon in de.sci.physik)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: About the infinite loop

2002-05-03 Thread Philip Charles

On 3 May 2002, Adam Warner wrote:

> So the unstable check doesn't work for this package because the install
> disks only download woody anyway. But when something goes wrong we still
> have to wait for the package to move from sid-->woody even though no one
> typically tests it in sid.
>
*

> I guess it really comes down to whether it is proper for no one to be
> testing packages until they hit woody, especially around the time of its
> release.

IMO, it is a glitch in the three tiered system we now have.  When slink and
potato were being developed everything was in testing/frozen.  If
something must be used in the next release then it should immediately go
into testing as each new version is built rather than unstable.

> We know that the biggest problem with testing Debian installers is that
> hardly anyone needs to use them. The idea of doing a new install instead
> of using the package management system to perform an upgrade is foreign
> to most users and developers.

As someone who produces CDs I am particularly interested in installations
from scratch.  With the old two tier system I knew where I was.  This time
round we did not have the same kind of freeze we had with slink and
potato, so I basically did not know where or when to start.

Maybe there needs to be a policy which states that any package that is
used in an installation goes into testing immediately.

> BTW thanks to the install disk developers. The disks are of very high
> quality. The best of any distribution I have used. Lots of options. Lots
> of freedom to do tasks out of order and no rampant paternalism (like
> refusing to proceed if a swap partition is not created).

Here, here.  I would also like to note that the installation disks go
straight into testing and not into unstable.

Phil.

--
  Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand
   +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420
 [EMAIL PROTECTED] - preferred.  [EMAIL PROTECTED]
 I sell GNU/Linux & GNU/Hurd CDs.   See http://www.copyleft.co.nz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




cvs commit to boot-floppies/utilities/dbootstrap/po by claush

2002-05-03 Thread Debian Boot CVS Master

Repository: boot-floppies/utilities/dbootstrap/po
who:claush
time:   Fri May  3 05:23:35 PDT 2002
Log Message:
  Danish update

Files:
changed:da.po


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




cvs commit to boot-floppies/documentation/da by claush

2002-05-03 Thread Debian Boot CVS Master

Repository: boot-floppies/documentation/da
who:claush
time:   Fri May  3 05:23:34 PDT 2002
Log Message:
  Danish update

Files:
changed:hardware.sgml welcome.sgml


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




cvs commit to boot-floppies/utilities/dbootstrap/po by dancer

2002-05-03 Thread Debian Boot CVS Master

Repository: boot-floppies/utilities/dbootstrap/po
who:dancer
time:   Fri May  3 04:46:57 PDT 2002
Log Message:
  updated ja.po according to patch from NAKANO TAKEO

Files:
changed:ja.po


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: Comment on install manual

2002-05-03 Thread Wichert Akkerman

Previously Guido Guenther wrote:
> SPI has it's own disklabel - cool :)

Doh, that should have been SGI as well of course :)

> If your disk has a SGI disklabel already, the expert menu is not
> available

That sounds a bit silly..

> (for whatever reason, I'll file a wishlist bug against
> util-linux - it should at least allow to recreate the disklabel)

At the very least it should mention in the error message why it does
not allow you to enter the expert menu.

The rest of the install went smoothly. There was a slight catch in that
the indy would only use the BOOTP server as TFTP server and ignored the
bootserver option, but some network sniffing revealed that pretty
quickly.

Wichert.

-- 
  _
 [EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: Comment on install manual

2002-05-03 Thread Florian Lohoff

On Fri, May 03, 2002 at 10:22:16AM +0200, Guido Guenther wrote:
> SPI has it's own disklabel - cool :)
> If your disk has a SGI disklabel already, the expert menu is not
> available(for whatever reason, I'll file a wishlist bug against
> util-linux - it should at least allow to recreate the disklabel) and
> there's usually no need to build a new one. If you really want to, you
> can /dev/zero the first blocks of your disk. Afterwards the expert menu
> allows you to create a new disklabel.

I did so by overwriting with an empty dos label - "o" ...

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-5201-669912
Heisenberg may have been here.



msg19606/pgp0.pgp
Description: PGP signature


[no subject]

2002-05-03 Thread officegirl



 


¡¡
 

°¡ºê¸®¿¤Çâ¼ö
ÆÄ¿îµ¥À̼Ç
ÃѾËû¹ÙÁö

\25,000
\39,000
\31,500

Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³»µå·Á Á˼ÛÇÕ´Ï´Ù.
¿øÄ¡ ¾ÊÀ¸½Ã¸é ¿·ÀÇ ¹öÆ°À» ´­·¯ÁÖ¼¼¿ä. 




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



prep with matrox millenium == out of scan range when booting kernel?!

2002-05-03 Thread Rubin

Hello People,

As I've posted before, I have modern debian 3.0 booting succesfully on a 
  Bull Estrella Series 300 (aka Motorola Powerstack II 4000/Pro).

After some investigations it turned out that the vga card is severely 
out of date (a Cirrus Logic GD5446 /w 256k of ram ;-). Ofcourse, this 
machine needs a cool graphics card so my first try was a Diamond FireGL 
3000 with fully loaded texture board (32mb)... The machine refused to 
come up (probably because it is anything but "standard" vga"). So as a 
second best, I chose my trusty Matrox Millenium II /w 4mb ram. The sytem 
agreed, and comes up nicely into the openfirmware screen and presents 
the usual bootup and diagnostics options.

But alas, it was all too good to be true; As soon as the bootloader (I 
think quik) loads, the screen goes black and a second later my monitor 
states "Out Of Scan Range"... Mmmm.. I tried and reproduced this with 
the older (2.2 potato) and newer (3.0 testing).
I'm pretty sure this has to do with the bootloader of debian but I don't 
know how to resolve this!

Interresting enough, running the yaboot bootloader from the ydl 2.2 cd 
inits the screen properly and presents me a boot: prompt; Alas, I seem 
to be unable to use it to boot my system with as it always returns "No 
Such File Or directory" or a "Corrupt Or Invalid Partition"..

If anybody has any suggestions, please let me know. I'll keep hacking at 
it and post whatever I'll find out next ;-)

Grtz,

Rubin.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: About the infinite loop

2002-05-03 Thread Adam Warner

On Fri, 2002-05-03 at 20:03, Eduard Bloch wrote:
> #include 

(BTW it's fantastic that you can post to a Debian mailing list without
being subscribed)

> Adam Warner wrote on Fri May 03, 2002 um 06:06:45PM:
> 
> > How did this bug almost get into the offical release of Woody? Was the
> 
> Pretty simple - nobody tests base-config completely unless it gets into
> _Woody_.

So the unstable check doesn't work for this package because the install
disks only download woody anyway. But when something goes wrong we still
have to wait for the package to move from sid-->woody even though no one
typically tests it in sid.

> > package tested before being distributed? If it wasn't for the security
> > infrastructure holding back the release date of Woody, Debian could be
> > in the midst of its worst PR fiasco with hundreds or thousands of CDs
> > being recalled and the bad news completely overshadowing the release.
> 
> Yes, this is one reason why IMO the general timings of the Woody release
> are very, very bad. This must change in Woody+1.

On my local mirror base-config 1.33.17 just became available to install.
It will probably be at least another two days before the fixed package
filters through to this mirror. I see your point about the general
release timings being very bad if such fundamental packages are still
being changed.

"On the upside, woody itself is ready to be released."
http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200204/msg00020.html

But what _would_ be good timing for the release Eduard? Perhaps
everybody is simply feeling pressure because it has been so long since
the last release.
 
> > If there is no mechanism to roll back to earlier packages that are know
> > to work when something really bad goes wrong, why not?

[Ouch. A hastily written sentence] Translation: Why is there no
mechanism to roll back packages?

> The whole packagement system depends on the package versions. You cannot
> just make the old package appear as an update without rebuilding it. And
> exactly the build prozess was faulty in this case.

[It's not immediately apparent why the package indices can't link back
to the older file]

I guess it really comes down to whether it is proper for no one to be
testing packages until they hit woody, especially around the time of its
release.

We know that the biggest problem with testing Debian installers is that
hardly anyone needs to use them. The idea of doing a new install instead
of using the package management system to perform an upgrade is foreign
to most users and developers.

BTW thanks to the install disk developers. The disks are of very high
quality. The best of any distribution I have used. Lots of options. Lots
of freedom to do tasks out of order and no rampant paternalism (like
refusing to proceed if a swap partition is not created).

Regards,
Adam



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: Comment on install manual

2002-05-03 Thread Guido Guenther

On Thu, May 02, 2002 at 10:07:39PM +0200, Wichert Akkerman wrote:
> Section 6.3.1 mentions you can create a SGI disk label from the fdisk
> expert menu, but when I had x in fdisk it tells me `Sorry, not experts
> menu for SPI partition tables available'. Somethings feels fishy here..
SPI has it's own disklabel - cool :)
If your disk has a SGI disklabel already, the expert menu is not
available(for whatever reason, I'll file a wishlist bug against
util-linux - it should at least allow to recreate the disklabel) and
there's usually no need to build a new one. If you really want to, you
can /dev/zero the first blocks of your disk. Afterwards the expert menu
allows you to create a new disklabel.
 -- Guido


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: About the infinite loop

2002-05-03 Thread Eduard Bloch

#include 
Adam Warner wrote on Fri May 03, 2002 um 06:06:45PM:

> How did this bug almost get into the offical release of Woody? Was the

Pretty simple - nobody tests base-config completely unless it gets into
_Woody_.

> package tested before being distributed? If it wasn't for the security
> infrastructure holding back the release date of Woody, Debian could be
> in the midst of its worst PR fiasco with hundreds or thousands of CDs
> being recalled and the bad news completely overshadowing the release.

Yes, this is one reason why IMO the general timings of the Woody release
are very, very bad. This must change in Woody+1.

> If there is no mechanism to roll back to earlier packages that are know
> to work when something really bad goes wrong, why not?

The whole packagement system depends on the package versions. You cannot
just make the old package appear as an update without rebuilding it. And
exactly the build prozess was faulty in this case.

Gruss/Regards,
Eduard.
-- 
Ich glaube nicht, daß man dieses Stück in Software umgesetzte Scheiße über-
haupt mieser machen kann, als es sowieso schon ist. Das dürfte das einzige
Programm sein, das vom Verhalten und seinen Anwendern her schlimmer als XP
auf einem Amiga ist. - Manuel Richardt in ka.talk ueber Outlook Express


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




cvs commit to boot-floppies/scripts/rootdisk/messages/fr by mquinson

2002-05-03 Thread Debian Boot CVS Master

Repository: boot-floppies/scripts/rootdisk/messages/fr
who:mquinson
time:   Fri May  3 00:20:56 PDT 2002
Log Message:
  Sync to EN [Pierre Machard]

Files:
changed:release_notes


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]