Re: bugs 64500 and 64823

Sven LUTHER <[EMAIL PROTECTED]> writes: > All in all, what i would want to happen is that when dbootstrap detects it is > running on an apus subarch, it does the same thing as if cdrom was supplied, > in case it was forgotten. It would be a 3 lines patch or so, surrounded by a > #ifd __powerpc__

Re: bugs 64500 and 64823

On Sat, Dec 02, 2000 at 02:12:02PM -0500, Adam Di Carlo wrote: > Sven LUTHER <[EMAIL PROTECTED]> writes: > > > Well, the problem is that it is not an official CDROM, but a copy of the > > archive on harddisk. There is no sense to generate rescue.bin on apus, since > > it is only used for getting

Re: bugs 64500 and 64823

Adam Di Carlo <[EMAIL PROTECTED]> writes: > dbootstrap should be clever enough to sense that a given CD-ROM is a > normal, official one and act accordingly, e.g., suck that stuff in > without further prompting. This should be the case no matter what the > cmdline argument were. Rigth now this is

Re: bugs 64500 and 64823

Sven LUTHER <[EMAIL PROTECTED]> writes: > Well, the problem is that it is not an official CDROM, but a copy of the > archive on harddisk. There is no sense to generate rescue.bin on apus, since > it is only used for getting the modules out of it. The kernel stays in the > native partition anyway,

Re: bugs 64500 and 64823

On Thu, Nov 30, 2000 at 01:40:52PM -0500, Adam Di Carlo wrote: > Sven LUTHER <[EMAIL PROTECTED]> writes: > > > BTW, i guess another option would be to look at the place where we read > > /proc/cmdline, and then set things up as if the boot arg cdrom was entered if > > and only if we are on ppc an

Re: bugs 64500 and 64823

Sven LUTHER <[EMAIL PROTECTED]> writes: > BTW, i guess another option would be to look at the place where we read > /proc/cmdline, and then set things up as if the boot arg cdrom was entered if > and only if we are on ppc and on the apus subarch. Which file should i look > for that ? mmm, maybe i

Re: bugs 64500 and 64823

On Thu, Nov 30, 2000 at 10:17:09AM -0500, Adam Di Carlo wrote: > Sven LUTHER <[EMAIL PROTECTED]> writes: > > > On Thu, Nov 30, 2000 at 02:59:20AM -0500, Adam Di Carlo wrote: > > > Sven LUTHER <[EMAIL PROTECTED]> writes: > > > > > > > Is there somethign special involved when dbootstrap installs f

Re: bugs 64500 and 64823

Sven LUTHER <[EMAIL PROTECTED]> writes: > On Thu, Nov 30, 2000 at 02:59:20AM -0500, Adam Di Carlo wrote: > > Sven LUTHER <[EMAIL PROTECTED]> writes: > > > > > Is there somethign special involved when dbootstrap installs from a CD ? how > > > can we make dbootstrap install think it is installing

Re: bugs 64500 and 64823

On Thu, Nov 30, 2000 at 02:59:20AM -0500, Adam Di Carlo wrote: > Sven LUTHER <[EMAIL PROTECTED]> writes: > > > Is there somethign special involved when dbootstrap installs from a CD ? how > > can we make dbootstrap install think it is installing from a CD when we are on > > apus ? > > Have it pa

Re: bugs 64500 and 64823

Sven LUTHER <[EMAIL PROTECTED]> writes: > Is there somethign special involved when dbootstrap installs from a CD ? how > can we make dbootstrap install think it is installing from a CD when we are on > apus ? Have it pass the 'cdrom' boot argument is the easiest way. There's a check in dbootstr

Re: bugs 64500 and 64823

On Sat, Aug 26, 2000 at 08:24:16PM -0400, Adam Di Carlo wrote: > > Wait a minnit. Why can't we just change dbootstrap to give the mount > command Michel mentioned, rather than the one which you mentioned? > > Assuming taht doesn't break other arches (don't see why it would) then > we have a pre

Bug#64500: bugs 64500 and 64823

I've looked into this briefly. The question is why we ever need to worry about managing loop devices. If not, and it seems we don't, then we can completely eliminate any fudging with /dev/loopX, we can remove utilities/dbootstrap/losetup.c. That would also mean just mucking with a lot of suppo

Bug#64500: bugs 64500 and 64823

Sven LUTHER <[EMAIL PROTECTED]> writes: > > I'm working only on a Potato upgrade. > > Ok, ... > > Any time frame so that i can manage my time for it ? We're shooting for oct 1 I think. I would say earlier but if we wanna wait for 2.2.17-1 we have little choice -- there are no idepci and compa

Bug#64500: bugs 64500 and 64823

On Tue, Sep 05, 2000 at 09:50:38AM -0400, Adam Di Carlo wrote: > Sven LUTHER <[EMAIL PROTECTED]> writes: > > > I think the apus subarch need a boot loader and kernel upgrade also. > > Ugh. No problem i can do a new kernel package, and the boot loader is only one dir to change. It is not really

Bug#64500: bugs 64500 and 64823

Sven LUTHER <[EMAIL PROTECTED]> writes: > I think the apus subarch need a boot loader and kernel upgrade also. Ugh. > BTW, i suppose this is for woody, or maybe a potato upgrade ? I'm working only on a Potato upgrade. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSC

Re: bugs 64500 and 64823

On Sat, Aug 26, 2000 at 08:24:16PM -0400, Adam Di Carlo wrote: > > naturally i checked that the /dev/loop0 device is available and readable (it > > has the same rights in both root /dev). > > > > Ok, this is the current status. Now, what can we do about it ? > > Wait a minnit. Why can't we just

Re: bugs 64500 and 64823

Sven LUTHER <[EMAIL PROTECTED]> writes: > On Sat, Jul 15, 2000 at 07:52:09AM +1000, Anthony Towns wrote: > > Hello world, > > > > After installing b-f 2.2.16, 64500 and 64823 still seem to be > > open. Are these RC? Are they already fixed? Do they require a 2.2.17 be > > built? What's the deal?

Re: bugs 64500 and 64823

On Sat, Jul 22, 2000 at 08:55:58AM +1000, Anthony Towns wrote: > On Fri, Jul 21, 2000 at 10:28:45AM +0200, Sven LUTHER wrote: > > I posted a message about it some week ago, but i don't see it anywehere, so i > > suppose it got lost. > > The 64500 bug is still there, i don't know how to fix it, [..

Re: bugs 64500 and 64823

On Fri, Jul 21, 2000 at 08:19:51PM +1000, Herbert Xu wrote: > Sven LUTHER <[EMAIL PROTECTED]> wrote: > > > > # mount -r -t vfat -o loop=/dev/loop0 rescue.bin /mnt > > What kind of a filesystem is rescue.bin on? Does it support bmap? Don't know, it was created by dosfstool, i guess it is a vfat

Re: bugs 64500 and 64823

On Fri, Jul 21, 2000 at 10:28:45AM +0200, Sven LUTHER wrote: > I posted a message about it some week ago, but i don't see it anywehere, so i > suppose it got lost. > The 64500 bug is still there, i don't know how to fix it, [...] In which case it's probably not going to be fixed in a reasonable a

Re: bugs 64500 and 64823

Sven LUTHER <[EMAIL PROTECTED]> wrote: > > # mount -r -t vfat -o loop=/dev/loop0 rescue.bin /mnt What kind of a filesystem is rescue.bin on? Does it support bmap? -- Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gond

Re: bugs 64500 and 64823

On Sat, Jul 15, 2000 at 07:52:09AM +1000, Anthony Towns wrote: > Hello world, > > After installing b-f 2.2.16, 64500 and 64823 still seem to be > open. Are these RC? Are they already fixed? Do they require a 2.2.17 be > built? What's the deal? Hello, ... I posted a message about it some week ag

Re: bugs 64500 and 64823

On Sat, Jul 15, 2000 at 03:39:30PM -0400, Adam Di Carlo wrote: > I don't think either should hold up potato release, IMHO. Then they're not release critical, and as such they've both been downgraded. Cheers, aj -- Anthony Towns <[EMAIL PROTECTED]> I don't spea

Re: bugs 64500 and 64823

Anthony Towns <[EMAIL PROTECTED]> writes: > Hello world, > > After installing b-f 2.2.16, 64500 and 64823 still seem to be > open. Are these RC? Are they already fixed? Do they require a 2.2.17 be > built? What's the deal? Regarding 64500, there aren't a lot of powerpc/apus users, and the ones

bugs 64500 and 64823

Hello world, After installing b-f 2.2.16, 64500 and 64823 still seem to be open. Are these RC? Are they already fixed? Do they require a 2.2.17 be built? What's the deal? Cheers, aj -- Anthony Towns <[EMAIL PROTECTED]> I don't speak for anyone save myself. GPG