Re: Hints to allow debian-installer RC2 upload

[Christian Perrier]

Quoting Otavio Salvador (ota...@debian.org):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Luk Claes  writes:
> 
> > Ok, only took care of the ones you mentioned and reviewing the list on
> > [1] it seems reasonable.
> 
> Thanks ...
> 
> As a last-minute change, Robert has uploaded win32-loader that fixes
> an important bug that would be interesting to get in (plus
> translations). Please take a look at it please age it to get it on
> lenny so we can upload d-i.


What about kernel-wedge, also? (heads-up from Frans)



signature.asc
Description: Digital signature

debian-installer error

[schoappied]

Hi,

I'm trying to build a custom Debian live-cd, but I think it is going 
wrong when it want to add the installer.

I got this message:

Download complete and in download only mode
http://ftp.us.debian.org/debian//pool/main/l/linux-kernel-di-i386-2.6/acpi-modules-2.6.26-1-486-di_1.75_i386.udeb:
2009-01-19 02:11:56 Fout 404: Not Found.

What could this be?

\r


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Pre-bug-raising questions

[Mike Grice]

Hi guys,

Many thanks for your closure of my recent bug to get the Sun LDOM
modules included into the Debian-installer (and the associated kernel
work).

To further the process, I tried to do an install using the daily
netboot image at
http://people.debian.org/~stappers/d-i/sparc/daily/netboot/boot.img.
I'm pleased to say that this gets further than ever before:

 - it fails to detect the network device but i'm able to select the
correct one from a list.
 - it fails to detect the disk device but i'm able to select the
correct one from a list.

(Don't know if the above 2 are a udev problem)

Anyway, both easily worked around.  The problem I get now is that the
kernel the installer installs as part of the setup is the etch-n-half
kernel, which doesn't have the required drivers installed.  So I'm
stuck at 'waiting for root filesystem...' until I drop to the initrd,
and I can't find the module to install.

Having some stuff randomly in my head about being able to pass suite=
to the boot line, I reinstalled with suite=lenny.

This time, the debian-installer installs a better sounding kernel
(2.6.26-1-sparc64-smp), but I'm dumped to the initrd shell again.
Looking through the filesystem, the modules are definitely there and I
can insmod them and continue the install.

Is there anything I'm missing here?  I can tell something is 'just a
bit missing' and I'd love to be able to raise a correct bug report for
this and get it squashed before Lenny.

Thanks for your help so far,

Mike.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Pre-bug-raising questions

[Bastian Blank]

On Mon, Jan 19, 2009 at 11:52:59AM +, Mike Grice wrote:
> I'm pleased to say that this gets further than ever before:
>  - it fails to detect the network device but i'm able to select the
> correct one from a list.
>  - it fails to detect the disk device but i'm able to select the
> correct one from a list.

Hmm. Which list do you mean?

> The problem I get now is that the
> kernel the installer installs as part of the setup is the etch-n-half
> kernel, which doesn't have the required drivers installed.  So I'm
> stuck at 'waiting for root filesystem...' until I drop to the initrd,
> and I can't find the module to install.

The daily installers defaults to installing unstable. However there is
no etch'n'half-kernel in unstable. So you override that decision
somewhere.

> This time, the debian-installer installs a better sounding kernel
> (2.6.26-1-sparc64-smp), but I'm dumped to the initrd shell again.
> Looking through the filesystem, the modules are definitely there and I
> can insmod them and continue the install.

Okay, so its a problem somewhere between udev and the kernel
definitions.

> Is there anything I'm missing here?  I can tell something is 'just a
> bit missing' and I'd love to be able to raise a correct bug report for
> this and get it squashed before Lenny.

Add the modules to /etc/initramfs-tools/modules.

Bastian

-- 
Insults are effective only where emotion is present.
-- Spock, "Who Mourns for Adonais?"  stardate 3468.1


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Pre-bug-raising questions

[Frans Pop]

On Monday 19 January 2009, Bastian Blank wrote:
> > The problem I get now is that the
> > kernel the installer installs as part of the setup is the etch-n-half
> > kernel, which doesn't have the required drivers installed.  So I'm
> > stuck at 'waiting for root filesystem...' until I drop to the initrd,
> > and I can't find the module to install.
>
> The daily installers defaults to installing unstable. However there is
> no etch'n'half-kernel in unstable. So you override that decision
> somewhere.

s/unstable/testing/
But the conclusion is correct: daily built images should never install 
stable "by default". Either Mike is doing something wrong, or the image 
is seriously broken somehow. The selection of stable could possibly also 
be the result of network problems.
We should be able to tell from the syslog for the installation.


signature.asc
Description: This is a digitally signed message part.

Re: AMD64 Testing Netinst known Issues broken link

[Simon Paillard]

Hello debian-boot,

On Mon, Jan 19, 2009 at 10:03:38AM +0100, Ionel Mugurel Ciobica wrote:
> On 19-01-2009, at 17h 00'20", Kris Bousfield wrote about "AMD64 Testing 
> Netinst known Issues broken link"
> > I have recently tried to install the current testing AMD64
> > netinst and ran into the known problem with the marvel disk
> > controllers not being supported.
> >
> > The workaround gives 2 links, one for the I386 and the other for AMD64.
> > The AMD64 one I need has a broken link.
> > http://www.debian.org/devel/debian-installer/errata
> > http://http.us.debian.org/debian/pool/main/l/linux-kernel-di-amd64-2.6/pata-modules-2.6.26-1-amd64-di_1.72_amd64.udeb
> >  (Does not work)
>
> I don't think is the right list, but try 1.53 or 1.49 instead of 1.72,
> if that is good enough for you.
> 
> (E.g.: 
> http://http.us.debian.org/debian/pool/main/l/linux-kernel-di-amd64-2.6/pata-modules-2.6.26-1-amd64-di_1.53_amd64.udeb
> or 
> http://http.us.debian.org/debian/pool/main/l/linux-kernel-di-amd64-2.6/pata-modules-2.6.26-1-amd64-di_1.49_amd64.udeb
> instead of the broken link)

This mail to let you know that devel/debian-installer/errata will be
fixed, replacing 
http://http.us.debian.org/debian/pool/main/l/linux-kernel-di-amd64-2.6/pata-modules-2.6.26-1-amd64-di_1.72_amd64.udeb
 (KO)
by 
http://http.us.debian.org/debian/pool/main/l/linux-kernel-di-amd64-2.6/pata-modules-2.6.26-1-amd64-di_1.53_amd64.udeb
 
(the right one according to 
http://packages.debian.org/lenny/pata-modules-2.6.26-1-amd64-di )

Best regards.

-- 
Simon Paillard


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Pre-bug-raising questions

[Mike Grice]

On Mon, Jan 19, 2009 at 12:46 PM, Bastian Blank  wrote:
> On Mon, Jan 19, 2009 at 11:52:59AM +, Mike Grice wrote:
>> I'm pleased to say that this gets further than ever before:
>>  - it fails to detect the network device but i'm able to select the
>> correct one from a list.
>>  - it fails to detect the disk device but i'm able to select the
>> correct one from a list.
>
> Hmm. Which list do you mean?

Ok.  From a boot net:dhcp, the installer gives me:

Select a language: English
Choose Language: default
Detect Network Hardware:
"No Ethernet card was detected. If you know the name of the driver   │
  │ needed by your Ethernet card, you can select it from the list."

I'm then given a list of all the network drivers available.  I can
scroll down to the 'sunvnet' driver, and the installer then carries on
as normal.

I'm asked for a hostname and domain, which I provide.  I select United
Kingdom as the Debian archive mirror.  I select the default mirror for
that country 'ftp.uk.debian.org'.  I provide HTTP proxy information,
which for my network is http://192.168.107.1:3128 (basic squid
install).

The installer then 'loads additional components', which I think
happens over the network.  It mentions contacting a time server.  I'm
then on the 'detect disks' menu, which tells me:
"  │ No disk drive was detected. If you know the name of the driver
needed   │
  │ by your disk drive, you can select it from the list."

I can scroll down to the 'sunvdc' driver, and the installer then
carries on as normal.

Those are the two menu things I referred to before.

BTW, if I choose guided partitioning, it will select ext2 by default
for the boot partition (I change this, but just thought you would like
to know as its a bit odd, maybe a legacy SILO hangover).

>> The problem I get now is that the
>> kernel the installer installs as part of the setup is the etch-n-half
>> kernel, which doesn't have the required drivers installed.  So I'm
>> stuck at 'waiting for root filesystem...' until I drop to the initrd,
>> and I can't find the module to install.
>
> The daily installers defaults to installing unstable. However there is
> no etch'n'half-kernel in unstable. So you override that decision
> somewhere.

Actually, I just checked this time from a clean install and its picked
the new kernel without prompting.  As I was messing with the network
parameters the first time perhaps it defaulted to the older kernel?
Either way, that part is a non-issue now.  I will provide the install
syslog (thanks for that idea FP) if you need it for diagnosis later...

>> This time, the debian-installer installs a better sounding kernel
>> (2.6.26-1-sparc64-smp), but I'm dumped to the initrd shell again.
>> Looking through the filesystem, the modules are definitely there and I
>> can insmod them and continue the install.
>
> Okay, so its a problem somewhere between udev and the kernel
> definitions.

Ok.  Is this something I can fix myself without rebuilding the
installer?  (e.g., can I preseed it)?

>> Is there anything I'm missing here?  I can tell something is 'just a
>> bit missing' and I'd love to be able to raise a correct bug report for
>> this and get it squashed before Lenny.
>
> Add the modules to /etc/initramfs-tools/modules.

Is that something I need to put in the bug report as a fix for this issue?

Thanks for your help so far,

Mike.


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Hints to allow debian-installer RC2 upload

[Otavio Salvador]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christian Perrier  writes:

> Quoting Otavio Salvador (ota...@debian.org):
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> 
>> Luk Claes  writes:
>> 
>> > Ok, only took care of the ones you mentioned and reviewing the list on
>> > [1] it seems reasonable.
>> 
>> Thanks ...
>> 
>> As a last-minute change, Robert has uploaded win32-loader that fixes
>> an important bug that would be interesting to get in (plus
>> translations). Please take a look at it please age it to get it on
>> lenny so we can upload d-i.
>
>
> What about kernel-wedge, also? (heads-up from Frans)

Good catch! It is not required for d-i upload but for Lenny release.

Please RM team:

unblock kernel-wedge

Cheers,

- -- 
O T A V I OS A L V A D O R
- -
 E-mail: ota...@debian.org  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
- -
"Microsoft sells you Windows ... Linux gives
 you the whole house."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iEYEARECAAYFAkl0jJIACgkQLqiZQEml+FUzpACfbrjyFDoASNMrzZviBvmoztsO
cNYAnRrSJ1AgPMqxs7dvtDAy6SKRYL8r
=5HCP
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Hints to allow debian-installer RC2 upload

[Adeodato Simó]

* Otavio Salvador [Mon, 19 Jan 2009 12:22:11 -0200]:

> > What about kernel-wedge, also? (heads-up from Frans)

> Good catch! It is not required for d-i upload but for Lenny release.
> Please RM team:
> unblock kernel-wedge

Done.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
I promise you. Once I enter into an exclusive relationship, I sleep with
very few people.
-- Denny Crane


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#418708: installation-reports: Dialogs difficult to use on gray-scale monitors

[Marc-Jano Knopp]

[ As querybts doesn't let me provide extra information (##501285), I'm
  trying to add this via e-mail, hope it works. ]


Tomasz Chmielewski  wrote:

> I remember I used d-i to install Debian (arm) on Thecus n4100 - using 
> minicom and a serial connection. Navigation in d-i over a serial 
> connection / minicom sucks, but that's another story.
> 
> Essentially, a serial connection is black and white only - can it be 
> worse than a gray-scale monitor?

Yes.

In case of a serial connection, the communication endpoint (software or
hardware terminal) can

  1) evaluate *all* color/brightness information (it's usually just
 black and white with two grades of brightness, digitally encoded
 via escape sequences),

  2) losslessly reproduce the transferred color/brightness information,
 as the terminal (software or hardware) is featured with an
 appropriate output device (CRTC in either case).

In case of a gray-scale monitor attached to a (color) graphics card, the
monitor can

  1) usually *not* evaluate all information (at least 16 millions of
 colors, split to three different color channels, analogically
 encoded), as it often has only one input channel, which is hooked
 to the green output channel of the graphics card,

  2) *not* losslessly reproduce the transferred information. The input
 consists of at least 16 millions colors, which have to be mapped
 to just 256 grades of brightness (gray).

Lower-end gray-scale monitors only evaluate the green channel and will
display all colors that don't contain any green (e. g. pure red or pure
blue) as black.

Higher-end gray-scale monitors evaluate all three color channels (red,
green, blue), and map the 16 millions of colors in an
eye-physiologically optimal way to 255 grades of brightness, so that,
for instance, pure red and pure blue are displayed with to different
shades of gray. There are also graphics cards that do that mapping on
their own, if configured so.

Either way, information gets lost or "compressed" so much, that two
different colors can be indistinguishable on a gray-scale monitor.


There are two possibilities after letting the user tell the system 
(e. g. via bootloader parameters) about having a gray-scale or
monochrome monitor:

A) For both gray-scale and monochrome monitors:
   
   Use only black and white (with two grades of brightness) and
   display the currently selected element with a special formatting,
   i. e. inverted or underlined.

B) For gray-scale monitors:

   In case the color-to-shades-of-gray mapping is (nearly) the same
   everywhere, use more than two colors, but make sure that with the
   given mapping, they are well distinguishable.

Option "A" should be totally sufficient for installing Debian.


Regards

  Marc-Jano


P.S.: Even today's BIOS setup programs have an option to change
  foreground and background colors (incl. black & white) -- which
  is good, because otherwise, it could happen that I can't use my
  server's BIOS setup, as it's attached to a small gray-scale
  monitor.



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Pre-bug-raising questions

[Mike Grice]

2009/1/19 Mike Grice :
> On Mon, Jan 19, 2009 at 12:46 PM, Bastian Blank  wrote:
>> On Mon, Jan 19, 2009 at 11:52:59AM +, Mike Grice wrote:
>>> I'm pleased to say that this gets further than ever before:
>>>  - it fails to detect the network device but i'm able to select the
>>> correct one from a list.
>>>  - it fails to detect the disk device but i'm able to select the
>>> correct one from a list.
>>
>> Hmm. Which list do you mean?
>
> Ok.  From a boot net:dhcp, the installer gives me:
>
> Select a language: English
> Choose Language: default
> Detect Network Hardware:
> "No Ethernet card was detected. If you know the name of the driver   │
>  │ needed by your Ethernet card, you can select it from the list."
>
> I'm then given a list of all the network drivers available.  I can
> scroll down to the 'sunvnet' driver, and the installer then carries on
> as normal.
>
> I'm asked for a hostname and domain, which I provide.  I select United
> Kingdom as the Debian archive mirror.  I select the default mirror for
> that country 'ftp.uk.debian.org'.  I provide HTTP proxy information,
> which for my network is http://192.168.107.1:3128 (basic squid
> install).
>
> The installer then 'loads additional components', which I think
> happens over the network.  It mentions contacting a time server.  I'm
> then on the 'detect disks' menu, which tells me:
> "  │ No disk drive was detected. If you know the name of the driver
> needed   │
>  │ by your disk drive, you can select it from the list."
>
> I can scroll down to the 'sunvdc' driver, and the installer then
> carries on as normal.
>
> Those are the two menu things I referred to before.
>
> BTW, if I choose guided partitioning, it will select ext2 by default
> for the boot partition (I change this, but just thought you would like
> to know as its a bit odd, maybe a legacy SILO hangover).
>
>>> The problem I get now is that the
>>> kernel the installer installs as part of the setup is the etch-n-half
>>> kernel, which doesn't have the required drivers installed.  So I'm
>>> stuck at 'waiting for root filesystem...' until I drop to the initrd,
>>> and I can't find the module to install.
>>
>> The daily installers defaults to installing unstable. However there is
>> no etch'n'half-kernel in unstable. So you override that decision
>> somewhere.
>
> Actually, I just checked this time from a clean install and its picked
> the new kernel without prompting.  As I was messing with the network
> parameters the first time perhaps it defaulted to the older kernel?
> Either way, that part is a non-issue now.  I will provide the install
> syslog (thanks for that idea FP) if you need it for diagnosis later...
>
>>> This time, the debian-installer installs a better sounding kernel
>>> (2.6.26-1-sparc64-smp), but I'm dumped to the initrd shell again.
>>> Looking through the filesystem, the modules are definitely there and I
>>> can insmod them and continue the install.
>>
>> Okay, so its a problem somewhere between udev and the kernel
>> definitions.
>
> Ok.  Is this something I can fix myself without rebuilding the
> installer?  (e.g., can I preseed it)?
>
>>> Is there anything I'm missing here?  I can tell something is 'just a
>>> bit missing' and I'd love to be able to raise a correct bug report for
>>> this and get it squashed before Lenny.
>>
>> Add the modules to /etc/initramfs-tools/modules.
>
> Is that something I need to put in the bug report as a fix for this issue?

Adding those modules to that file and running update-initramfs -u does
fix this issue.  I have the following problem, though:

The boot sequence now identifies all the modules gets as far as the
console login but my keystrokes don't actually get there (I can mash
the keyboard and no characters are echoed back, or responses given
from the host).  This is from the 'console' as far as connecting over
telnet (which works for doing the install).

If I break out of the installer to the shell and make sure ssh-server
is running as part of the install, I can get to the box at the time
the login prompt is displayed and use the box as normal, so it's just
a console problem...

So I guess the salient points from all the above are:

1) the debian-installer is not detecting the correct modules for the
hdd and net even though theyre present in the udebs

2) the initramfs-tools config on the installed system doesn't load the
relevant modules by default

3) the text console doesn't work once the install is finished and the
system is up as normal

Thanks again,
Mike


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Pre-bug-raising questions

[Ian Campbell]

On Mon, 2009-01-19 at 14:12 +, Mike Grice wrote:
> 
> Select a language: English
> Choose Language: default
> Detect Network Hardware:
> "No Ethernet card was detected. If you know the name of the driver
> │
>   │ needed by your Ethernet card, you can select it from the list."

Do you have something akin to /sys/bus/sunv/devices/blah? With modalias
entries here and in the module the installer should be able to make the
connection between one and the other. For example for Xen virtual
devices we have:
di32:~# cat /sys/bus/xen/devices/vif-0/modalias 
xen:vif
di32:~# modinfo xen-netfront
filename:   
/lib/modules/2.6.26-1-686-bigmem/kernel/drivers/net/xen-netfront.ko
alias:  xennet
alias:  xen:vif
license:GPL
description:Xen virtual network device frontend
depends:
vermagic:   2.6.26-1-686-bigmem SMP mod_unload modversions
686 

So the xen:vif modalias ties into the alias on the module.

Ian.
-- 
Ian Campbell
Current Noise: Cynic - Integral Birth

An expert is one who knows more and more about less and less until he knows
absolutely everything about nothing.


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Pre-bug-raising questions

[Mike Grice]

2009/1/19 Mike Grice :
> On Mon, Jan 19, 2009 at 4:10 PM, Ian Campbell  wrote:
>> On Mon, 2009-01-19 at 14:12 +, Mike Grice wrote:
>>>
>>> Select a language: English
>>> Choose Language: default
>>> Detect Network Hardware:
>>> "No Ethernet card was detected. If you know the name of the driver
>>> │
>>>   │ needed by your Ethernet card, you can select it from the list."
>>
>> Do you have something akin to /sys/bus/sunv/devices/blah? With modalias
>> entries here and in the module the installer should be able to make the
>> connection between one and the other. For example for Xen virtual
>> devices we have:
>>di32:~# cat /sys/bus/xen/devices/vif-0/modalias
>>xen:vif
>>di32:~# modinfo xen-netfront
>>filename:   
>> /lib/modules/2.6.26-1-686-bigmem/kernel/drivers/net/xen-netfront.ko
>>alias:  xennet
>>alias:  xen:vif
>>license:GPL
>>description:Xen virtual network device frontend
>>depends:
>>vermagic:   2.6.26-1-686-bigmem SMP mod_unload modversions
>>686
>>
>> So the xen:vif modalias ties into the alias on the module.
>
> Ok, that's pretty interesting.  I suspect that the console support is
> compiled into the kernel via the CONFIG_LDOMS kernel option though
> (the net and disk are modules).  The giveaway for that would be the
> very sparse loaded module list:
>
> hostname:~# lsmod
> Module  Size  Used by
> ipv6  307168  72
> ext3  142672  2
> jbd50856  1 ext3
> sunvnet16132  0
> sunvdc 12168  5
>
> Theres some interesting things in dmesg about console shenanigans:
> hostname:~# dmesg | grep -E '(cons|tty|prom)'
> [0.00] console [earlyprom0] enabled
> [0.00] OF stdout device is: /virtual-devi...@100/cons...@1
> [22750.854590] console handover: boot [earlyprom0] -> real [tty0]
> [22755.397980] f02795dc: ttyS0 at I/O 0x0 (irq = 17) is a SUN4V HCONS
> [22755.400034] console [ttyHV0] enabled
>
> The console I'm having problems with is the virtual one where it
> simulates being 'at the console'.  From the primary LDOM (domain 0 in
> xenspeak), you telnet to localhost on a port and it dumps you to that
> console.
>
> The weird thing is that this console works completely fine during the
> debian-installer (even with colour and tabbing, etc.) but once you
> reboot into the new Debian install, the console is effectively
> 'read-only' (I see the login: prompt, but no matter what key
> combination I press, my typing does not show at the other side).
>
> The output of dmesg and a find in /sys are attached if you think
> perusing these will help...

Ok, to answer my own question, this console seems to have become a
serial console after the reboot.  Just on a hunch I edited
/etc/inittab (via my ssh connection), uncommented the ttyS0 line (the
one you normally use to enable the serial console) and after an 'init
q' my virtual console that was open in another window sprang into life
with a normal banner.

How you'd take care of that in the installer in a nice way, I have no idea...

Mike


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Pre-bug-raising questions

[Ian Campbell]

On Mon, 2009-01-19 at 16:43 +, Mike Grice wrote:
> 2009/1/19 Mike Grice :
> > On Mon, Jan 19, 2009 at 4:10 PM, Ian Campbell  wrote:
> >> On Mon, 2009-01-19 at 14:12 +, Mike Grice wrote:
> >>>
> >>> Select a language: English
> >>> Choose Language: default
> >>> Detect Network Hardware:
> >>> "No Ethernet card was detected. If you know the name of the driver
> >>> │
> >>>   │ needed by your Ethernet card, you can select it from the list."
> >>
> >> Do you have something akin to /sys/bus/sunv/devices/blah? With modalias
> >> entries here and in the module the installer should be able to make the
> >> connection between one and the other. For example for Xen virtual
> >> devices we have:
> >>di32:~# cat /sys/bus/xen/devices/vif-0/modalias
> >>xen:vif
> >>di32:~# modinfo xen-netfront
> >>filename:   
> >> /lib/modules/2.6.26-1-686-bigmem/kernel/drivers/net/xen-netfront.ko
> >>alias:  xennet
> >>alias:  xen:vif
> >>license:GPL
> >>description:Xen virtual network device frontend
> >>depends:
> >>vermagic:   2.6.26-1-686-bigmem SMP mod_unload modversions
> >>686
> >>
> >> So the xen:vif modalias ties into the alias on the module.
> >
> > Ok, that's pretty interesting.  I suspect that the console support is
> > compiled into the kernel via the CONFIG_LDOMS kernel option though
> > (the net and disk are modules).  The giveaway for that would be the
> > very sparse loaded module list:
> >
> > hostname:~# lsmod
> > Module  Size  Used by
> > ipv6  307168  72
> > ext3  142672  2
> > jbd50856  1 ext3
> > sunvnet16132  0
> > sunvdc 12168  5
> >
> > Theres some interesting things in dmesg about console shenanigans:
> > hostname:~# dmesg | grep -E '(cons|tty|prom)'
> > [0.00] console [earlyprom0] enabled
> > [0.00] OF stdout device is: /virtual-devi...@100/cons...@1
> > [22750.854590] console handover: boot [earlyprom0] -> real [tty0]
> > [22755.397980] f02795dc: ttyS0 at I/O 0x0 (irq = 17) is a SUN4V HCONS
> > [22755.400034] console [ttyHV0] enabled
> >
> > The console I'm having problems with is the virtual one where it
> > simulates being 'at the console'.  From the primary LDOM (domain 0 in
> > xenspeak), you telnet to localhost on a port and it dumps you to that
> > console.
> >
> > The weird thing is that this console works completely fine during the
> > debian-installer (even with colour and tabbing, etc.) but once you
> > reboot into the new Debian install, the console is effectively
> > 'read-only' (I see the login: prompt, but no matter what key
> > combination I press, my typing does not show at the other side).
> >
> > The output of dmesg and a find in /sys are attached if you think
> > perusing these will help...
> 
> Ok, to answer my own question, this console seems to have become a
> serial console after the reboot.  Just on a hunch I edited
> /etc/inittab (via my ssh connection), uncommented the ttyS0 line (the
> one you normally use to enable the serial console) and after an 'init
> q' my virtual console that was open in another window sprang into life
> with a normal banner.
> 
> How you'd take care of that in the installer in a nice way, I have no idea...

For Xen I had to add code to
packages/finish-install/finish-install.d/90console to make this work.
It's r54359 in the Debian installer SVN repo
http://svn.debian.org/viewsvn/d-i?rev=54359&view=rev

If your device is hvc0 as well then adding an || to that if statement
seems reasonable.

-- 
Ian Campbell
Current Noise: The Sontaran Experiment - The Dawning Of The Black Summer

Q:  Why was Stonehenge abandoned?
A:  It wasn't IBM compatible.


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Debian-installer early kernel exception (ASUS P5QL motherboard, i386)

[Márton Drótos]

Dear debian-boot members,

I've experienced that it is impossible to perform an installation with
the actual Lenny installer on ASUS P5QL motherboards because
Bug#505975 ([1]; for more details, see [2]) is not fixed in the kernel
version which is used by the installer.

I'm not sure wheter this issue should be reported as a bug, because in
later kernels it is fixed.

Márton Drótos


[1]: 
http://groups.google.com/group/linux.debian.kernel/browse_thread/thread/c5d34c035ba76315
[2]: http://lkml.org/lkml/2008/10/9/267


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#332941: marked as done (installation-reports: fails to unpack base-installer component)

[Debian Bug Tracking System]

Your message dated Mon, 19 Jan 2009 19:33:13 +0100
with message-id <20090119193313.e605a898@firenze.linux.it>
and subject line Re: Bug#332941: installation-reports: fails to unpack 
base-installer component
has caused the Debian Bug report #332941,
regarding installation-reports: fails to unpack base-installer component
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 ow...@bugs.debian.org
immediately.)


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

 Debian-installer-version: Debian GNU/Linux 3.1 r0
   (as released when sarge became stable)
   obtained from http://cdimage.debian.org/debian-cd/current/, IIRC
 uname -a: Linux (none) 2.6.8-2-386 #1 Mon Jan 24 03:01:58 EST 2005 i586 unknown
 Date: Sun,  9 Oct 2005 17:43:45 +0200 (latest try...)
 Method: I tried to install from CD, booting from CD (with the help of a
   Smart Boot Manager floppy). No network for this machine.

 Machine: (Old) assembled minitower machine.
 Processor: Pentium-S  Clock frequency: 120 MHz
 Memory: 32 Mibyte (successfully checked with two full memtest86 runs)
 Root Device: /dev/hda (IDE)
 Root Size/partition table: I didn't reach the partitioning step...
 Output of lspci and lspci -n:
# lspci
:00:00.0 Host bridge: Intel Corp. 430VX - 82437VX TVX [Triton VX] (rev 01)
:00:07.0 ISA bridge: Intel Corp. 82371SB PIIX3 ISA [Natoma/Triton II] (rev 
01)
:00:07.1 IDE interface: Intel Corp. 82371SB PIIX3 IDE [Natoma/Triton II]
:00:0e.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] 
(rev 53)
# lspci -n
:00:00.0 0600: 8086:7030 (rev 01)
:00:07.0 0601: 8086:7000 (rev 01)
:00:07.1 0101: 8086:7010
:00:0e.0 0300: 5333:8811 (rev 53)

 Base System Installation Checklist:
 [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
 
 Initial boot worked:[O]
 Configure network HW:   [ ]
 Config network: [ ]
 Detect CD:  [O]
 Load installer modules: [E]
 Detect hard drives: [ ]
 Partition hard drives:  [ ]
 Create file systems:[ ]
 Mount partitions:   [ ]
 Install base system:[ ]
 Install boot loader:[ ]
 Reboot: [ ]

 Comments/Problems:

I booted from CD (with the help of a Smart Boot Manager floppy), selecting
"linux26".
After the low memory warning, I chose the Italian keyboard keymap.
The CD detection went fine: debian-installer scanned the CD Debian archive.
The "Loading components of the Debian Installer" step went on from
0 to 85 % (I think), then...

  0. the screen blanked for a while
  1. the interface got repainted (again "Loading components of the
 Debian Installer")
  2. the progress bar restarted from zero 
  3. progress status said "unpacking base-installer"
  4. the progress bar reached 10 %
  5. goto 0. (in a seemingly endless loop)

Actually the loop was repeated a few times and then I got a permanent
blank screen.
Switching on the fourth virtual terminal (ALT+F4) shows that there's
still activity: an endless loop of 82 identical lines are
logged to /var/log/syslog.
I counted them by switching on the second virtual terminal (ALT+F2)
and determining that 

  # tail -83 /var/log/syslog

shows the first line identical to the last one (apart from the date, of
course...).
Unfortunately I couldn't mount any floppy disk or hard disk: as
a consequence, I was not able to save those log lines.  :-(

Please note that the CD and CD reader seem to work properly: I could
successfully check the CD content md5sums from a previosly installed
system (I mean: on the same machine), by mounting the CD and issueing
the following command in the CD root directory:

  $ md5sum -cv md5sum.txt

I cannot go on with the installation.
I even tried in expert mode, but got similar errors...
What can I do?

--- End Message ---
--- Begin Message ---
> On Mon, 10 Oct 2005 23:49:51 +0200 Francesco Poli wrote:
[...]
> > But I'm *not* installing etch, I'm trying to install sarge!
[...]

I am closing this bug report, since it applies to sarge, which is not
going to be changed any longer, I guess.

I don't know whether the memory requirements currently claimed in
http://d-i.alioth.debian.org/manual/en.i386/ch02s05.html
are correct or not: unless I have the opportunity to check this
on a real low memory x86 machine [1], I'll assume they are OK.


[1] I no longer have access to the old box I mentioned in the present
bug report...


-- 
 On some search engines, searching for my nickname AND
 "nano-documents" may lead you to my website...  

Re: Debian-installer early kernel exception (ASUS P5QL motherboard, i386)

[Frans Pop]

On Monday 19 January 2009, Márton Drótos wrote:
> I've experienced that it is impossible to perform an installation with
> the actual Lenny installer on ASUS P5QL motherboards because
> Bug#505975 ([1]; for more details, see [2]) is not fixed in the kernel
> version which is used by the installer.
>
> I'm not sure wheter this issue should be reported as a bug, because in
> later kernels it is fixed.

That bug report says it is fixed in kernel version 2.6.26-10, so daily 
built images should already work. And the upcoming RC2 release of the 
installer should be fine too.

Can you confirm that a daily built image [1] does not have the problem?

Cheers,
FJP

[1] http://www.debian.org/devel/debian-installer/


signature.asc
Description: This is a digitally signed message part.

Re: Pre-bug-raising questions

[Frans Pop]

On Monday 19 January 2009, Mike Grice wrote:
> So I guess the salient points from all the above are:
>
> 1) the debian-installer is not detecting the correct modules for the
> hdd and net even though theyre present in the udebs
>
> 2) the initramfs-tools config on the installed system doesn't load the
> relevant modules by default
>
> 3) the text console doesn't work once the install is finished and the
> system is up as normal

Just to make sure there are no false expectancies: we are about to upload 
the RC2 release of Debian Installer, which is expected to be the final 
release for Lenny.

The issues you describe here are clearly not bugs, but a new feature. The 
detection/loading of modules is something that should preferably be done 
automatically by the kernel, although it can probably be worked around in 
the installer (if there is a clear way to recognize _when_ the modules 
should be loaded).

The "serial console" issue is probably relatively trivial to solve, but 
should still be done very carefully.

Conclusion: the needed changes will NOT be done before the release of 
Lenny. However, there is a slight chance they could be included in a 
later stable update. That mostly depends on whether someone is willing to 
do the work required for that.

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.

Re: Pre-bug-raising questions

[Mike Grice]

On Mon, Jan 19, 2009 at 4:57 PM, Ian Campbell  wrote:
> On Mon, 2009-01-19 at 16:43 +, Mike Grice wrote:
>> 2009/1/19 Mike Grice :
>> > On Mon, Jan 19, 2009 at 4:10 PM, Ian Campbell  wrote:
>> >> On Mon, 2009-01-19 at 14:12 +, Mike Grice wrote:
>> >>>
>> >>> Select a language: English
>> >>> Choose Language: default
>> >>> Detect Network Hardware:
>> >>> "No Ethernet card was detected. If you know the name of the driver
>> >>> │
>> >>>   │ needed by your Ethernet card, you can select it from the list."
>> >>
>> >> Do you have something akin to /sys/bus/sunv/devices/blah? With modalias
>> >> entries here and in the module the installer should be able to make the
>> >> connection between one and the other. For example for Xen virtual
>> >> devices we have:
>> >>di32:~# cat /sys/bus/xen/devices/vif-0/modalias
>> >>xen:vif
>> >>di32:~# modinfo xen-netfront
>> >>filename:   
>> >> /lib/modules/2.6.26-1-686-bigmem/kernel/drivers/net/xen-netfront.ko
>> >>alias:  xennet
>> >>alias:  xen:vif
>> >>license:GPL
>> >>description:Xen virtual network device frontend
>> >>depends:
>> >>vermagic:   2.6.26-1-686-bigmem SMP mod_unload modversions
>> >>686
>> >>
>> >> So the xen:vif modalias ties into the alias on the module.
>> >
>> > Ok, that's pretty interesting.  I suspect that the console support is
>> > compiled into the kernel via the CONFIG_LDOMS kernel option though
>> > (the net and disk are modules).  The giveaway for that would be the
>> > very sparse loaded module list:
>> >
>> > hostname:~# lsmod
>> > Module  Size  Used by
>> > ipv6  307168  72
>> > ext3  142672  2
>> > jbd50856  1 ext3
>> > sunvnet16132  0
>> > sunvdc 12168  5
>> >
>> > Theres some interesting things in dmesg about console shenanigans:
>> > hostname:~# dmesg | grep -E '(cons|tty|prom)'
>> > [0.00] console [earlyprom0] enabled
>> > [0.00] OF stdout device is: /virtual-devi...@100/cons...@1
>> > [22750.854590] console handover: boot [earlyprom0] -> real [tty0]
>> > [22755.397980] f02795dc: ttyS0 at I/O 0x0 (irq = 17) is a SUN4V HCONS
>> > [22755.400034] console [ttyHV0] enabled
>> >
>> > The console I'm having problems with is the virtual one where it
>> > simulates being 'at the console'.  From the primary LDOM (domain 0 in
>> > xenspeak), you telnet to localhost on a port and it dumps you to that
>> > console.
>> >
>> > The weird thing is that this console works completely fine during the
>> > debian-installer (even with colour and tabbing, etc.) but once you
>> > reboot into the new Debian install, the console is effectively
>> > 'read-only' (I see the login: prompt, but no matter what key
>> > combination I press, my typing does not show at the other side).
>> >
>> > The output of dmesg and a find in /sys are attached if you think
>> > perusing these will help...
>>
>> Ok, to answer my own question, this console seems to have become a
>> serial console after the reboot.  Just on a hunch I edited
>> /etc/inittab (via my ssh connection), uncommented the ttyS0 line (the
>> one you normally use to enable the serial console) and after an 'init
>> q' my virtual console that was open in another window sprang into life
>> with a normal banner.
>>
>> How you'd take care of that in the installer in a nice way, I have no idea...
>
> For Xen I had to add code to
> packages/finish-install/finish-install.d/90console to make this work.
> It's r54359 in the Debian installer SVN repo
> http://svn.debian.org/viewsvn/d-i?rev=54359&view=rev
>
> If your device is hvc0 as well then adding an || to that if statement
> seems reasonable.

Hi Ian,

Having found that it's the weird behaviour of LDOM changing the device
from one type to another, I think its fair to say its down to the
person doing the installing to make sure this is picked up properly,
it's just inconvenient rather than broken.  Although for a non-network
install you will have problems, so yeah, that kind of workaround is a
good idea, thanks.

The main concern I have is the autodetection of the hardware... I
don't know how the installer works enough to see what bit isn't
working there, so I'll have to do some digging :-(

Mike


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Pre-bug-raising questions

[Mike Grice]

On Mon, Jan 19, 2009 at 7:18 PM, Frans Pop  wrote:
> On Monday 19 January 2009, Mike Grice wrote:
>> So I guess the salient points from all the above are:
>>
>> 1) the debian-installer is not detecting the correct modules for the
>> hdd and net even though theyre present in the udebs
>>
>> 2) the initramfs-tools config on the installed system doesn't load the
>> relevant modules by default
>>
>> 3) the text console doesn't work once the install is finished and the
>> system is up as normal
>
> Just to make sure there are no false expectancies: we are about to upload
> the RC2 release of Debian Installer, which is expected to be the final
> release for Lenny.
>
> The issues you describe here are clearly not bugs, but a new feature. The
> detection/loading of modules is something that should preferably be done
> automatically by the kernel, although it can probably be worked around in
> the installer (if there is a clear way to recognize _when_ the modules
> should be loaded).

I'm not a d-i expert, but I guess the question is valid: who takes
responsibility for picking up hardware pertinent to installation?  I
(maybe incorrectly) assumed that the installer 'scanned' then enabled
this as appropriate. If its not the installer, can you let me know
which subsystem is?  I'm hoping to get Debian/sparc adopted fully at
work, but I'll not be able to do this unless it's a trivial deviation
from official release to remotely reproduce any such change.

> The "serial console" issue is probably relatively trivial to solve, but
> should still be done very carefully.

I agree with this part.  It's really the fault of the LDOM software,
the changing of type of console is a bit silly and creates extra
headache for users and maintainers.  I'm happy to have my own
implementation of the changes needed to /etc/inittab or whatever, on a
site basis (if anything generic gets cooked up of course i'll offer it
back).

> Conclusion: the needed changes will NOT be done before the release of
> Lenny. However, there is a slight chance they could be included in a
> later stable update. That mostly depends on whether someone is willing to
> do the work required for that.

I guess my main problem with that is that it rules out Debian for me
until at least Squeeze if I have to make big changes from the default
(which means I will end up on Solaris or can the whole project
entirely).  It's a shame, I love Debian and would love to implement
it.  If I could get a better understanding of the subsystems that are
responsible for making the decision what modules to probe, I could try
and learn and take a look and feed back the changes.  What bit of the
Debian system decides which modules to load?  Why does it work for one
driver and not another?

Thanks,
Mike.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Pre-bug-raising questions

[Frans Pop]

On Monday 19 January 2009, Mike Grice wrote:
> Having found that it's the weird behaviour of LDOM changing the device
> from one type to another,

That would indeed be very weird. Are you sure that that is what happens?

It seems more likely to me that maybe the _installer_ treats the device a 
bit differently than a regular system, just because its boot sequence is 
rather different.

> I think its fair to say its down to the person doing the installing to
> make sure this is picked up properly, it's just inconvenient rather than
> broken.

If it happens consistently I see no reason why the installer could not set 
up the inittab correctly. We already do so for other cases and to me this 
does seem to be in line with that.

The script Ian pointed you to is the correct one to look at. However, I'm 
not sure at this point which of the three existing categories (regular 
serial console; "onboard service processor"; Xen) this use case best 
matches. We'll need more detailed info for that (remote access to the 
system could maybe help at some point).

Cheers,
FJP

P.S. Please don't CC on replies. Anybody who replies obviously reads the 
list and it's against Debian list policy.


signature.asc
Description: This is a digitally signed message part.

Re: Pre-bug-raising questions

[Ian Campbell]

On Mon, 2009-01-19 at 19:46 +, Mike Grice wrote:
> On Mon, Jan 19, 2009 at 4:57 PM, Ian Campbell  wrote:
> > On Mon, 2009-01-19 at 16:43 +, Mike Grice wrote:
> >> 2009/1/19 Mike Grice :
> >> > On Mon, Jan 19, 2009 at 4:10 PM, Ian Campbell  
> >> > wrote:
> >> >> On Mon, 2009-01-19 at 14:12 +, Mike Grice wrote:
> >> >>>
> >> >>> Select a language: English
> >> >>> Choose Language: default
> >> >>> Detect Network Hardware:
> >> >>> "No Ethernet card was detected. If you know the name of the driver
> >> >>> │
> >> >>>   │ needed by your Ethernet card, you can select it from the list."
> >> >>
> >> >> Do you have something akin to /sys/bus/sunv/devices/blah? With modalias
> >> >> entries here and in the module the installer should be able to make the
> >> >> connection between one and the other. For example for Xen virtual
> >> >> devices we have:
> >> >>di32:~# cat /sys/bus/xen/devices/vif-0/modalias
> >> >>xen:vif
> >> >>di32:~# modinfo xen-netfront
> >> >>filename:   
> >> >> /lib/modules/2.6.26-1-686-bigmem/kernel/drivers/net/xen-netfront.ko
> >> >>alias:  xennet
> >> >>alias:  xen:vif
> >> >>license:GPL
> >> >>description:Xen virtual network device frontend
> >> >>depends:
> >> >>vermagic:   2.6.26-1-686-bigmem SMP mod_unload modversions
> >> >>686
> >> >>
> >> >> So the xen:vif modalias ties into the alias on the module.

> The main concern I have is the autodetection of the hardware... I
> don't know how the installer works enough to see what bit isn't
> working there, so I'll have to do some digging :-(

That's what the module alias stuff I describe above is all about, if
this is correct then the installer should Do The Right Thing.

-- 
Ian Campbell

BOFH excuse #244:

Your cat tried to eat the mouse.


signature.asc
Description: This is a digitally signed message part

live-cd, preseeding, sudo, sources.list

[schoappied]

Hi,

I have made an custom Debian live-cd, it has d-i included. Now I want to 
customize the d-i process a bit.


1) enable sudo (disable root)

2) add a custom sources.list


I've read a bit about preseeding, but where should I put the file on the 
live-cd? Should I do it before or after building that live-cd?


I've taken the example file from the manual as example. Do I get it 
right that if I comment out the lines, the default d-i option is used?



To enable sudo I have this in the file:

### Account setup
# Skip creation of a root account (normal user account will be able to
# use sudo).

d-i passwd/root-login boolean false

# Alternatively, to skip creation of a normal user account.
#d-i passwd/make-user boolean false


To enable a custom sources.list I have:

# Additional repositories, local[0-9] available
d-i apt-setup/local0/repository string \
#   http://local.server/debian stable main
ftp://ftp.debian.us/debian/ testing main contrib non-free

http://www.debian-multimedia.org/ testing main

http://ftp.us.debian.org/debian/ unstable main contrib non-free

http://ftp.uni-kl.de/debian-multimedia/ unstable main

#d-i apt-setup/local0/comment string local server
# Enable deb-src lines
d-i apt-setup/local0/source boolean true

# URL to the public key of the local repository; you must provide a key or
# apt will complain about the unauthenticated repository and so the
# sources.list line will be left commented out
#d-i apt-setup/local0/key string http://local.server/key

# By default the installer requires that repositories be authenticated
# using a known gpg key. This setting can be used to disable that
# authentication. Warning: Insecure, not recommended.
d-i debian-installer/allow_unauthenticated string true


( I've the keys already on the live-cd..)


Advise is welcome here!

Thanks in advance,

~d


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#512348: efi-reader: support for i386 and amd64.

[Kurt Roeckx]

Package: efi-reader
Severity: wishlist

EFI is supported i386 and amd64 too.  Can this package be made
available on them if it's useful?


Kurt




-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#512348: efi-reader: support for i386 and amd64.

[Frans Pop]

tag 512348 wontfix
thanks

On Monday 19 January 2009, Kurt Roeckx wrote:
> EFI is supported i386 and amd64 too.  Can this package be made
> available on them if it's useful?

efi-reader in its current for is NOT suitable for x86, so it would first 
have to be _made_ useful before this makes sense. It's actual current 
functionality is extremely limited and IMO does not really add any value 
to the installer.
It is even quite possible that it does not even work as intended with the 
current version of localechooser (after all, it has basically been 
unmaintained since 2005 and we've had HUGE changes in D-I since then).

If a proposal is submitted (after consensus preferably followed by 
patches) that would make efi-reader useful for x86 _and_ would ensure 
that it does not get in the way of installs on non-efi systems, we will 
reconsider this.

Cheers,
FJP



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: Bug#512348: efi-reader: support for i386 and amd64.

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tag 512348 wontfix help
Bug#512348: efi-reader: support for i386 and amd64.
There were no tags set.
Tags added: wontfix, help

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [RFC] New "installer-settings" component - please test and comment!

[Frans Pop]

On Tuesday 13 January 2009, Frans Pop wrote:
> Over the past months I've been working on a new component that allows
> to change "settings" for the installer. Main intention is to improve
> the flexibility of the installer and the user experience.

Not that much feedback, but I guess that was to be expected :-(
So, let me explain what this is all about.

There are several things that I've never really liked about the 
current "expert mode":
* default install offers too few options for quite a few users, but
  expert mode immediately goes to the lowest possible level: there
  is no graceful way to select intermediate levels
* medium priority (which I've personally always preferred over low
  priority) is effectively inaccessible to users and unused in
  practice
* showing the menu is coupled hard to priority levels, even though for
  debugging it would be quite nice if you could run an install at high
  prio but _with_ menu, and for "expert" installs it would be quite nice
  if you could run at medium prio but _without_ menu (as users in
  principle have no need to skip installation steps or change the order
  of installation steps)

Another issue is that we do have some specific options in D-I (PPPoE, 
dmraid, multipath) that I would personally like to see remain as optional 
features, but we currently don't have any user-friendly way to activate 
support for such option.

installer-settings is intended to solve all of these issues.

Flexible and gradual "expert" support
=
In its current implementation installer-settings does *not* change default 
installs: no extra dialogs, no changes in the installation order.
Only if you back up to the main menu you will see a new option "Installer 
settings" that allows to change settings that are relevant at that point 
of the installation. It also allows to change the debconf priority and 
whether or not to display the main menu.

Expert installs are changed. A lot!

* Instead of 'priority=low' the syslinux config will now add
  'expert=true'. In other words: when the installer is started the
  priority is *high*, just as for a default install.
* localechooser checks this expert setting and if set displays its
  "medium prio dialogs" (e.g. locale selection) at high priority.
* After locale and keyboard selection a "early installer settings"
  dialog is displayed. This allows the user to select the "expert
  level" at which he wishes to continue the installation.
* After "anna" a second "installer settings" dialog is displayed.
  This will allow to change settings for components that were not
  available before anna and settings which will never be relevant
  during the early stages of the installation.

All this results in the following "modes" being available to users:
1) automated/preseeded install (critical priority): installer-settings
   is disabled
2) default install
3) expert mode:
   a) "default level": remain at high priority, but with option to
  change settings (for example: to activate dmraid support)
   b) same as a) but with main menu displayed between components
   c) "advanced level": medium priority, without main menu (by default
  it is displayed, but it can now be disabled)
   d) same as c) but with main menu
   e) could be implemented as either "expert level" or as "debug level";
  in either case: low priority (menu will always be displayed)
4) rescue mode

When this is implemented the priority level of some dialogs should 
probably be adjusted. For example: the grub password dialog should be 
displayed at medium priority.
Some existing dialogs could possibly be implemented as a "setting", in 
which case the priority of the dialog itself should be lowered to low 
priority.

Implementation
==
installer-settings has a drop-in structure to add settings somewhat 
similar to partman. This means that the code that implements an 
individual setting can be part of the relevant component. Example: the 
settings for dmraid and multipath are implemented in disk-detect.

See /usr/lib/settings/*/ in the test images for examples.

installer-settings itself has absolutely no state info: it exclusively 
uses state (debconf values) from the component to which a setting 
belongs. This means that it does not interfere in any way with for 
example preseeding.

installer-settings itself consists of 4 udebs:
- installer-settings: core functionality
- settings-early: provides the settings menu entry after
  locale/kbd-chooser
- settings-anna: provides the settings menu entry after anna
- settings-menu: provides the permanent optional settings menu entry

Settings can be defined very flexibly:
- limit to settings-early/anna/menu
- only show at certain debconf priorities
- only show based on scripted logic ("choices" script)
- warn or don't show if certain installation steps have already been run

Settings can be coded to be changed either by just hitting  on 
them, or by displaying a dialog.

Size impact
---

Re: r57367 - trunk/packages/cdebconf-terminal/debian

[Frans Pop]

On Tuesday 20 January 2009, Colin Watson wrote:
> Author: cjwatson
> Date: Mon Jan 19 23:36:21 2009
> New Revision: 57367
>
> Log:
> cdebconf-gtk-terminal Provides: cdebconf-terminal, not
> cdebconf-entropy.
> --- trunk/packages/cdebconf-terminal/debian/control   (original)
> +++ trunk/packages/cdebconf-terminal/debian/control   Mon Jan 19 23:36:21
> 2009 @@ -11,7 +11,7 @@
>  Architecture: any
>  Section: debian-installer
>  Depends: cdebconf-gtk-udeb, ttf-dejavu-mono-udeb, ${shlibs:Depends}
> -Provides: cdebconf-entropy
> +Provides: cdebconf-terminal
>  XC-Package-Type: udeb
>  Description: cdebconf gtk plugin displaying a terminal
>   cdebconf plugin to display a terminal inside the debian-installer
>   graphical

I wonder if that will cause problems for Lenny installs. It is quite 
likely that it has escaped testing efforts if it does...

Nice catch BTW.


signature.asc
Description: This is a digitally signed message part.

Bug#512355: installation-report: Graphical Expert Install sucessfully

[Rafael Belmonte]

Package: installation-reports
Version: 2.38
Severity: normal



-- Package-specific info:

Boot method: CD
Image version: Official RC i386 NETINST Binary-1 20081104-23:47
Date: CD was downloaded and installed january, 04, 2009.

Machine: Acer Aspire 2920Z
Partitions:
/dev/sda:
sda1: NTFS do not used.
sda2: ext3 do not used.
sda3: FAT32 do not used.
sda4: Extended partition.
sda5: Logical, ext3 do not used.
sda6: Logical, ext3 do not used.
sda7: Logical, ext3 do not used.
sda8: Logical, ext3 used as root /
sda9: Logical, Linux Swap used as swap.

/dev/sdb:
sdb1: NTFS do not used.


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

I would like to see CD set back again.


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="5.0 (lenny) - installer build 20081029"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
umame -a: Linux rafadeb 2.6.26-1-486 #1 Thu Oct 9 14:22:52 UTC 2008 i686 unknown
lspci -knn: 00:00.0 Host bridge [0600]: Silicon Integrated Systems [SiS] 
SiS645DX Host & Memory & AGP Controller [1039:0646]
lspci -knn: 00:01.0 PCI bridge [0604]: Silicon Integrated Systems [SiS] Virtual 
PCI-to-PCI bridge (AGP) [1039:0001]
lspci -knn: 00:02.0 ISA bridge [0601]: Silicon Integrated Systems [SiS] SiS962 
[MuTIOL Media IO] [1039:0962] (rev 04)
lspci -knn: 00:02.1 SMBus [0c05]: Silicon Integrated Systems [SiS] SiS961/2 
SMBus Controller [1039:0016]
lspci -knn: 00:02.5 IDE interface [0101]: Silicon Integrated Systems [SiS] 5513 
[IDE] [1039:5513]
lspci -knn: Kernel driver in use: SIS_IDE
lspci -knn: Kernel modules: sis5513
lspci -knn: 00:03.0 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 
1.1 Controller [1039:7001] (rev 0f)
lspci -knn: Kernel driver in use: ohci_hcd
lspci -knn: Kernel modules: ohci-hcd
lspci -knn: 00:03.1 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 
1.1 Controller [1039:7001] (rev 0f)
lspci -knn: Kernel driver in use: ohci_hcd
lspci -knn: Kernel modules: ohci-hcd
lspci -knn: 00:03.2 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 
1.1 Controller [1039:7001] (rev 0f)
lspci -knn: Kernel driver in use: ohci_hcd
lspci -knn: Kernel modules: ohci-hcd
lspci -knn: 00:03.3 USB Controller [0c03]: Silicon Integrated Systems [SiS] USB 
2.0 Controller [1039:7002]
lspci -knn: Kernel driver in use: ehci_hcd
lspci -knn: Kernel modules: ehci-hcd
lspci -knn: 00:05.0 Multimedia audio controller [0401]: C-Media Electronics Inc 
CM8738 [13f6:0111] (rev 10)
lspci -knn: 00:0a.0 Multimedia video controller [0400]: Brooktree Corporation 
Bt878 Video Capture [109e:036e] (rev 02)
lspci -knn: 00:0a.1 Multimedia controller [0480]: Brooktree Corporation Bt878 
Audio Capture [109e:0878] (rev 02)
lspci -knn: 00:0c.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ [10ec:8139] (rev 10)
lspci -knn: Kernel driver in use: 8139too
lspci -knn: Kernel modules: 8139too, 8139cp
lspci -knn: 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc 
RV280 [Radeon 9200 PRO] [1002:5960] (rev 01)
lspci -knn: 01:00.1 Display controller [0380]: ATI Technologies Inc RV280 
[Radeon 9200 PRO] (Secondary) [1002:5940] (rev 01)
lsmod: Module  Size  Used by
lsmod: nls_cp437   5504  0 
lsmod: ufs63620  0 
lsmod: qnx47684  0 
lsmod: ntfs  180416  0 
lsmod: dm_mod 45384  0 
lsmod: md_mod 65940  0 
lsmod: xfs   446836  0 
lsmod: reiserfs  187008  0 
lsmod: jfs   148060  0 
lsmod: ext3  103432  1 
lsmod: jbd35092  1 ext3
lsmod: vfat8832  0 
lsmod: fat39964  1 vfat
lsmod: ext2   52616  0 
lsmod: mbcache 6656  2 ext3,ext2
lsmod: 8139too20096  0 
lsmod: 8139cp 17024  0 
lsmod: mii 4864  2 8139too,8139cp
lsmod: nls_utf81664  2 
lsmod: isofs  2768

Re: Limitar taxa de download por IP

[Felipe Augusto van de Wiel (faw)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jose, a resposta em português está abaixo da sua pergunta.

To debian-boot: Jose is asking help to limit the bandwidth rate by
IP address, I'm pointing him to -user-portuguese and explaining
what -boot is about.


On 16-01-2009 23:14, Jose Edmilson dos Santos wrote:
> Gostaria de sabe se é possível e como fazer para limitar a taxa de
> download por ip numa rede.
> 
> Minha versão é o Debian GUN/Linux 4.0
> 
> Obrigado.

Jose,

A debian-boot é uma lista em inglês e ela é voltada para o
desenvolvimento do Debian Installer. Para suporte técnico e outras
dúvidas como a sua, use a d-u-p:

http://lists.debian.org/debian-user-portuguese

Abraço,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl1XqgACgkQCjAO0JDlykYvFgCghD147HJdtKey2IW2k/vYtFEZ
vHIAoJ5376Fljy9lxPuD9gMC77flV9rb
=zMpF
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

D-I build (was: Re: Release?)

[Christian Perrier]

(again sorry for appearing to push hard, here)


Now that all unblocks were requested (as I tried to track on
LennyRC2Prep), I suppose the next step is to build and upload D-I,
right?

I have a pending commit in webwml for the errata and home pages, just
tell me when to commit it.





signature.asc
Description: Digital signature