On latest Fedora 17 (systemd-44-17.fc17.x86_64) enabling serial console for login is quite a pain: if the kernel console's speed is set to 115200 baud then: systemctl start getty will run agetty - but with 38400 baud speed. Editing the service files in /usr/lib/systemd helps but obviously systemd should behave better here: it should pick up the current baud setting of the console via stty and should use that for agetty. at minimum, if it wants to use hardfixed baud rate, it should use a modern 'high speed' setting like 115200. Another bug is that enabling the serial console does not work: [root@aldebaran ~]# systemctl enable getty Failed to issue method call: No such file or directory While researching this problem I saw that this bug has been present in systemd for years, I've seen it reported in bugzillas and elsewhere. also a usability bug report: plus doing 'systemctl start getty' does not display any information about whether the service got started or not, whether it was already started, etc - it just returns silently, passive-aggressively leaving the user wondering whether everything went as expected and what state systemd is in now.
Doing this: ln -s /usr/lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty resolves the enabling problem listed above, the serial console starts up automatically on ttyS0 and I can log in without having to ssh to the system first.
To duplicate this bug just add the relevant kernel console parameters at boot up ( which I guess the getty service should be picking up ) and or add to /etc/default/grub GRUB_CMDLINE_LINUX='console=tty0 console=ttyS0,115200n8' GRUB_TERMINAL=serial GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1" ( or something similar ) and regenerate grub config (In reply to comment #0) > On latest Fedora 17 (systemd-44-17.fc17.x86_64) enabling serial console for > login is quite a pain: if the kernel console's speed is set to 115200 baud > then: > > systemctl start getty > > will run agetty - but with 38400 baud speed. Editing the service files in > /usr/lib/systemd helps but obviously systemd should behave better here: > it should pick up the current baud setting of the console via stty and > should use that for agetty. Note that you should copy unit files in /usr/lib/systemd/system directory to /etc/systemd/system directory and edit that there or create a new one that bears the same name with .include reference + your changes otherwise your changes would be lost at next package update. See http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F > at minimum, if it wants to use hardfixed baud rate, it should use a modern > 'high speed' setting like 115200. Agreed > Another bug is that enabling the serial console does not work: > > [root@aldebaran ~]# systemctl enable getty > Failed to issue method call: No such file or directory Template units dont have [Install] and thus this less then useful error message is displayed and is being worked on in bug 752774 > While researching this problem I saw that this bug has been present in > systemd for years, I've seen it reported in bugzillas and elsewhere. > > also a usability bug report: > > plus doing 'systemctl start getty' does not display any > information about whether the service got started or not, whether it > was already started, etc - it just returns silently, passive-aggressively > leaving the user wondering whether everything went as expected and what > state systemd is in now. This is being tracked here 846306, I guess the main problem is how differentiate between services started a bootup ( where you dont want this behavior ) vs service manually started from cli )( where you want this behavior )
Use "serial-getty@.service" instead of "getty@.service". It will reuse the kernel configured baud rate then (we actually fixed agetty for that, so that this works fully automatically without user interference.) Also note that manually linking the getty template service is seldom necessary, as systemd-getty-generator will actually instantiate serial-getty@.service for a serial port if a serial port is used as kernel console. We really tried hard to make it entirely unnecessary to ever configure serial gettys manually. Just specifying console= on the kernel cmdline should be entirely sufficient. (More specfically, we read /sys/class/tty/console/active and spawn exectly one serial getty on the first tty that is listed in that file, iff it is a serial device).
I have another systemd problem with recent kernels - not necessarily related to the serial console. systemd, instead of booting up, just spuriously drops into rescue mode: [ OK ] Reached target Sockets. [ OK ] Reached target Basic System. Starting Rescue Shell... [ OK ] Started Rescue Shell. [ OK ] Reached target Rescue Mode. Welcome to rescue mode! Type "systemctl default" or ^D to enter default mode. Type "journalctl" to view system logs. Type "systemctl reboot" to reboot. this too is passive-aggressive failure behavior from systemd - it does not tell *WHY* rescue mode was entered (I certainly did not request it), nor does any of the suggested solutions printed above give any clue why it did that. journalctl does not give clues (to me) - here's all the entries that failed or triggered some sort of error: [root@lyra ~]# journalctl | grep -iE 'fail|err' Oct 02 07:47:02 lyra udev-configure-printer[637]: Failed to get parent Oct 02 07:47:18 lyra [716]: TCSD TDDL[716]: TrouSerS ERROR: Could not find ...en! Oct 02 07:47:18 lyra tcsd[709]: Starting tcsd: [FAILED] Oct 02 07:47:18 lyra systemd[1]: Unit tcsd.service entered failed state. Oct 02 07:47:22 lyra dbus[764]: [system] Activation via systemd failed for ...s. Oct 02 07:47:22 lyra NetworkManager[731]: <warn> failed to allocate link cac...d Oct 02 07:47:22 lyra NetworkManager[731]: <warn> failed to allocate link cac...d Oct 02 07:47:22 lyra modem-manager[779]: <info> Loaded plugin 'Sierra' Oct 02 07:47:22 lyra NetworkManager[731]: <warn> bluez error getting default.... Oct 02 07:47:25 lyra systemd[1]: Unit rc-local.service entered failed state. Oct 02 07:47:25 lyra systemd[1]: Unit prefdm.service entered failed state. Oct 02 07:47:25 lyra systemd[1]: Unit prefdm.service entered failed state. Oct 02 07:47:25 lyra systemd[1]: Unit prefdm.service entered failed state. Oct 02 07:47:25 lyra systemd[1]: Unit prefdm.service entered failed state. Oct 02 07:47:25 lyra systemd[1]: Unit prefdm.service entered failed state. Oct 02 07:47:25 lyra systemd[1]: Unit prefdm.service entered failed state. Oct 02 07:58:59 lyra login[948]: pam_unix(login:auth): authentication failu...t= Oct 02 07:59:02 lyra login[948]: FAILED LOGIN 1 FROM ttyS0 FOR (unknown), U...le Oct 02 07:59:03 lyra login[948]: pam_unix(login:auth): authentication failu...t= Oct 02 07:59:05 lyra login[948]: FAILED LOGIN 2 FROM ttyS0 FOR (unknown), U...le But AFAICS it's all after rescue mode was entered (and manually exited via the keyboard). /var/log/messages shows nothing beyond the 'bluez' failure: Oct 2 07:47:22 lyra dbus-daemon[764]: dbus[764]: [system] Activation via systemd failed for unit 'dbus-org.bluez.service': Unit dbus-org.bluez.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.bluez.service' for details. Oct 2 07:47:22 lyra dbus[764]: [system] Activation via systemd failed for unit 'dbus-org.bluez.service': Unit dbus-org.bluez.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.bluez.service' for details. The suggested 'detail' is: [root@lyra ~]# systemctl status dbus-org.bluez.service dbus-org.bluez.service Loaded: error (Reason: No such file or directory) Active: inactive (dead) Which gives very little idea as to what happened. How do you guys debug systemd?
I removed the 'CLOSED/NOTABUG' and moved it back to 'ASSIGNED' because the bug is not resolved yet. If it takes a kernel developer hours to figure out how to configure the serial line with systemd on a freshly installed Fedora 17 box, and if with the #1 google suggestion for the problem systemd executes the command: systemctl start getty but spuriously mismatches line speeds then it's certainly a bug in one way or another. So if what I did is buggy then either fix it, alias it to serial-getty@.service or print out the recommended method: systemctl start serial-getty@.service to keep people wasting hours on already solved problems... Thanks!
So I tried the suggested solution on a fully uptodate Fredora 17 box and it failed with: [root@lyra ~]# systemctl start serial-getty@.service Failed to issue method call: Unit name serial-getty@.service is not valid. Btw., do you find such error messages acceptable? I certainly don't: it does not tell us *WHY* the unit name is 'not valid'. We created computers to help humans, not to stand in the way :-)
So I guess you meant serial-getty? If a user is so lucky to guess that pattern then that can indeed be started - but not enabled: [root@lyra ~]# systemctl enable serial-getty Failed to issue method call: No such file or directory so my original problem was that the serial console did not start automatically if kernel serial console is enabled, on my configuration. [ Side note: the above error message is passive-aggressive as well, please improve it. ] Or did you mean that it is it enough to do: systemctl start serial-getty and the serial console getty will be automatically started in future bootups as well? Let me know if you need any other info to resolve these problems. Alternatively, could you point me to (or describe here) the suggested method of enabling the serial console on a freshly installed Fedora 17 box? I found no such information, only various guesses in bugzillas and on user websites. Doing a Google search for it gives: http://bit.ly/UDcNmv the first link: http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/sect-Virtualization-Troubleshooting_-Troubleshooting_with_serial_consoles.html is outdated, does not cover systemd nor the grub2 complications introduced in F17 (but that's outside this bugzilla). Adding 'systemd' to the search: http://bit.ly/UDcQPc Goes to an external site (which, as per your comment here, is wrong) and to bugzillas. The first Fedora link: http://fedoraproject.org/wiki/How_to_debug_Systemd_problems does not actually talk about serial consoles (anymore?). Note, you might not see such bugreports often, possibly because I'm one of the last kernel maintainers still left using Fedora & the latest version of systemd. I'm stubborn about this eating our own dogfood concept ;-)
I suggest you actually read bug 752774 and go through all the bugs on the fit and finish bug 784611 and make your comments on the relevant bugs or create a new bug and if the usability issue you describe there have not already been reported since you are not the first and certainly not the last that is experiencing these usability issues. Since you apparently missed the big blue banner with the bold letters word "Follow the upstream wiki guide" on our own wiki page that points to http://freedesktop.org/wiki/Software/systemd/Debugging I will probably update our own to match that one later today and remove that banner since I did not initiate the how to debug pages nor create that wiki page first place to later have it redirect people upstream or having them running around the whole internet trying to use google personalized searches on top of getting only results of who pays google the most. I have added the missing grub serial console setup directions to https://fedoraproject.org/wiki/GRUB_2#Enable_Serial_Console_in_Grub Lennart is it not possible to add ConditionKernelCommandLine=console and simply have a standalone unit that greps the console parameters provided and starts the unit automatically with those parameters instead of using an template unit to do this? For using a template to do this to properly work the only thing an user needs to do is to add the console parameters to the kernel command line. no more no less... If we cant do that we need a standalone unit that users will need to enable and or copy to /etc/systemd/system directory and tweak to their environment to suit their needs
Ok, lets ignore the usability issues if you are not interested in fixing them - I really have three (still unresolved) questions/problems that are on topic for this new bugzilla. #1 if I pass in console=ttyS0,115200 on Fedora 17 today then the serial line it produces either a hung/silent console or random garbage, because the speeds are mismatched by systemd. It is not clear to me what the action plan in this bug is: is it already fixed upstream (i.e. it will all work as expected), will it be fixed in Fedora 18, etc? #2 even if I find out about the only working serial speed (console=ttyS0,38400) and have a working serial console, how do I permanently enable the serial console, so that it comes up after a reboot as well? The two commands I tried did not work: [root@lyra ~]# systemctl enable serial-getty Failed to issue method call: No such file or directory [root@aldebaran ~]# systemctl enable getty Failed to issue method call: No such file or directory None of the documentation you linked to seemed to address this question. #3 the top two hits for the Google search for 'fedora serial console' comes up with two official looking Fedora pages: http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/sect-Virtualization-Troubleshooting_-Troubleshooting_with_serial_consoles.html https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_serial_console The first one is actively misleading in a current Fedora context as it talks about Grub 1 not Grub 2, the second one leads to a journey with mismatched line speeds. Even the systemd section on FreeDesktop.org, in particular FreeDesktop.org's FAQ on systemd serial console: http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions talks about using ln -s: # ln -sf /usr/lib/systemd/system/serial-getty@.service /etc/systemd/system/getty.target.wants/serial-getty # systemctl daemon-reload # systemctl start getty So I don't know how to interpret your observation in comment #8 about me supposedly missing very clear documentation hints: I have seen all the relevant documentation and yet spent hours on this problem. I'm trying to help and I'm outlining the thought process that led to these problems - there's nothing particularly unusual about any of what I did.
(In reply to comment #9) > Ok, lets ignore the usability issues if you are not interested in fixing > them - I really have three (still unresolved) questions/problems that are on > topic for this new bugzilla. The tracker bug would not exist and the subsequent the bugs on them if the intent was not to fix those usability issue. Both Lukas and Václav have been going through these bugs and fixing things > #1 if I pass in console=ttyS0,115200 on Fedora 17 today then the serial line > it produces either a hung/silent console or random garbage, because the > speeds are mismatched by systemd. It is not clear to me what the action plan > in this bug is: is it already fixed upstream (i.e. it will all work as > expected), will it be fixed in Fedora 18, etc? The intended behavior for serial console to work is that you only add the relevant console entries to the kernel command line either manual for onetime or permanently by adding it the /etc/default/grub configuration file. That's it and everything else should happen automatically. Things will get more trickier when you want to specify more then one console on the kernel command line since systemd spawn the getty automatically only on the primary console which means you have to get the order right if you specify more then one console if you want a getty. > #2 even if I find out about the only working serial speed > (console=ttyS0,38400) and have a working serial console, how do I > permanently enable the serial console, so that it comes up after a reboot as > well? You dont and are not supposed to do that but if you want to enable template units in general you have to do so manually by creating symbolic links to that unit in the relevant target wants directory you want that template unit be started from. > The two commands I tried did not work: > > [root@lyra ~]# systemctl enable serial-getty > Failed to issue method call: No such file or directory > > [root@aldebaran ~]# systemctl enable getty > Failed to issue method call: No such file or directory > > None of the documentation you linked to seemed to address this question. "Template units dont have [Install] and thus this less then useful error message is displayed and is being worked on in bug 752774" > #3 > > the top two hits for the Google search for 'fedora serial console' comes up > with two official looking Fedora pages: We have absolutely no control which results online searches yields What does duck duck go give, alta vista, web crawler, yahoo bing etc? Do they point to more current,accurate documentation or directions? > http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/sect- > Virtualization-Troubleshooting_-Troubleshooting_with_serial_consoles.html > > https://fedoraproject.org/wiki/QA: > Testcase_Anaconda_User_Interface_serial_console > > The first one is actively misleading in a current Fedora context as it talks > about Grub 1 not Grub 2, the second one leads to a journey with mismatched > line speeds. > > Even the systemd section on FreeDesktop.org, in particular FreeDesktop.org's > FAQ on systemd serial console: > > http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions > > talks about using ln -s: > > # ln -sf /usr/lib/systemd/system/serial-getty@.service > /etc/systemd/system/getty.target.wants/serial-getty > # systemctl daemon-reload > # systemctl start getty That probably is supposed to be "systemctl start serial-getty" then again I dont maintain the upstream wiki page so... > So I don't know how to interpret your observation in comment #8 about me > supposedly missing very clear documentation hints: I have seen all the > relevant documentation and yet spent hours on this problem. I'm trying to > help and I'm outlining the thought process that led to these problems - > there's nothing particularly unusual about any of what I did. I was referring to " Adding 'systemd' to the search: http://bit.ly/UDcQPc Goes to an external site (which, as per your comment here, is wrong) and to bugzillas. The first Fedora link: http://fedoraproject.org/wiki/How_to_debug_Systemd_problems does not actually talk about serial consoles (anymore?). " Michal chose to send reporters and others to the upstream wiki which is why I'm reconsidering why I am bothering with the how to debug page initiative since the intent seem to be to forward everybody upstream which also begs the question if we should not then just forward everyone to the relevant upstream bug tracker as well and stop reporting here in Red Hat's bugzilla et all and just leave the automatic bug reports and Red Hatters to it after all it's Red Hat's bugzilla instance. We have been discussing this a bit in the QA community.
(In reply to comment #9) > Ok, lets ignore the usability issues if you are not interested in fixing > them - I really have three (still unresolved) questions/problems that are on > topic for this new bugzilla. > > #1 if I pass in console=ttyS0,115200 on Fedora 17 today then the serial line > it produces either a hung/silent console or random garbage, because the > speeds are mismatched by systemd. It is not clear to me what the action plan > in this bug is: is it already fixed upstream (i.e. it will all work as > expected), will it be fixed in Fedora 18, etc? systemd doesn't ever touch the console baud rate at all. We just invoke "agetty -s" on it, which should have the effect that the kernel set baudrate is kept. If this doesn't work, please file a bug against util-linux, as systemd is not involved at that point in time. > #2 even if I find out about the only working serial speed > (console=ttyS0,38400) and have a working serial console, how do I > permanently enable the serial console, so that it comes up after a reboot as > well? > > The two commands I tried did not work: > > [root@lyra ~]# systemctl enable serial-getty > Failed to issue method call: No such file or directory One way is to permanently add console=ttyS0 to your kernel cmdline. systemd should then figure out the rest. If you only want a serial getty but no kernel console on it, please see the FAQ: http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions Note that starting with F18 what you attempted will also work. > # ln -sf /usr/lib/systemd/system/serial-getty@.service > /etc/systemd/system/getty.target.wants/serial-getty > # systemctl daemon-reload > # systemctl start getty Sorry, the first line is correct, but the second line is incorrect. I have fixed this now. > So I don't know how to interpret your observation in comment #8 about me > supposedly missing very clear documentation hints: I have seen all the > relevant documentation and yet spent hours on this problem. I'm trying to > help and I'm outlining the thought process that led to these problems - > there's nothing particularly unusual about any of what I did. Sorry for the misleading FAQ. I'll prep a blog story about how to use serial consoles. This should hopefully end up a the top of the google list after a short while, so that this is more easily found.
Anyway, the big remaining issue the bug is primarily about seems to be that "agetty -s" doesn't work correctly. Reassigning to util-linux. Karel, can you help Ingo?
(In reply to comment #11) > I'll prep a blog story about how to use serial consoles. This should > hopefully end up a the top of the google list after a short while, so that > this is more easily found. Done: http://0pointer.de/blog/projects/serial-console.html I hope this settles this issue.
(In reply to comment #11) > (In reply to comment #9) > > [root@lyra ~]# systemctl enable serial-getty > > Note that starting with F18 what you attempted will also work. In F17 it should now work too (since systemd-44-20.fc17, now in updates-testing).
Does any of this apply to /dev/ttyUSB[0-9][0-9]*? I mean the automatic kernel commandline->automated getty running on the port.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
So given that my question in comment 15 is regarding Fedora 18 and how none of this seems to work on ttyUSB* could somebody please bump the version of this bug to Fedora 18?
Bumped to 18...
(In reply to Brian J. Murrell from comment #15) > Does any of this apply to /dev/ttyUSB[0-9][0-9]*? I mean the automatic > kernel commandline->automated getty running on the port. I don't see why it wouldn't work. What does /sys/class/tty/console/active contain when you try it?
(In reply to Michal Schmidt from comment #19) > > I don't see why it wouldn't work. What does /sys/class/tty/console/active > contain when you try it? Unfortunately the only Fedora machine (this one I'm typing on) I have up wasn't booted with console=ttyUSB0,11500 but having investigated that file in the past I would entirely expect it to contain ttyUSB0. I guess my concern was more around whether any matching of console= on the kernel command line was specifically looking for ttyS* as it's pattern for determining if a serial console is present or not. But looking at the code I see this is used to determine whether the "active" console is serial or not, or rather is not a VC tty: if (isempty(tty) || tty_is_vc(tty)) free(active); else { int k; ... k = add_serial_getty(tty); free(active); ... } So I guess the remaining question is is ttyUSB* active by the time systemd does this? I would think it is since it gets activated during kernel boot, albeit later than native serial ports. I will have to try this all again next time I have an opportunity to reboot this fedora machine, but I'm pretty sure my ttyUSB0 serial console didn't get a getty on it the last time I tried all of this.
OK. So re: comment #20, this worked, for ttyUSB0 on F18 but is not working on F19 if I'm understanding that nothing needs to be done beyond listing "console=ttyUSB0,115200" on the kernel command line as the last "console=" option.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Per comment #21, can we have the Version: of this bug updated to F19 please?
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.