Bug#435469: marked as done (linux-source-2.6.22: udev: common user action causes undecipherable hang)
Your message dated Wed, 1 Aug 2007 00:50:38 +0200
with message-id <20070731225037.GB7506@baikonur.stro.at>
and subject line Bug#435469: linux-source-2.6.22: udev: common user action causes undecipherable hang
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: linux-source-2.6.22
Version: 2.6.22-1
Severity: normal
File: linux-source-2.6.22
summary: you can't boot from a naive mirror anymore. i have a
solution below.
a user who copies to a root partition with rsync (at least with
--one-file-system) will most likely expect it to boot. instead it
hangs with "unable to create an initial virtual console". this can
lead to users throwing the computer out a window, or doing unnecessary
debugging. ahem.
the suboptimal workaround is to special-case /dev/.static/dev . this
is not obvious to people who don't know about udev.
so for the sake of this common operation by likely many users, instead
of hanging, i think that the kernel should boot. at least the
following solution allows this:
1. udev put .static on the actual disk so that rsync copies it.
2. on boot, if /dev is unpopulated and unbootable, the kernel
looks for .static, and fixes things.
if this is unworkable, the kernel should check for an unpopulated /dev
and tell the user about it.
in general, imho the kernel can be improved in many ways like this to
help the user.
thanks.
-- System Information:
Debian Release: 4.0
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22myver-6-badinstall
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages linux-source-2.6.22 depends on:
ii binutils 2.17-3 The GNU assembler, linker and bina
ii bzip2 1.0.3-6 high-quality block-sorting file co
Versions of packages linux-source-2.6.22 recommends:
ii gcc 4:4.1.1-15 The GNU C compiler
ii libc6-dev [libc-dev] 2.3.6.ds1-13 GNU C Library: Development Librari
ii make 3.81-2 The GNU version of the "make" util
-- no debconf information
--- End Message ---
--- Begin Message ---
On Tue, Jul 31, 2007 at 02:48:59PM -0700, gambarimasu+reportbug@gmail.com wrote:
> Package: linux-source-2.6.22
> Version: 2.6.22-1
> Severity: normal
> File: linux-source-2.6.22
the bug you describe seems not relate to the package
you assigned it.
> summary: you can't boot from a naive mirror anymore. i have a
> solution below.
i would love my boxes to boot from a debian mirror no need of
any root :P
i guess that was not what you meant..
> a user who copies to a root partition with rsync (at least with
> --one-file-system) will most likely expect it to boot. instead it
> hangs with "unable to create an initial virtual console". this can
> lead to users throwing the computer out a window, or doing unnecessary
> debugging. ahem.
>
> the suboptimal workaround is to special-case /dev/.static/dev . this
> is not obvious to people who don't know about udev.
>
> so for the sake of this common operation by likely many users, instead
> of hanging, i think that the kernel should boot. at least the
> following solution allows this:
>
> 1. udev put .static on the actual disk so that rsync copies it.
> 2. on boot, if /dev is unpopulated and unbootable, the kernel
> looks for .static, and fixes things.
>
> if this is unworkable, the kernel should check for an unpopulated /dev
> and tell the user about it.
hmmm again that is a userspace policy and has nothing to do with
the kernel code itself. once init(1) is caled you are in deep userland.
i agree that the complexity of modern linux boxes has grown from
the old standard unix anyway things get only better :)
closing before leaving that to bitrot
regards
--
maks
--- End Message ---
Reply to: