Bug 739218 - Lost ability to use bash on hvc0
Summary: Lost ability to use bash on hvc0
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: 16
Hardware: ppc64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Roman Rakus
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-16 20:44 UTC by Mark Hamzy
Modified: 2014-01-13 00:13 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-05 21:21:51 UTC


Attachments (Terms of Use)

Description Mark Hamzy 2011-09-16 20:44:19 UTC
Description of problem:
Booting Fedora-20110916-ppc64-DVD.iso, with the following parameters:
   linux serial vnc=1 selinux=0 systemd.log_target=kmsg systemd.log_level=debug rd.break

This gets me into a shell before the system is booted up.  I then disable the anaconda installer, and substitute a bash prompt.

cp /sysroot/lib/systemd/system/loader.service /sysroot/lib/systemd/system/loader2.service
sed -i -e 's,Description=.*$,Description=Yet Another Bash Shell,' /sysroot/lib/systemd/system/loader.service
sed -i -e 's,/sbin/loader,/bin/bash,' /sysroot/lib/systemd/system/loader.service
cat << __EOF__ > /sysroot/lib/systemd/system/anaconda-shell.service
[Unit]
Description=Shell on hvc0
BindTo=dev-hvc0.device
After=dev-hvc0.device

[Service]
Environment=TERM=linux
WorkingDirectory=/
ExecStart=-/sbin/agetty -n hvc0 38400
Restart=always
RestartSec=0
TimeoutSec=0
TTYPath=/dev/hvc0
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
KillSignal=SIGHUP
__EOF__
exit

Unfortunately, bash no longer accepts input.

Comment 1 Roman Rakus 2011-09-19 11:25:03 UTC
(In reply to comment #0)
> Description of problem:
> Booting Fedora-20110916-ppc64-DVD.iso, with the following parameters:
>    linux serial vnc=1 selinux=0 systemd.log_target=kmsg systemd.log_level=debug
> rd.break
> 
> This gets me into a shell before the system is booted up.  I then disable the
> anaconda installer, and substitute a bash prompt.
> 
> cp /sysroot/lib/systemd/system/loader.service
> /sysroot/lib/systemd/system/loader2.service
> sed -i -e 's,Description=.*$,Description=Yet Another Bash Shell,'
> /sysroot/lib/systemd/system/loader.service
> sed -i -e 's,/sbin/loader,/bin/bash,'
> /sysroot/lib/systemd/system/loader.service

> cat << __EOF__ > /sysroot/lib/systemd/system/anaconda-shell.service
> [Unit]
> Description=Shell on hvc0
> BindTo=dev-hvc0.device
> After=dev-hvc0.device
> 
> [Service]
> Environment=TERM=linux
> WorkingDirectory=/
> ExecStart=-/sbin/agetty -n hvc0 38400
> Restart=always
> RestartSec=0
> TimeoutSec=0
> TTYPath=/dev/hvc0
> TTYReset=yes
> TTYVHangup=yes
> TTYVTDisallocate=yes
> KillSignal=SIGHUP
> __EOF__
I'm not familiar with systemd, what is this supposed to do?
> exit
Do you exit from bash?
> 
> Unfortunately, bash no longer accepts input.
Are you in bash? Didn't previous exit exited you from most parent bash?

I haven't ppc machine on touch right now, so I can't take a look what's going on. But from my first look, it seems you exited from bash.

Comment 2 Mark Hamzy 2011-09-19 14:57:04 UTC
The rd.break boot parameter starts up a shell before the root is switched and the system boots up.  This allows you to change files before they get executed.  I am exiting from that shell and not the shell launched by agetty (which would automatically restart if exited).

I suspect that this might be a problem introduced by switching from a 3.0 kernel to a 3.1 kernel.

Comment 3 Roman Rakus 2011-09-19 15:07:56 UTC
Thanks. And is agetty launched or not?

Comment 4 Mark Hamzy 2011-09-19 15:21:28 UTC
That is a good question.  I only have access to this one console and I've lost the ability to type in it.  So I don't know how to investigate that. :)

Comment 5 Roman Rakus 2011-09-19 17:22:44 UTC
ssh connection or something like that?

Comment 6 Mark Hamzy 2011-10-05 19:05:44 UTC
So I was able to set up another hvc terminal to the machine.  And I noticed the following:

[anaconda root@(none) /]# strace -f -e write=4 /sbin/agetty -n hvc0 38400
...
socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4
connect(4, {sa_family=AF_FILE, path="/dev/log"}, 110) = 0
send(4, "<83>Oct  5 18:32:49 agetty[605]:"..., 95, MSG_NOSIGNAL) = 95
 | 00000  3c 38 33 3e 4f 63 74 20  20 35 20 31 38 3a 33 32  <83>Oct   5 18:32 |
 | 00010  3a 34 39 20 61 67 65 74  74 79 5b 36 30 35 5d 3a  :49 aget ty[605]: |
 | 00020  20 2f 64 65 76 2f 68 76  63 30 3a 20 63 61 6e 6e   /dev/hv c0: cann |
 | 00030  6f 74 20 67 65 74 20 63  6f 6e 74 72 6f 6c 6c 69  ot get c ontrolli |
 | 00040  6e 67 20 74 74 79 3a 20  4f 70 65 72 61 74 69 6f  ng tty:  Operatio |
 | 00050  6e 20 6e 6f 74 20 70 65  72 6d 69 74 74 65 64     n not pe rmitted  |
close(4)                                = 0
...

Comment 7 Mark Hamzy 2011-10-05 21:21:51 UTC
That discovery led me to systemd not setting up the controlling terminal before spawning agetty.

The following seems to work now!

boot: linux serial rd.break
...
switch_root:/# cp /sysroot/lib/systemd/system/loader.service /sysroot/lib/systemd/system/loader2.service
switch_root:/# cat << __EOF__ > /sysroot/lib/systemd/system/loader.service
[Unit]
Description=Shell on hvc0
BindTo=dev-hvc0.device
Wants=dev-hvc0.device rsyslog.service udev-settle.service
After=dev-hvc0.device rsyslog.service udev-settle.service

[Service]
Environment=HOME=/root MALLOC_CHECK_=2 MALLOC_PERTURB_=204 PATH=/usr/bin:/bin:/sbin:/usr/sbin:/mnt/sysimage/bin:/mnt/sysimage/usr/bin:/mnt/sysimage/usr/sbin:/mnt/sysimage/sbin PYTHONPATH=/tmp/updates TERM=linux
WorkingDirectory=/root
ExecStart=-/sbin/agetty -n -l /bin/bash hvc0 38400
Restart=always
RestartSec=0
TimeoutSec=0
TTYPath=/dev/hvc0
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
KillSignal=SIGHUP
__EOF__
switch_root:/# exit


Note You need to log in before you can comment on or make changes to this bug.