Debian Bug report logs - #21867
[closable?] CTRL-C is disabled during first boot

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: <mrvn@mirjam.informatik.uni-tuebingen.de>

To: submit@bugs.debian.org

Subject: base: CTRL-C is disabled during first boot

Date: Wed, 29 Apr 1998 12:30:35 +0200 (CEST)

Package: base
Version: N/A

During the first boot the CTRL-C is disabled. It should be reenabled
before dselect is started. Dselect tells the user that he can for
example cancel the acess method dialog with CTRL-C in case he mistyped.

-- System Information
Debian Release: 2.0 (frozen)
Kernel Version: Linux mirjam 2.0.33 #3 Tue Mar 24 12:33:04 CET 1998 i486 unknown

Message #12 received at 21867@bugs.debian.org (full text, mbox, reply):

From: Adam Di Carlo <adam@onshore.com>

To: <mrvn@mirjam.informatik.uni-tuebingen.de>

Cc: 21867@bugs.debian.org

Subject: CTRL-C is disabled during first boot

Date: 10 Jan 1999 13:13:09 -0500

> During the first boot the CTRL-C is disabled. It should be reenabled
> before dselect is started. Dselect tells the user that he can for
> example cancel the acess method dialog with CTRL-C in case he
> mistyped.

I don't understand this bug report.  When you say that Control-C is
disabled during the first boot, you really mean that Control-C simply
has no effect which the kernel is booting, which is true and correct.

Control-C is *enabled* after the kernel boot.

Are you saying you tried to use Control-C during a critical moment
(which one?) during dselect's operation (what were you trying to do?)
and it didn't work?

--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>

Message #17 received at 21867@bugs.debian.org (full text, mbox, reply):

From: mrvn@mirjam.informatik.uni-tuebingen.de (Goswin Brederlow)

To: adam@onshore.com, mrvn@mirjam.informatik.uni-tuebingen.de

Cc: 21867@bugs.debian.org

Subject: Re: CTRL-C is disabled during first boot

Date: Thu, 14 Jan 1999 16:20:43 +0100 (CET)

The inittab, or some other start script disables ctrl-c, to prevent
hacking during the boot process (or it simply didn't work) and until
login was run, it wasn't activated again. Its a long time since I
reported the bug, so I have to check and see if its still not working.
I know that a lot has changed on the install script, so maybe thats fixed
as well.

May the Source be with you.
			Goswin

Message #22 received at 21867@bugs.debian.org (full text, mbox, reply):

From: Adam Di Carlo <adam@onshore.com>

To: <mrvn@mirjam.informatik.uni-tuebingen.de>

Cc: 21867@bugs.debian.org

Subject: Re: CTRL-C is disabled during first boot

Date: 15 May 1999 17:19:27 -0400

> The inittab, or some other start script disables ctrl-c, to prevent
> hacking during the boot process (or it simply didn't work) and until
> login was run, it wasn't activated again. Its a long time since I
> reported the bug, so I have to check and see if its still not
> working.  I know that a lot has changed on the install script, so
> maybe thats fixed as well.

First off, you are talking about the first time that you boot from the
newly installed system, right?

Secondly, if this is a problem, its not a boot-floppies problem per
se, AFAIK.

Do you mind if I close this bug?  I'm a little hesitant to since I'm
not sure we've addresssed it or not.  I certainly haven't heard anyone
else complain about this sorta thing.

--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>

Message #29 received at 21867@bugs.debian.org (full text, mbox, reply):

From: Martin Schulze <joey@finlandia.Infodrom.North.DE>

To: 21867@bugs.debian.org, aph@debian.org

Subject: CTRL-C is disabled during first boot

Date: Thu, 20 May 1999 21:09:25 +0200

Mrvn:

> During the first boot the CTRL-C is disabled. It should be reenabled
> before dselect is started. Dselect tells the user that he can for
> example cancel the acess method dialog with CTRL-C in case he
> mistyped.

aph:
] I don't understand this bug report.  When you say that Control-C is
] disabled during the first boot, you really mean that Control-C simply
] has no effect which the kernel is booting, which is true and correct.

] Control-C is *enabled* after the kernel boot.

I have just done a test installation with my Slink disks and can
confirm this bug, unfortunately.

After you've done with the installation and reboot the system, you
go into dselect, an access method, but can't interrupt it with C-c.
However on a regular system you can interrupt it.

Thus: This *IS* a bug indeed, and we have to figure out who disables
INT

Regards,

	Joey

-- 
If you come from outside of Finland, you live in wrong country.
	-- motd of irc.funet.fi

Please always Cc to me when replying to me on the lists.

Message #36 received at 21867-done@bugs.debian.org (full text, mbox, reply):

From: Adam Di Carlo <adam@onshore.com>

To: 11926-done@bugs.debian.org, 21867-done@bugs.debian.org, 23337-done@bugs.debian.org, 27650-done@bugs.debian.org, 33950-done@bugs.debian.org, 35873-done@bugs.debian.org, 36657-done@bugs.debian.org, 47490-done@bugs.debian.org, 48779-done@bugs.debian.org, 48866-done@bugs.debian.org, 52596-done@bugs.debian.org

Subject: bugs fixed in boot-floppies 2.2.4

Date: Mon, 03 Jan 2000 14:52:09 -0500

Thank you for your bug report.  The bug should have been closed by
boot-floppies version 2.2.4, now in unstable (for i386, others
following shortly).  Let us know if you have any more problems.

.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>

Changes: boot-floppies (2.2.4) unstable; urgency=low
 .
  * fdisk: using the 2.2 features of the /proc file-system, we should be
    able to detect any and all kernel-supported r/w random-access devices
  * dbootstrap: installation via HTTP method (net-fetch) added; messages
    not yet tuned, this method should work fine but might not look pretty
    yet
  * dbootstrap: look for files and stuff in
    dists/potato/main/disks-%s/current where %s is the architecture name
  * busybox: more updates, fixing some critical problems in tar (setuid
    not respected, files with symlinks to them (i.e. libc) set to 777),
    cp, and mv didn't work for directories; fix problem where symlink
    targets were made world-writable (!)
  * dbootstrap: when writing /etc/fstab, use tabs (closes: Bug#11926,
    Bug#36657)
  * dbootstrap: add commented out /dev/pts example to /etc/fstab
    (closes: Bug#33950)
  * dbootstrap: don't ask about GMT or not on m68k; when we *do* ask about
    it, do it in one dialog box, not two; look for UTC not GMT in
    /etc/default/rcS (closes: Bug#48866)
  * base: remove setserial from sparc platform
  * base: add xviddetect, and pciutils -- these are not yet integrated,
    however; debconf-tiny integration put off due to critical
    perl-5.005-base bugs
  * rescue: rdev.sh handles an alternate kernel location as an optional
    argument (closes: Bug#27650)
  * dbootstrap: ask when mke2fs'ing whether to use 2.2 specific features
    (closes: Bug#47490)
  * dbootstrap: change the wording of the name server selection
    (closes: Bug#23337); many other wording changes
  * dbootstrap: don't put `vga=normal' in the default lilo.conf since it
    apparently breaks MDA graphics cards (closes: Bug#35873)
  * top-level Makefile: check for dependancies by examining
    /var/lib/dpkg/status instead of running `dpkg --get-selections' since
    the latter only shows whether a package is *selected* for installation
    (closes: Bug#52596)
  * scripts/basedisks/new_root_home/.bash_profile: trap `:' instead of `""'
    so that children don't ignore the signals (closes: Bug#21867)
  * dbootstrap: be more specific when prompting for floppies
    (closes: Bug#48779)
  * debian/rules: scrub /usr/src/boot-floppies.tar.gz more, removing wierd
    ownership and permissions

Send a report that this bug log contains spam.