Bug#408588: Debian on SGI Altix IA-64
On Fri, Feb 02, 2007 at 01:25:39PM -0500, St?phane Larose wrote:
I agree - not creating the serial device would be a problem for a pci serial
card.
Ok, let's drop this option then
Is there a way we can support both? What if we create a ttySG0 file in
init-udev-devices and pass console=ttySG0 to the kernel[2]?
If that works, I don't think its a big deal to ask altix users to pass
console=ttySG0 to the installer - we could even put it in the elilo
help menu (which isn't localized).
St?phane: can you test these two patches and report back what works?
If /proc isn't mounted at this point, you might remove the if
statement around [2].
The first patch works. When testing the second one, I realized that passing
console=xx or CONSOLE=xx is not the same (sorry about that). console in
lowercase is used by the kernel as the console and not keep as an environment
variable. Using CONSOLE in uppercase is not used by the kernel but passed as
an environment variable.
The way I read the busybox source, it looks for CONSOLE= first then
console=:
static void console_init(void)
{
...
if ((s = getenv(CONSOLE)) != NULL || (s = getenv(console)) != NULL)
{
safe_strncpy(console, s, sizeof(console));
...
I don't really understand how kernel command line options become env
vars though - is something preventing console= from being an env var
at this point?
--
dann frazier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408588: Debian on SGI Altix IA-64
On Thursday 08 February 2007 09:56, you wrote: I don't really understand how kernel command line options become env vars though - is something preventing console= from being an env var at this point? I think console parameter is probably filtered out by the kernel (the initrd parameter seems to be filtered out too). pgphJpFBXTS8A.pgp Description: PGP signature
Bug#408588: Debian on SGI Altix IA-64
On Thu, February 8, 2007 13:11, Frans Pop said: On Thursday 08 February 2007 09:56, you wrote: I don't really understand how kernel command line options become env vars though - is something preventing console= from being an env var at this point? I think console parameter is probably filtered out by the kernel (the initrd parameter seems to be filtered out too). Anything which is not understood by the kernel is added to init's env and vice versa (see the kernel sources, file init/main.c, function unknown_bootoption) -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408588: Debian on SGI Altix IA-64
On Thursday 01 February 2007 01:02, dann frazier wrote: Is /proc mounted at this point? Yes it is. If so, then that's probably the best detection method available for etch. We could do something like [1] and not create the serial devices - but that feels like a hack to me. What if someone put a serial pci card in one of these machines and wanted to use that as a console? I agree - not creating the serial device would be a problem for a pci serial card. Is there a way we can support both? What if we create a ttySG0 file in init-udev-devices and pass console=ttySG0 to the kernel[2]? If that works, I don't think its a big deal to ask altix users to pass console=ttySG0 to the installer - we could even put it in the elilo help menu (which isn't localized). St?phane: can you test these two patches and report back what works? If /proc isn't mounted at this point, you might remove the if statement around [2]. The first patch works. When testing the second one, I realized that passing console=xx or CONSOLE=xx is not the same (sorry about that). console in lowercase is used by the kernel as the console and not keep as an environment variable. Using CONSOLE in uppercase is not used by the kernel but passed as an environment variable. Busybox tries to use the CONSOLE env. var. (if present) to know which device to open. So using console=ttySG0 is not working because there is no env. var. set and busybox will then use /dev/tts/0. If I put CONSOLE=ttySG0 it works. In fact, putting CONSOLE=whatYouWant will work because busybox will try to open 'whatYouWant', it will fail, then it will fallback to the default /dev/console which works. When booted, if I look at the /proc/self/fd/ links, they point to /dev/console. The only way to have those links point to /dev/ttySG0 is to pass CONSOLE=/dev/ttySG0 (/dev/ is important in this case because busybox don't add it if you just pass ttySG0), and to have the /dev/ttySG0 device created with the patch number 2. So I can boot with no patches if I put CONSOLE=something and this will have the effect of using /dev/console. I can also boot with patch 2 and CONSOLE=/dev/ttySG0 and this will have the effect of using /dev/ttySG0. Maybe this information will give a hint on how to solve the last console problem which is the 90console post-install script that dosn't activate a console tty login in /etc/inittab and put that console in /etc/securetty on Altix. Stéphane
Bug#408588: Debian on SGI Altix IA-64
On Mon, Jan 29, 2007 at 09:39:08AM -0500, St?phane Larose wrote: On Saturday 27 January 2007 23:21, Joey Hess wrote: I'm not 100% sure, but I think that this is happening before udev gets a chance to make it, since it's prior to init starting. This is correct. And after init, udev create the /dev/ttySG0 device correctly. Seems like we could fix it by making init-udev-devices skip creation of /dev/tts/0, if running on the altix. What would be a good way to detect that machine? I don't know if this is a good way but if the /proc/sgi_sn/ directory exist, it means that the 'sn' driver is loaded which is SGI architecture. Is /proc mounted at this point? If so, then that's probably the best detection method available for etch. We could do something like [1] and not create the serial devices - but that feels like a hack to me. What if someone put a serial pci card in one of these machines and wanted to use that as a console? Is there a way we can support both? What if we create a ttySG0 file in init-udev-devices and pass console=ttySG0 to the kernel[2]? If that works, I don't think its a big deal to ask altix users to pass console=ttySG0 to the installer - we could even put it in the elilo help menu (which isn't localized). St?phane: can you test these two patches and report back what works? If /proc isn't mounted at this point, you might remove the if statement around [2]. [1] Index: src/lib/debian-installer/init-udev-devices === --- src/lib/debian-installer/init-udev-devices (revision 44839) +++ src/lib/debian-installer/init-udev-devices (working copy) @@ -22,7 +22,7 @@ makedev 600 /dev/tty$i c 4 $i done makedir 755 /dev/tts -for i in 0 1; do +[ -d /proc/sgi_sn ] || for i in 0 1; do makedev 600 /dev/tts/$i c 4 $(($i + 64)) makedev 600 /dev/ttyS$i c 4 $(($i + 64)) done [2] Index: src/lib/debian-installer/init-udev-devices === --- src/lib/debian-installer/init-udev-devices (revision 44839) +++ src/lib/debian-installer/init-udev-devices (working copy) @@ -26,3 +26,7 @@ makedev 600 /dev/tts/$i c 4 $(($i + 64)) makedev 600 /dev/ttyS$i c 4 $(($i + 64)) done +# SGI Altix consoles +if [ -d /proc/sgi_sn ]; then + makedev 600 /dev/ttySG0 c 204 40 +fi -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408588: Debian on SGI Altix IA-64
On Saturday 27 January 2007 23:21, Joey Hess wrote: I'm not 100% sure, but I think that this is happening before udev gets a chance to make it, since it's prior to init starting. This is correct. And after init, udev create the /dev/ttySG0 device correctly. Seems like we could fix it by making init-udev-devices skip creation of /dev/tts/0, if running on the altix. What would be a good way to detect that machine? I don't know if this is a good way but if the /proc/sgi_sn/ directory exist, it means that the 'sn' driver is loaded which is SGI architecture. Stéphane
Bug#408588: Debian on SGI Altix IA-64
On Thursday 25 January 2007 19:57, Stéphane Larose wrote: In kernel 2.6.7, there is a new serial console driver for the Altix L1 (CONFIG_SERIAL_SGI_L1_CONSOLE=y) and the device is /dev/ttySG0. I think this device gets associated with /dev/console in the d-i because, if I create it (just before busybox init starts): mknod ttySG0 c 204 40 The fact that /dev/ttySG0 does not get created is a kernel/udev issue as far as I know. After that is solved, passing 'console=/dev/ttySG0' as a boot parameter to the installer should make things work correctly. 2- creating the /dev/ttySG0 device in the init-udev-devices script AFAIK this should not be needed. On powerpc they use various weird serial devices as well, and AFAIK these are not created manually either. IMO the IA-64 porters should look at this whole issue. Dann: Could you take a look at this BR? Cheers. FJP pgpxURYrjpKxv.pgp Description: PGP signature
Bug#408588: Debian on SGI Altix IA-64
Frans Pop wrote: The fact that /dev/ttySG0 does not get created is a kernel/udev issue as far as I know. After that is solved, passing 'console=/dev/ttySG0' as a boot parameter to the installer should make things work correctly. I'm not 100% sure, but I think that this is happening before udev gets a chance to make it, since it's prior to init starting. -- see shy jo signature.asc Description: Digital signature
Bug#408588: Debian on SGI Altix IA-64 (follow-up)
Package: rootskel
Reply below..
Stéphane Larose wrote:
Hi,
At the end of December, I posted on this list about booting and running
Debian
etch on SGI Altix 350. There was basically 3 things to modify on the netinst
cd to make it boot and install:
- putting 'relocatable' in elilo.conf (done - thanks to Dann Frazier)
- adding some modules to the d-i kernel (done - thanks to Dann Frazier)
- modifying something with the console device since we lose the console
output
when booting the cd (just when init - or busybox init starts)
The trick I found to get the console output after init starts was to comment
out this line:
makedev 600 /dev/tts/$i c 4 $(($i + 64))
in /lib/debian-installer/init-udev-devices. I've done some research to know
exactly why this make the console output work.
In kernel 2.6.7, there is a new serial console driver for the Altix L1
(CONFIG_SERIAL_SGI_L1_CONSOLE=y) and the device is /dev/ttySG0. I think this
device gets associated with /dev/console in the d-i because, if I
create it (just before busybox init starts):
mknod ttySG0 c 204 40
and
echo something /dev/ttySG0 or
echo something /dev/console
both will echo.
Then I looked at how busybox init was choosing the console and found out that
this part of code is being executed:
... (from busybox init.c source)
if (ioctl(0, TIOCGSERIAL, sr) == 0) {
/* this is a serial console */
snprintf(console, sizeof(console) - 1, SC_FORMAT, sr.line);
...
while ((fd = open(console, O_RDONLY | O_NONBLOCK)) 0 tried 2) {
/* Can't open selected console -- try
logical system console and VT_MASTER */
safe_strncpy(console, (tried == 0 ? _PATH_CONSOLE : CURRENT_VC),
sizeof(console));
...
So sr.line is set to 0 which seems correct but the SC_FORMAT variable
is '/dev/tts/' (hard-coded) resulting in console=/dev/tts/0 instead
of /dev/ttySG0.
On the d-i CD, /dev/tts/0 is created by
the /lib/debian-installer/init-udev-devices script, so busybox will try to
open it and will succeed but this device is not the correct one on the Altix
so no more console output after busybox init.
If I delete /dev/tts/0 (or comment out the line to create this device in the
init-udev-devices script), the 'open' call of busybox will fail so busybox
will retry with console=_PATH_CONSOLE (which is defined as /dev/console) and
this will work since we effectively are on /dev/console (/dev/ttySG0) during
the Debian installation on Altix.
That is what I think creates the problem with console output when installing
on Altix. I don't know what is the best solution to correct this but maybe:
1- patching busybox so that SC_FORMAT would be /dev/ttySG on Altix (if kernel
2.6.7)
2- creating the /dev/ttySG0 device in the init-udev-devices script
I don't know how doable #1 is (would need some way for busybox to detect
this machine), so I'm focusing on #2.
However, I'm not sure why creating the /dev/ttySG0 device would work.
From your description it sounds like busybox init would still try to use
the hardcoded /dev/tts/0 device instead.
Seems like we could fix it by making init-udev-devices skip creation of
/dev/tts/0, if running on the altix. What would be a good way to detect
that machine?
--
see shy jo
signature.asc
Description: Digital signature
