[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#378164: marked as done (OldWorld Mac-specific problems; perhaps drop?)

Your message dated Wed, 08 Sep 2010 03:58:15 +0000
with message-id <E1OtBnb-0005EK-AZ@ravel.debian.org>
and subject line Closing old installation report #378164
has caused the Debian Bug report #378164,
regarding OldWorld Mac-specific problems; perhaps drop?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
378164: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378164
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: installation-reports

On Jul 13, 2006, at 1:24 PM, Sven Luther wrote:


On Thu, Jul 13, 2006 at 06:46:02PM +0200, Frans Pop wrote:

On Thursday 13 July 2006 18:20, Sven Luther wrote:

initrd-tools used to be knoweldgeable about the root device, while
initramfs-tools doesn't and you have to give it explicitly.

Try using yaird instead of initramfs-tools, and you will see this
problem going away.


Which is not really a structural solution as initramfs-tools _is_ the
default bootloader...


Indeed, the aim was to confirm that this is the solution to this bug.
So, what needs to be changed to have a proper "root=<whatever>" parameter in the bootloader configuration? Or, if nobootloader is used, what needs 
to be added in the boot instructions there?
Yeah, but when using bootx, the user needs to set it by hand. I suppose nobootloader gets chosen, and the ideal would that it could detect somehow that we are running bootx, or simply that we are on an oldworld pmac, and then give the info of what to do to the user (like we do currently on the pegasos).
Actually, when you choose "continue without installing bootloader" (or something like that) it clearly tells you what you need to do regarding "root=" and so on. But there's a gotcha...
The BootX dialog box makes it *appear* that having an initrd is incompatible with setting "root=" on the command line by, when you choose an initrd image, deleting the box where you put your root device designation and replacing it with a box where you chose the size for the the RAM area to load initrd. But *actually* you still can tell it to put a "root=" on the command line manually in the "additional arguments" box without ill effects, even though you have chosen an initrd.
So to the casual newbie -- and to experienced hands like myself who are used to the old behavior where the location of the root filesystem was encoded into the initrd image -- it looks like you should ignore the information provided by the d-i when you choose to "continue without installing bootloader". 

This can be fixed in one of two ways:
1) Fix the initramfs-tools to encode the root filesystem location in the initrd. 
	or
2) Fix the documentation so it explains what to do with that information if you are use BootX or OpenFirmware or something other than yaboot or quik as a bootloader.
If method (1) is chosen, it would be nice if there was clear documentation available (in the wiki?) on how to disassemble, modify, and reassemble an initrd image if you have to move the location of the root filesystem to another device.
I'm CC-ing this to submit@bugs.debian.org with "Package: installation- reports", for lack of a better. Will somebody who understands such things please assign it to an appropriate priority and package? 

Thanks!

Rick

--- End Message ---
--- Begin Message --- 
We are closing this installation report for one of the following
reasons:
- it was reported with a pre-lenny version of Debian
  Installer.
- indications in the installation report give the feeling that
  the reported problem waslying in another software, unrelated to
  D-I, which we can't easily identify.
- indications in the installation report suggest that it may have been
  fixed in a more recent version of a D-I component
- it was successful and we forgot closing it..:-)
- it has no information we consider useful


The D-I team is currently in the process of cleaning out the old spool
of installation reports that haven't bene processed yet. 

In case you think that the problem you reported has chances to be
still present, please reiterate your installation test with
a more recent image of D-I, if you're in position of doing this.

You'll find daily builds at
http://www.debian.org/devel/debian-installer. We recommend you choose
the netboot image, in the "daily builds section", then choose to
install "squeeze" when prompted.

If some problems are found, please report them with a new bug sent
against installation-reports.

Many thanks for your understanding and your help improving Debian,
past and present.

--- End Message ---
Reply to: