Bug#420820: no console set IBM p5 server
On Wednesday 16 May 2007 19:41, Rolf Brudeseth wrote: I tested the script with the console attached to serial port 1 and 2 (hvsi0 and hvsi1). I had to make some minor changes to the script to get it to work. Thanks. Sorry for the delay, but here is a new version of the script. It now uses the device from chosen and fixes the problem of the newline after the co: line. Here is another thought. Could you test if creating a getty line using /dev/console just magically works? Given the fact that the installer does not need any special setup and uses /dev/console, that might just do it. It would remove the need to figure out exactly what type of virtual console is being used and that would simplify the patch a lot. I suspect the alternative attached script might just work. Cheers, FJP 90console Description: application/shellscript 90console_alt Description: application/shellscript
Bug#420820: no console set IBM p5 server
Here is another thought. Could you test if creating a getty line using /dev/console just magically works? Given the fact that the installer does not need any special setup and uses /dev/console, that might just do it. It would remove the need to figure out exactly what type of virtual console is being used and that would simplify the patch a lot. I suspect the alternative attached script might just work. I changed /etc/inittab as follows: #co:2345:respawn:/sbin/getty hvsi0 9600 vt100 co:2345:respawn:/sbin/getty console 9600 vt100 In the example below I can log inn and execute 'su' successfully; however, I get following echo'ed to the screen: no job control in this shell Debian GNU/Linux 4.0 hv2pos console hv2pos login: rolfb Password: Last login: Fri May 25 14:25:57 2007 on hvsi0 Linux hv2pos 2.6.18-4-powerpc64 #1 SMP Fri May 4 07:57:01 UTC 2007 ppc64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. -bash: no job control in this shell $ $ su - Password: -su: no job control in this shell # Rolf
Bug#420820: no console set IBM p5 server
On Wed, May 16, 2007 at 12:41:18PM -0500, Rolf Brudeseth wrote: I tested the script with the console attached to serial port 1 and 2 (hvsi0 and hvsi1). I had to make some minor changes to the script to get it to work. I don't know, but you may want to implement the changes differently. Regardless, before you submit the final 90console script, I assume I need to figure out how to detect whether a graphics monitor is used as the console, as well as how the ATX workstation behaves. Hi Rolf, ... I have a question here. Is this a safe way to handle this ? The options contain the variables of the OF, set by the user, but it is also possible to boot directly from the OF command line, bypassing the values found in options, or have special values passed from yaboot. On the pegasos, but i suppose the same holds true for IBM power boxes, i know it is even possible to pass these special values by the DHCP server. This would typically be done in a d-i install, where you want to over-ride the defaults, without changing the real values. I know i have done so myself. So, all in all, it is much better to do the same using the chosen properties, which is what should be used on CHRP for this kind of things, and is also said to be so in the CHRP spec. If you don't believe me, or otherwise ignore me, just ask someone with a clue on this and they will tell you so. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Wed, May 16, 2007 at 12:41:18PM -0500, Rolf Brudeseth wrote: I tested the script with the console attached to serial port 1 and 2 (hvsi0 and hvsi1). I had to make some minor changes to the script to get it to work. I don't know, but you may want to implement the changes differently. Regardless, before you submit the final 90console script, I assume I need to figure out how to detect whether a graphics monitor is used as the console, as well as how the ATX workstation behaves. Hi Rolf, ... I have a question here. Is this a safe way to handle this ? The options contain the variables of the OF, set by the user, but it is also possible to boot directly from the OF command line, bypassing the values found in options, or have special values passed from yaboot. On the pegasos, but i suppose the same holds true for IBM power boxes, i know it is even possible to pass these special values by the DHCP server. This would typically be done in a d-i install, where you want to over-ride the defaults, without changing the real values. I know i have done so myself. So, all in all, it is much better to do the same using the chosen properties, which is what should be used on CHRP for this kind of things, and is also said to be so in the CHRP spec. If you don't believe me, or otherwise ignore me, just ask someone with a clue on this and they will tell you so. I am not ignoring you, just slow at responding. I am getting input from folks that are not adding their comments to this bug, and I am no Open Firmware expert so it is taking me some time to wrap my head around this. But I am happy to change the script if you think I am not implenting the changes in the optimum way. $ ls -l /proc/device-tree/chosen/ total 16 -r--r--r-- 1 root root 19 2007-05-17 10:23 bootargs -r--r--r-- 1 root root 58 2007-05-17 10:23 bootpath -r--r--r-- 1 root root 4 2007-05-17 10:23 cpu -r--r--r-- 1 root root 40 2007-05-17 10:23 ibm,rpa-client-config -r--r--r-- 1 root root 8 2007-05-17 10:23 linux,initrd-end -r--r--r-- 1 root root 8 2007-05-17 10:23 linux,initrd-start -r--r--r-- 1 root root 8 2007-05-17 10:23 linux,kernel-end -r--r--r-- 1 root root 4 2007-05-17 10:23 linux,phandle -r--r--r-- 1 root root 4 2007-05-17 10:23 linux,stdout-package -r--r--r-- 1 root root 22 2007-05-17 10:23 linux,stdout-path -r--r--r-- 1 root root 4 2007-05-17 10:23 memory -r--r--r-- 1 root root 4 2007-05-17 10:23 mmu -r--r--r-- 1 root root 7 2007-05-17 10:23 name -r--r--r-- 1 root root 4 2007-05-17 10:23 nvram -r--r--r-- 1 root root 4 2007-05-17 10:23 stdin -r--r--r-- 1 root root 4 2007-05-17 10:23 stdout I see that the following two files report the node, so changing the script to use 'chosen' instead, and testing it on my hardware is no problem. $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] $ cat /proc/device-tree/chosen/linux,stdout-path /vdevice/[EMAIL PROTECTED] But I can not find an equivalent method in 'chosen' to determine whether the console is mapped to hvsi0 or hvc0. $ cat /proc/device-tree/vdevice/[EMAIL PROTECTED]/compatible hvterm-protocol Let me know what I should use. I can either modify the script myself or if you prefer you can send me a new one. Either way I can test it. Friendly, Sven Luther
Bug#420820: no console set IBM p5 server
On Thu, May 17, 2007 at 10:44:41AM -0500, Rolf Brudeseth wrote: On Wed, May 16, 2007 at 12:41:18PM -0500, Rolf Brudeseth wrote: I tested the script with the console attached to serial port 1 and 2 (hvsi0 and hvsi1). I had to make some minor changes to the script to get it to work. I don't know, but you may want to implement the changes differently. Regardless, before you submit the final 90console script, I assume I need to figure out how to detect whether a graphics monitor is used as the console, as well as how the ATX workstation behaves. Hi Rolf, ... I have a question here. Is this a safe way to handle this ? The options contain the variables of the OF, set by the user, but it is also possible to boot directly from the OF command line, bypassing the values found in options, or have special values passed from yaboot. On the pegasos, but i suppose the same holds true for IBM power boxes, i know it is even possible to pass these special values by the DHCP server. This would typically be done in a d-i install, where you want to over-ride the defaults, without changing the real values. I know i have done so myself. So, all in all, it is much better to do the same using the chosen properties, which is what should be used on CHRP for this kind of things, and is also said to be so in the CHRP spec. If you don't believe me, or otherwise ignore me, just ask someone with a clue on this and they will tell you so. I am not ignoring you, just slow at responding. I am getting input from folks that are not adding their comments to this bug, and I am no Open Firmware expert so it is taking me some time to wrap my head around this. But I am happy to change the script if you think I am not implenting the changes in the optimum way. $ ls -l /proc/device-tree/chosen/ total 16 -r--r--r-- 1 root root 19 2007-05-17 10:23 bootargs -r--r--r-- 1 root root 58 2007-05-17 10:23 bootpath -r--r--r-- 1 root root 4 2007-05-17 10:23 cpu -r--r--r-- 1 root root 40 2007-05-17 10:23 ibm,rpa-client-config -r--r--r-- 1 root root 8 2007-05-17 10:23 linux,initrd-end -r--r--r-- 1 root root 8 2007-05-17 10:23 linux,initrd-start -r--r--r-- 1 root root 8 2007-05-17 10:23 linux,kernel-end -r--r--r-- 1 root root 4 2007-05-17 10:23 linux,phandle -r--r--r-- 1 root root 4 2007-05-17 10:23 linux,stdout-package -r--r--r-- 1 root root 22 2007-05-17 10:23 linux,stdout-path -r--r--r-- 1 root root 4 2007-05-17 10:23 memory -r--r--r-- 1 root root 4 2007-05-17 10:23 mmu -r--r--r-- 1 root root 7 2007-05-17 10:23 name -r--r--r-- 1 root root 4 2007-05-17 10:23 nvram -r--r--r-- 1 root root 4 2007-05-17 10:23 stdin -r--r--r-- 1 root root 4 2007-05-17 10:23 stdout I see that the following two files report the node, so changing the script to use 'chosen' instead, and testing it on my hardware is no problem. $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] $ cat /proc/device-tree/chosen/linux,stdout-path /vdevice/[EMAIL PROTECTED] But I can not find an equivalent method in 'chosen' to determine whether the console is mapped to hvsi0 or hvc0. $ cat /proc/device-tree/vdevice/[EMAIL PROTECTED]/compatible hvterm-protocol Well once you have seen that chosen/linux,stdout-path points to [EMAIL PROTECTED], then you can revert to using the normal device tree for the compatible function. The main point is to use chosen to know what was done at boot time, since chosen is set either by the OF or thebootloader to inform the client program (in this case linux) about the different choices which where made at boot time. The options entry is no guarantee whatsoeve, just information about what the default option can be, but it can be overriden. Notice also, that stdin and stdout, should be two devices wxhich can be used to actually output and input information, altough i am not sure how this is supposed to work. Normally you could just ignore any of these choices, and simply have the chosen/stdin and cvhosen stdout used. Friendly, Sven Luther Let me know what I should use. I can either modify the script myself or if you prefer you can send me a new one. Either way I can test it. Friendly, Sven Luther --- Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
I tested the script with the console attached to serial port 1 and 2 (hvsi0 and hvsi1). I had to make some minor changes to the script to get it to work. I don't know, but you may want to implement the changes differently. Regardless, before you submit the final 90console script, I assume I need to figure out how to detect whether a graphics monitor is used as the console, as well as how the ATX workstation behaves. Rolf $ diff -u 90console 90console.orig --- 90console 2007-05-16 10:28:13.0 -0500 +++ 90console.orig 2007-05-16 11:10:09.0 -0500 @@ -52,8 +52,8 @@ if [ -e $DT_ROOT/options/output-device ]; then OD=$(cat $DT_ROOT/options/output-device) case $OD in - /vdevice/[EMAIL PROTECTED]) - case $(cat $DT_ROOT$OD/compatible) in + [EMAIL PROTECTED]) + case $(cat $DT_ROOT/vdevice/$OD/compatible) in hvterm-protocol) console=hvsi0 ;; hvterm|hvterm1) @@ -64,7 +64,7 @@ ;; esac ;; - /vdevice/[EMAIL PROTECTED]) + [EMAIL PROTECTED]) console=hvsi1 ;; *) exit 0 ;; @@ -80,7 +80,7 @@ sed -i -e s|^#\?co:.*$|$console_line| \ /target/etc/inittab else - sed -i -e /^#1:/i\\$console_line \ + sed -i -e /^#1:/i\$console_line\n \ /target/etc/inittab fi fi It is somewhat odd, but sed and '\n' behaves differently on my laptop where I tested the script. With the installer, no matter how many '\' I use, I either get 'n' or '\n' added to the end of the line, but not a newline. I tested both sed expressions that add the console entry. That is, insert versus replace. hvsi0 = $ cat /etc/inittab # /etc/inittab: init(8) configuration. # $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $ # The default runlevel. id:2:initdefault: # Boot-time system configuration/initialization script. # This is run first except when booting in emergency (-b) mode. si::sysinit:/etc/init.d/rcS # What to do in single-user mode. ~~:S:wait:/sbin/sulogin # /etc/init.d executes the S and K scripts upon change # of runlevel. # # Runlevel 0 is halt. # Runlevel 1 is single-user. # Runlevels 2-5 are multi-user. # Runlevel 6 is reboot. l0:0:wait:/etc/init.d/rc 0 l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/rc 6 # Normally not reached, but fallthrough in case of emergency. z6:6:respawn:/sbin/sulogin # What to do when CTRL-ALT-DEL is pressed. ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now # Action on special keypress (ALT-UpArrow). #kb::kbrequest:/bin/echo Keyboard Request--edit /etc/inittab to let this work. # What to do when the power fails/returns. pf::powerwait:/etc/init.d/powerfail start pn::powerfailnow:/etc/init.d/powerfail now po::powerokwait:/etc/init.d/powerfail stop # /sbin/getty invocations for the runlevels. # # The id field MUST be the same as the last # characters of the device (after tty). # # Format: # id:runlevels:action:process # # Note that on most Debian systems tty7 is used by the X Window System, # so if you want to add more getty's go ahead but skip tty7 if you run X. # co:2345:respawn:/sbin/getty hvsi0 9600 vt100 #1:2345:respawn:/sbin/getty 38400 tty1 #2:23:respawn:/sbin/getty 38400 tty2 #3:23:respawn:/sbin/getty 38400 tty3 #4:23:respawn:/sbin/getty 38400 tty4 #5:23:respawn:/sbin/getty 38400 tty5 #6:23:respawn:/sbin/getty 38400 tty6 # Example how to put a getty on a serial line (for a terminal) # #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100 #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100 # Example how to put a getty on a modem line. # #T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3 hvsi1 = $ cat /etc/inittab # /etc/inittab: init(8) configuration. # $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $ # The default runlevel. id:2:initdefault: # Boot-time system configuration/initialization script. # This is run first except when booting in emergency (-b) mode. si::sysinit:/etc/init.d/rcS # What to do in single-user mode. ~~:S:wait:/sbin/sulogin # /etc/init.d executes the S and K scripts upon change # of runlevel. # # Runlevel 0 is halt. # Runlevel 1 is single-user. # Runlevels 2-5 are multi-user. # Runlevel 6 is reboot. l0:0:wait:/etc/init.d/rc 0 l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/rc 6 # Normally not reached, but fallthrough in case of emergency. z6:6:respawn:/sbin/sulogin # What to do when CTRL-ALT-DEL is pressed. ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now # Action on special keypress (ALT-UpArrow). #kb::kbrequest:/bin/echo
Bug#420820: no console set IBM p5 server
On Monday 14 May 2007 23:55, Rolf Brudeseth wrote: On Monday 14 May 2007 22:29, Rolf Brudeseth wrote: - Step 1: $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] == hvsi0 or hvc0 $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] == hvsi1 Do these pseudo files always exist, or just if a serial console is used? These three device files should always be present in /dev. It is just a matter of specifying the correct one in /etc/inittab, regardless of how the console is accessed. If they do always exist, what is their value if the other device is used, or if a regular console is used? I am not sure I understand the question so let me try to explain it as follows. IBM System p5 servers can be configured in two mutually exclusive ways as far as consoles are concerned. You misunderstand me. I'm not concerned about the device files in /dev, but about the files in /proc. We are going to be using the presence/content of the files /proc/device-tree/options/output-device/vdevice/[EMAIL PROTECTED], /proc/device-tree/options/output-device/vdevice/[EMAIL PROTECTED] and /proc/device-tree/vdevice/[EMAIL PROTECTED]/compatible to determine which type of console is being actually used, right? My question is: if hvsi1 is being used, what is the output of cat /proc/device-tree/options/output-device/vdevice/[EMAIL PROTECTED] or does that file just not exist in that case? My second question was: what is the output for the first two files if the console is on a regular keyboard/monitor directly connected to the box? From your description it looks like this question is basically just not relevant: a P5 server _always_ has a console connected by serial cable. So basically we should always have a co: line in /etc/inittab which points to either hvsi0, hvsi1 or hvc0 and this is basically completely separate from a regular serial console setup using a T0: line (which is only an _alternative_ to a directly connected keyboard/monitor). In that case, we don't need to touch the 90console script at all, but should rather add an additional script (91mgmt-console maybe) specific to PowerPC (and maybe also Sparc?) to set up the co: line. So, what I'm now beginning to understand is that I should forget about the T0 line (which we currently set in 90console for regular serial console setups), but have to use a co: line as you suggested in your initial post. Sorry if this seems obvious to you, but I'm not familiar with the hardware and want to be clear about how this works before implementing anything. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Tuesday 15 May 2007 08:03, Frans Pop wrote: My question is: if hvsi1 is being used, what is the output of cat /proc/device-tree/options/output-device/vdevice/[EMAIL PROTECTED] or does that file just not exist in that case? Sorry, forget about this one. I see I misread your mail. I thought some lines were wrapped, but that is not the case. I've got it now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Mon, May 14, 2007 at 09:38:25PM +0200, Frans Pop wrote: (No need to CC me. I see your replies on the debian-boot mailing list.) On Monday 14 May 2007 21:09, Rolf Brudeseth wrote: ~ # /usr/lib/finish-install.d/90console [...] + readlink /proc/1560/fd/0 + rawconsole=/dev/console Thanks. So the debian-installer process thinks a regular console is being used. That means that we do indeed need that redirection information you referred to. So, how do we determine which device is actually being used as console? The information of which console is used is available from the CHRP device tree. Probably something like : /proc/device-tree/chosen/stdout or /proc/device-tree/chosen/linux,stdout-path (This is from my Apple XServe G5, i don't have the p505 online right now, and cannot access it until next week), so Rolf, if you could share the content of your /proc/device-tree/chosen directory, and the content of those nodes actually of interest ? The stdout seems to be a pointer to a node of some kind, while the linux,stdout-path actually contains the path of the OF device used as stdout. This means that you would need something like ofpath or ofpathname to map it back to the actual /dev/hvc*|hvsi*. Notice also, that later linuces are able to auto-discover the actual output device used, and keep it as console, without the need of specifying console=/dev/*, altough i am not fully sure how this works. This is rather nice, especially as the actual name of the serial devices changes for the same hardware depending on how you use it, and the virtualized ones may even have a phantom /dev/ttyS or /dev/tty somewhere, since adding /dev/hvc0 in addition to both /dev/ttyS and /dev/tty on the kernel command line does desactivate the hvc output. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Tue, May 15, 2007 at 08:03:13AM +0200, Frans Pop wrote: On Monday 14 May 2007 23:55, Rolf Brudeseth wrote: On Monday 14 May 2007 22:29, Rolf Brudeseth wrote: - Step 1: $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] == hvsi0 or hvc0 $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] == hvsi1 Do these pseudo files always exist, or just if a serial console is used? These three device files should always be present in /dev. It is just a matter of specifying the correct one in /etc/inittab, regardless of how the console is accessed. If they do always exist, what is their value if the other device is used, or if a regular console is used? I am not sure I understand the question so let me try to explain it as follows. IBM System p5 servers can be configured in two mutually exclusive ways as far as consoles are concerned. You misunderstand me. I'm not concerned about the device files in /dev, but about the files in /proc. We are going to be using the presence/content of the files /proc/device-tree/options/output-device/vdevice/[EMAIL PROTECTED], /proc/device-tree/options/output-device/vdevice/[EMAIL PROTECTED] and /proc/device-tree/vdevice/[EMAIL PROTECTED]/compatible to determine which type of console is being actually used, right? My question is: if hvsi1 is being used, what is the output of cat /proc/device-tree/options/output-device/vdevice/[EMAIL PROTECTED] or does that file just not exist in that case? Frans, forget about those existential questions. /proc/device-tree/chosen is what you want. It will contain a copy of all the relevant information used during booting, provided to you by the underlying firmware. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Monday 14 May 2007 22:58, Frans Pop wrote: All in all, this looks easy enough to implement. I'll give it a shot over the next few days and send you something to test. Please try the attached script. It is a drop-in replacement for /usr/lib/finish-install.d/90console. Just copy it over the existing script after the load additional installer components stage has run. You may have to 'chmod a+x' the script. The script will disable all the gettys on VT1 to VT6. I hope that is correct. The co: line will be added before those lines (or replaced if it already exists). As I cannot test really the script myself, there may be minor syntax errors in it. You can run the script manually from shell any time after the base installation stage has completed and again use 'set -x' to get debugging output. If there are any problems, please provide the debug output. If you think there are alternative (simpler) solutions possible based on the information provided by Sven Luther, please let me know. Cheers, FJP 90console Description: application/shellscript
Bug#420820: no console set IBM p5 server
As long as Linux kernel creates the Linux,stdout-package property in the /chosen that indicates the console-path, then this script doesn't need to look at the output-device property in the /options node (the /options node represents the various NVRAM varaibles, which is how Open Firmware remembers it's console-path). Two important testcases to worry about are: 1) If the linux,stdout-package property doesn't point to a vty device but something else like PCI graphics or PCI serial port (ATX platform has those). For a graphics card, the device tree node pointed by the stdout-package will have a device-type property of display. I'm not sure what the compatible property will look like for PCI serial ports (as they'll be underneath the pci-function layer if there are multiple ports per PCI-function) but they'd map to ttyS# entries, not hv*# entries. Either way, it's safe to assume that if the compatible starts with hvterm, then it's either the hvterm, hvterm1, or hvterm-protocol (and maps to a hv*# entry). 2) If there are multiple USB keyboards (with graphics adapter), are both supported for login or just one? Hopefully both, but I guess this is a rare scenario. Note we've only been paying attention to stdout and not stdin to specify an exact keyboard. Then again, I'd advise staying away from specifying a specific keyboard because recent IBM firmware has a /vdevice/vkbd node (a virtual keyboard driver that handles USB hotplug gracefully), which doesn't map to a single USB keyboard. That function was added in Power5 GA7 firmware JS21-GA3 blade firmware. - Jim Lindeman Software Engineer System p Firmware [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Monday 14 May 2007 17:33, Rolf Brudeseth wrote: I got the login prompt after I modified /etc/inittab (via a linux install I had on another disk). OK, your report did not really make that clear. It was probably not really necessary to include the login prompt then. I understood that that is what you saw when it appeared to be hanging. How exactly did you boot the installer (with what parameters)? I tried both 'install64' and 'expert64'. So you did not add any 'console=...' parameter? Did the installer itself correctly use the serial console despite that? Nothing else was echo'ed to the screen. At the time, I did not realize that with Etch the sshd server is not enabled by default. Correct, it is not. Unless you use the network-console component of the installer which enables you to do the main part of the installation over ssh. In that case sshd is installed. I later understood that the system was up an running just fine, except for this serial port console issue. OK. Yes there was and it was commented out. Right. All this means that the installer, even though it may have been using serial console (I'd still like that confirmed), did not recognize that fact and thus did not set up the installed system for it, which explains the problems on the reboot. By other systems you mean Apple computers or prior generation IBM workstations? What has changed on IBM System p5 servers is that the serial ports or console on the HMC is virtualized via the onboard service processor. No, I mean HPPA and SPARC systems mostly as that is what I have experience with for serial console installs. So, the next step is to find out why the installer does not recognize that you are on serial console. Can you please boot the installer again and activate a debug shell (there is an option in the installer's main menu, or alternatively you can use that network-console component). Please provide the output of 'cat /proc/cmdline'. Next, run 'nano /usr/lib/finish-install.d/90console'; this will start an editor for that file: - add a line 'set -x' below 'set -e' - delete all lines between (not including) 'ttyterm=$TERM' and ';;' - save and exit And then run the script and provide the full output. If you load the optional openssh-client-udeb, you can scp a file to another system. TIA, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
I got the login prompt after I modified /etc/inittab (via a linux install I had on another disk). OK, your report did not really make that clear. It was probably not really necessary to include the login prompt then. I understood that that is what you saw when it appeared to be hanging. Sorry, yes I was a little terse. Just wanted to indicate that I finally was able to get the login prompt. How exactly did you boot the installer (with what parameters)? I tried both 'install64' and 'expert64'. So you did not add any 'console=...' parameter? No, I added no kernel parameters. Did the installer itself correctly use the serial console despite that? Yes, the installer used the serial port correctly. Nothing else was echo'ed to the screen. At the time, I did not realize that with Etch the sshd server is not enabled by default. Correct, it is not. Unless you use the network-console component of the installer which enables you to do the main part of the installation over ssh. In that case sshd is installed. I later understood that the system was up an running just fine, except for this serial port console issue. OK. Yes there was and it was commented out. Right. All this means that the installer, even though it may have been using serial console (I'd still like that confirmed), did not recognize that fact and thus did not set up the installed system for it, which explains the problems on the reboot. Yes, the install went just fine via the serial port. It was not until the subsequent reboot from disk when I could not interact with the serial console. By other systems you mean Apple computers or prior generation IBM workstations? What has changed on IBM System p5 servers is that the serial ports or console on the HMC is virtualized via the onboard service processor. No, I mean HPPA and SPARC systems mostly as that is what I have experience with for serial console installs. So, the next step is to find out why the installer does not recognize that you are on serial console. Can you please boot the installer again and activate a debug shell (there is an option in the installer's main menu, or alternatively you can use that network-console component). Yes, I will give that a shot. Please provide the output of 'cat /proc/cmdline'. Next, run 'nano /usr/lib/finish-install.d/90console'; this will start an editor for that file: - add a line 'set -x' below 'set -e' - delete all lines between (not including) 'ttyterm=$TERM' and ';;' - save and exit And then run the script and provide the full output. If you load the optional openssh-client-udeb, you can scp a file to another system. TIA, FJP
Bug#420820: no console set IBM p5 server
So, the next step is to find out why the installer does not recognize that you are on serial console. Can you please boot the installer again and activate a debug shell (there is an option in the installer's main menu, or alternatively you can use that network-console component). Please provide the output of 'cat /proc/cmdline'. ~ # cat /proc/cmdline ro ramdisk_size=10240 -- Next, run 'nano /usr/lib/finish-install.d/90console'; this will start an editor for that file: - add a line 'set -x' below 'set -e' - delete all lines between (not including) 'ttyterm=$TERM' and ';;' - save and exit And then run the script and provide the full output. If you load the optional openssh-client-udeb, you can scp a file to another system. ~ # ls -l /usr/lib/finish-install.d/90console ls: /usr/lib/finish-install.d/90console: No such file or directory ~ # ls -l /usr/lib/finish-install.d/ -rwxr-xr-x1 root root 2111 May 14 18:14 05brltty -rwxr-xr-x1 root root 2441 May 14 18:14 05localechooser -rwxr-xr-x1 root root 50 May 14 18:14 07preseed -rwxr-xr-x1 root root 645 May 14 18:14 15cdrom-detect -rwxr-xr-x1 root root 18 May 14 18:14 30hw-detect -rwxr-xr-x1 root root 542 May 14 18:14 94save-logs ~ # TIA, FJP Rolf
Bug#420820: no console set IBM p5 server
On Monday 14 May 2007 20:23, Rolf Brudeseth wrote: ~ # ls -l /usr/lib/finish-install.d/90console ls: /usr/lib/finish-install.d/90console: No such file or directory Sorry, the file only appears after you have passed the step load additional installer components, so you will have to walk through the installation to just past that point. It's probably best to proceed to the first screen of the partitioner and then exit to the menu. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
~ # cat /usr/lib/finish-install.d/90console
#!/bin/sh
set -e
set -x
log() {
logger -t finish-install $@
}
# Since this script is running with debconf, 'tty' does
# not give reliable answers about what sort of terminal
# we have. The stdin of /sbin/debian-installer seems
# to tell the truth.
inst_pid=$(pidof debian-installer | sed s/ /\n/g | sort -n | head -n 1)
rawconsole=$(readlink /proc/${inst_pid}/fd/0)
console=$(mapdevfs $rawconsole)
rawconsole=${rawconsole#/dev/}
console=${console#/dev/}
case $console in
tty[A-Z]*|hvc*|hvsi*)
log Configuring /etc/inittab for serial console
consoletype=${console%%[0-9]*}
ttyline=${console#$consoletype}
ttyspeed=$(chroot /target stty --file /dev/$console speed)
ttyterm=$TERM
;;
esac
~ #
~ # /usr/lib/finish-install.d/90console
+ pidof debian-installer
+ sed s/ /\n/g
+ sort -n
+ head -n 1
+ inst_pid=1560
+ readlink /proc/1560/fd/0
+ rawconsole=/dev/console
+ mapdevfs /dev/console
+ console=/dev/console
+ rawconsole=console
+ console=console
~ #
Bug#420820: no console set IBM p5 server
(No need to CC me. I see your replies on the debian-boot mailing list.) On Monday 14 May 2007 21:09, Rolf Brudeseth wrote: ~ # /usr/lib/finish-install.d/90console [...] + readlink /proc/1560/fd/0 + rawconsole=/dev/console Thanks. So the debian-installer process thinks a regular console is being used. That means that we do indeed need that redirection information you referred to. So, how do we determine which device is actually being used as console? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Monday 14 May 2007 21:09, Rolf Brudeseth wrote: ~ # /usr/lib/finish-install.d/90console [...] + readlink /proc/1560/fd/0 + rawconsole=/dev/console Thanks. So the debian-installer process thinks a regular console is being used. That means that we do indeed need that redirection information you referred to. So, how do we determine which device is actually being used as console? I see that this is all publicly available, so no problem sharing: - IEEE 1275, IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices - Power Architecture Platform Requirements (PAPR) at power.org - Step 1: $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] == hvsi0 or hvc0 $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] == hvsi1 - Step 2 (if hvsi0 or hvc0): $ cat /proc/device-tree/vdevice/[EMAIL PROTECTED]/compatible hvterm-protocol == hvsi0 $ cat /proc/device-tree/vdevice/[EMAIL PROTECTED]/compatible hvterm -- or -- hvterm1 == hvc0 In other words: hvterm-protocol == Serial port attached console at port 1 or 2 (non-HMC managed) hvterm or hvterm1 == HMC managed console Rolf
Bug#420820: no console set IBM p5 server
On Monday 14 May 2007 22:29, Rolf Brudeseth wrote: - Step 1: $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] == hvsi0 or hvc0 $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] == hvsi1 Do these pseudo files always exist, or just if a serial console is used? If they do always exist, what is their value if the other device is used, or if a regular console is used? All in all, this looks easy enough to implement. I'll give it a shot over the next few days and send you something to test. Thanks again. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Monday 14 May 2007 22:29, Rolf Brudeseth wrote: - Step 1: $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] == hvsi0 or hvc0 $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] == hvsi1 Do these pseudo files always exist, or just if a serial console is used? These three device files should always be present in /dev. It is just a matter of specifying the correct one in /etc/inittab, regardless of how the console is accessed. If they do always exist, what is their value if the other device is used, or if a regular console is used? I am not sure I understand the question so let me try to explain it as follows. IBM System p5 servers can be configured in two mutually exclusive ways as far as consoles are concerned. If the system is set up where all the hardware resources are associated with a single OS partition and an HMC is not used, then the console is available either through serial port 1 or 2. A physical serial cable can be attached to a traditional terminal, a laptop running minicom, etc. The system senses which serial port is in use and the appropriate value will be set in Open Firmware. On the other hand, if the system is split up into multiple OS partitions, then a Hardware Management Console (HMC) is required and the serial ports can not be used for console access. The HMC is essentially another PC type computer, running IBM software, which is used to manage the hardware resources made available to the various OS partitions on the server. The HCM will offer as many consoles as there are partitions on the system. It is possible to have an HMC managed system with all the hardware resources associated with a single OS partition. However, the serial ports still can not be used for console access. It is also possible to add extra hardware (PCI adapters, Serial over LAN, etc) that will allow for ttySx type hardware serial ports to be used. These are not present with the default configuration and will not allow the user to interact with the ASM and SMS menues that I have described in an earlier entry in this bug. Thus, they will behave like a traditional terminal configuration, where the first thing a user will see is the login prompt. They can not be used for power-up, install, etc. All in all, this looks easy enough to implement. I'll give it a shot over the next few days and send you something to test. Just let me know when it is ready. Thanks again. Cheers, FJP Happy to help. Rolf
Bug#420820: no console set IBM p5 server
retitle 420820 no console set IBM p5 server reassign 420820 finish-install thanks Op 11-05-2007 om 14:26 schreef Rolf Brudeseth: Here is the fix I implemented, since the system is non-HMC managed and the serial cable is attached to port1: [EMAIL PROTECTED]:~$ diff /etc/inittab /etc/inittab.orig 63d62 co:2345:respawn:/sbin/getty hvsi0 9600 vt100 Because you had to add that line, was it not added by d-i IIRC adds d-i a serial line getty, when the installer is booted with 'console=ttyS0' (where ttyS0 is an example of a valid serial port ) I also remember bugreports about that behaviour, but I don't remember their status. Note that there are three possible consoles on an IBM p5 Server: co:2345:respawn:/sbin/getty hvsi0 9600 vt100 == Console via serial port 1 (Non-HMC managed) co:2345:respawn:/sbin/getty hvsi1 9600 vt100 == Console via serial port 2 (Non-HMC managed) co:2345:respawn:/sbin/getty hvc0 9600 vt100== Console via HMC Would it OK to activate all three? Assuming that detecting a p5 server can be done. The baud rate is ignored. The serial port baud rates are managed through the Service Processor ASM menues. No worries Mate! This is in the /etc/inittab on my iBook 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3 where tty2 and tty3 are virtual consoles, where baudrate neither matters. Cheers Geert Stappers P.S. preferred diff syntax is diff -u oldfile newfile e.g.: diff -u /etc/inittab.orig /etc/inittab -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
Op 11-05-2007 om 22:25 schreef Geert Stappers: Op 11-05-2007 om 14:26 schreef Rolf Brudeseth: Note that there are three possible consoles on an IBM p5 Server: co:2345:respawn:/sbin/getty hvsi0 9600 vt100 == Console via serial port 1 (Non-HMC managed) co:2345:respawn:/sbin/getty hvsi1 9600 vt100 == Console via serial port 2 (Non-HMC managed) co:2345:respawn:/sbin/getty hvc0 9600 vt100== Console via HMC Would it OK to activate all three? Assuming that detecting a p5 server can be done. Bugreport #394970 is/was about serial ports on a p5 server. In that report is not yet a succesfull test confirmed. HtH GSt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
