Bug#484366: rootskel: cttyhack requires the serial console to be /dev/ttyS0
On Wednesday 04 June 2008, Frans Pop wrote:
> On Tuesday 03 June 2008, Daniel Jacobowitz wrote:
> > I tried to install Debian on Versatile/PB using qemu and the armel
> > installer (Lenny beta 1). It is quickly stuck complaining
> > "cttyhack: '/dev/ttyS0': No such file or device".
>
> What _exact_ qemu command line did you use?
And of course, shortly after sending such a message you do reproduce it.
For the benefit of others:
- download armel versatile images
- start qemu with (add -nographic if needed/wanted):
$ qemu-system-arm -M versatilepb -serial pty -hda <disk image> \
-kernel vmlinuz-<kvers>-versatile -initrd initrd.gz \
-append "root=/dev/ram console=ttyAMA0"
- qemu will output what char device qemu it is using:
char device redirected to /dev/pts/1
- start minicom using:
$ minicom -s
- adjust minicom 'Serial port setup' to use /dev/pts/1 as Serial Device
(using the correct device reported by qemu - see above);
in 'Modem and dialing', remove the Init and Reset strings
(If -nographic is used, the boot will happen in the terminal where qemu is
started; if it is not used, minicom will have the boot messages and debug
shells.)
The console seems to be just /dev/console:
# readlink /proc/1/fd/0
/dev/console
# readlink /proc/self/fd/0
/dev/console
I'm not sure what the real problem here is, especially because I'm not
sure if current D-I (since the introduction of cttyhack) has really been
tested on systems that use something else than ttySx for their serial
consoles. I do know there are others.
AFAIK D-I used to work on those systems, without having to create those
devices. I'm also not sure whether there's a bug in cttyhack or that the
kernel isn't "telling" it what the correct device to use is.
The symlink approach below does not seem like the right solution as a
system could (in theory at least) have both ttySx and tty<whatever>x.
And as every arch/subarch/serial driver seems to want to invent its own
character devices, maintaining that would be unpleasant anyway.
The issue can easily be worked around:
- add extra boot parameter "BOOT_DEBUG=3" in -append option
- in first debug shell, use nano to edit /etc/inittab and just remove
'/bin/cttyhack' from ::sysinit: and ::respawn: lines
- use 'exit' to exit the debug shells
The following works as well (probably close to what Daniel did):
<workaround>
/lib/debian-installer/init-udev-devices:
for i in 0 1 2 3; do
- makedev 600 /dev/ttyS"$i" c 4 "$(($i + 64))"
+ makedev 600 /dev/ttyAMA"$i" c 204 "$(($i + 64))"
+ ln -s ttyAMA"$i" /dev/ttyS"$i"
done
/lib/debian-installer-startup.d/S02udev:
udevsettle
+for i in 0 1 2 3; do
+ ln -s ttyAMA"$i" /dev/ttyS"$i"
+done
exit 0
</workaround>
I have no idea where to go from here. Hope someone else does.
Cheers,
FJP
Reply to: