Re: Bug#60891: xdm: Installs default tty7 line in Xservers -- break s system
Note to the other two maintainers. Branden has closed the bug I
submitted. Based on the information he provided to me in his message I
feel that you also should close the bugs I submitted against gdm and
wdm. They should possibly be re-submitted at a lesser severity, but not
as critical. Please read my message below and determine for yourself.
Branden, I've just subscribed to debian-users and have yet to get any
messages after my confirmation. Please feel free to forward this if my
CC dosn't go through.
Hmm, Just re-read my bug-report message. Used too much cut/paste to post
the three reports. As stated in the final paragraph, I do NOT have xdm
installed right now, I have wdm. So I relied on the fact that all 3
packages defaulted to tty7 and that it is applied by the wdm.postinst
script...
---snip---
#! /bin/sh -e
#
# WDM postinst.
#
# (C) 1998, 1999 Marcelo Magallon <mmagallo@debian.org>
wdm_config_file=/etc/X11/wdm/wdm-config
wdm_Xsession=/etc/X11/wdm/Xsession
common_Xsession=/etc/X11/Xsession
wdm_Xservers=/etc/X11/wdm/Xservers
xdm_Xservers=/etc/X11/xdm/Xservers
default_local_server=":0 local /usr/bin/X11/X vt7"
---snip---
Also, in three paragraphs I used *6* all-caps words. Hardly throwing
them around gratuitously. (you used ~90 in 12 paragraphs). At least you
did say I was good at describing the problem, that was my intent all
along.
As for the fact that the postinst scripts are sure to leave prior config
files intact -- that hardly applies when I've not installed the package
previously or if I have purged a package not planning to use it again.
I am on a single, non-networked, machine in a home environment with
multiple users. As we trust each other, we often leave a tty open and
logged in. Therefore, early on I adjusted my inittab to run a getty on
tty1 through tty10. I pipe some of syslogs output to tty11 and have used
tty12 for X for quite a while. If there are others in a similar
situation who decide to install one of these packages it will cause
similar problems.
I did ask on openprojects IRC #debian several days running to see if
anyone else had experienced this problem. There were several
suggestions relating to using (or not) xkb and a few other things I
can't recall now. But only ONE person suggested checking that
particular config file to see if it was trying to start on a tty with a
getty running.
To be honest, I am not a programmer of any sort. I can hack together
shell scripts to do things I need if I really have to, but that's about
it. When the problem exhibited itself I did not even consider checking
the "X FAQ". I had no problem at all with X, it worked just fine using
'startx' and has for quite some time. My problem was with all 3 display
managers. Checking the FAQ for the X-window system itself did not occur
to me, and I don't think it will to new users either.
I personally still think it is a bug though I have NO idea how to work
around it. The default installation causes some systems to require a
hard reset into single mode in order to correct the problem. In my mind
that makes it a critical bug -- but since it will most likely affect
very few systems it could probably be argued that it is a level 1 bug,
or with the difficulty of fixing it, it could even be a level 0 bug.
In the future, however, I will make an attempt to strike up a dialog
with the maintainer of a package to help determine if I should submit a
bug report. I believe debian's goal is to create a system usable by
most. Such a system must somehow account for some unexpected setups. I
submitted a non-critical bug in a couple of -doc packages that Manoj
Srivastava maintains. The ONLY cause for the installs to break was my
horrid drive partitioning that had left me with too little room on
/usr. I had the /usr/doc and /usr/share/doc directories symlinked in
from elsewhere and that broke the postinst quite thoroughly. He fixed
the problem on his end and I also found a way to back up and
re-partition my drives properly.
I did not feel my bug report was impolite or condescending. I was
merely trying to clearly describe what had happened to me and could,
conceivably, happen to other first time users of the display manager
packages.
As far as not 'assigning a bug critical severity', when I run 'bug' it
asks me to give a one line description, then asks me to 'assign a
severity' based on the descriptions it gives. I chose critical because
it caused the 'whole system' to break and require a hard reset:
4) Critical bug. Makes unrelated software on the system (or the whole
system) break, or causes serious data loss, or introduces a security
hole on systems where you install the package.
I think that having the '*dm' packages not start on install if no prior
in stallation is detected and post a *notice* on screen describing the
need to correct the Xservers (or gdm.conf) file would be enough to
mostly guarantee that this wouldn't happen. Being required to hard
reset your machine in single mode to read the documentation to find out
why it locked up is not conducive to keeping ones blood pressure at a
normal level.
Ryan Murray nicely explained the way the dm and init would race to grab
tty's if no default at all were set. I'm showing my ignorance again,
but can a dm be started from /etc/inittab the same as the getty
processes? That would allow the *dm install to possibly read
/etc/inittab to determine the last tty with a getty installed and
install itself on the next one available.
On 21 Mar, Branden Robinson wrote:
> On Tue, Mar 21, 2000 at 04:11:44PM -0600, gvl@phorce1.com wrote:
>> Package: xdm
>> Version: N/A
>> Severity: critical
>
> I don't appreciate critical bug reports that reveal such profound ignorance
> of the Debian system in general, and of the xdm package specifically.
>
>> When installed with apt-get xdm postinst inserts a default line in
>> /etc/X11/xdm/Xservers of ':0 local /usr/bin/X11/X vt7' if instructed to
>> handle a local session.
>
> It does no such thing. You obviously didn't bother to read the postinst
> script, so here it is.
-postinst deleted-
>> This will cause ANY system that has 'login'
>> running on vt7 to break.
>
> If YOU had READ the FAQ that is shipped with ALL Debian installations of the
> X WINDOW SYSTEM, you would KNOW that this problem is WELL-KNOWN about and
> that there is a WELL-KNOWN FIX.
>
> You'd also UNDERSTAND that because /etc/X11/xdm/Xservers is a CONFFILE,
> your CHANGES to the file, such as NOT STARTING AN X SERVER ON VT 7, are
> RESPECTED during upgrades; if the upstream version has changed AND you have
> MODIFIED your version, then you are ASKED which version you want to
> install. You are EXPLICITLY given the OPTION of KEEPING YOUR VERSION of
> the file. In FACT, this is the DEFAULT.
>
> If YOU failed to UNDERSTAND the prompt you were given, that is YOUR
> PROBLEM. If YOU had BOTHERED to INVESTIGATE, you would NOTE that even if
> you do make such a MISTAKE, the OLD VERSION of the file WITH YOUR
> MODIFICATIONS is PRESERVED with the suffix ".dpkg-old" so that YOU may MOVE
> IT BACK INTO PLACE.
>
>> postinst should ASK what vt you normally run X on (12 on my system) and
....
>> postinst should put up an interactive
>> NOTE suggesting that the customer modify the file by hand to include a
>> default vt.
>
> USERS should READ the DOCUMENTATION provided with a package before FILING a
> CRITICAL BUG REPORT.
>
> They should also ENDEAVOR to be POLITE when filing them, and not speak
> CONDESCENDINGLY to PACKAGE MAINTAINERS who are VOLUNTEERS serving MANY
> USERS with MANY DIFFERENT NEEDS.
>
> Furthermore, PEOPLE who file BUG REPORTS should refrain from GRATUITOUS
> CAPITALIZATION OF WORDS in order to promote a MORE CIVIL DISCOURSE about
> possible PROBLEMS with the SYSTEM.
>
> Just as soon as you come up with a common configuration file format and
> implementation method which sysvinit (/etc/inittab) and all X display
> managers can refer to for information about what virtual consoles to use,
> I'd be happy to accommodate you.
>
> In the MEANTIME, I suggest you NOT OVERWRITE CONFFILES on your system
> without UNDERSTANDING what you are DOING. And try to be more THOUGHTFUL in
> the future before assigning a bug CRITICAL SEVERITY. In fact, you might
> even leave it up to the PACKAGE MAINTAINER or other Debian DEVELOPERS, who
> have EXPERIENCE with the system, to make such a judgment.
>
> I'm CC'ing debian-user so that people can see how *not* to file a bug
> report. This person was good at describing the symptoms of his problem,
> but had obviously not read any documentation, like the Debian X FAQ[1], and
> had an utterly incorrect understanding of how the /etc/X11/xdm/Xservers
> file is handled. It is all right for a user to not understand the
> sometimes complicated implementation details of the Debian system -- no one
> can know everything -- but to pretend that you know, be completely wrong
> about it, and then advertise this fact to the package maintainer in an
> angry bug report is not the correct way to admit your ignorance.
>
> [1] /usr/share/doc/xfree86-common/FAQ.gz; this file just happens to be
> referenced at the top of /usr/share/doc/xdm/README.Debian.
--
'69 Bug (Airball, the Rolling Basket Case)
Have a look at my online store for gift ideas:
<a HREF="http://shop.affinia.com/phorce1/Store/";></a>
Reply to: