Processed: please integrate the em8300 module
Processing commands for [EMAIL PROTECTED]: > reassign 446222 linux-modules-contrib-2.6 Bug#446222: em8300: Integration into linux-modules-contrib-2.6 Bug reassigned from package `em8300' to `linux-modules-contrib-2.6'. > submitter 446222 ! Bug#446222: em8300: Integration into linux-modules-contrib-2.6 Changed Bug submitter from [EMAIL PROTECTED] to Nicolas Boullis <[EMAIL PROTECTED]>. > retitle 446222 please integrate the em8300 module Bug#446222: em8300: Integration into linux-modules-contrib-2.6 Changed Bug title to `please integrate the em8300 module' from `em8300: Integration into linux-modules-contrib-2.6'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: serial driver/irda conflict resolution?
Mikko Rapeli wrote: > Etch kernels at least have serial 8250 built in, but it conflicts with > the irda chip on a Thinkpad T20. With modular driver I can override this > by adding the irda driver nsc-ircc to /etc/initramfs-tools/modules, but > how do I tell the distro kernel not to give io 0x3f7, irq 4 and dma 3 to > 8250? You may want to take a look at this bugs: http://bugzilla.kernel.org/show_bug.cgi?id=3575 http://bugzilla.kernel.org/show_bug.cgi?id=8991 There are people working to fix this problem for a long time. I load nsc-ircc irda with this script: setserial /dev/ttyS1 uart none modprobe nsc-ircc irq=3 io=0x02f8 dma=3 dongle_id=0x09 irattach irda0 -s MAKEDEV ircomm chmod 666 /dev/ircomm0 Ahora también puedes acceder a tu correo Terra desde el móvil. Infórmate pinchando aquí.
Bug#447766: Kernel panic when rebooting a xen DomU
Package: linux-image-2.6.18-5-xen-686 Version: 2.6.18.dfsg.1-13etch4 On a Dell 2950 server, I rebooted a Xen instance: xm reboot backup then I remember checking the console for progress: xm console backup and when the DomU rebooted (or shortly after, I can't remember), I got a kernel panic (I got it through multiple "Message from [EMAIL PROTECTED] at Tue Oct 23 15:48:26 2007 ..." over my SSH connection): n8 kernel: [ cut here ] n8 kernel: kernel BUG at drivers/xen/core/evtchn.c:481! n8 kernel: invalid opcode: [#1] n8 kernel: SMP n8 kernel: CPU:5 n8 kernel: EIP is at retrigger+0x1f/0x35 n8 kernel: eax: ebx: 0208 ecx: 0026 edx: f55f6000 n8 kernel: esi: c0317860 edi: 011a ebp: esp: c039feb0 n8 kernel: ds: 007b es: 007b ss: 0069 n8 kernel: Process xenwatch (pid: 29, ti=c039e000 task=c0ead000 task.ti=c039e000) n8 kernel: Stack: c013b201 c0317860 011a c0317888 c013af57 db38dec0 n8 kernel:db38dec0 c02171c8 c02175a8 c0210737 0010 020a n8 kernel:0209 c0a8f475 c02e57a4 ee338000 0002 n8 kernel: Call Trace: n8 kernel: Code: ee 85 f6 75 96 58 5a 5b 5e 5f 5d c3 0f b7 0c 85 40 98 37 c0 8b 15 84 09 2d c0 85 c9 74 1d 0f a3 8a 80 08 00 00 19 c0 85 c0 75 08 <0f> 0b e1 01 92 0a 2b c0 f0 0f ab 8a 00 08 00 00 b8 01 00 00 00 n8 kernel: EIP: [] retrigger+0x1f/0x35 SS:ESP 0069:c039feb0 Attached is what I could get using the Remote Console Access (RAC). This is a screen capture of tty1. Also attached is the syslog around that time. The server froze and I had to reboot it. HTH, -- Sylvain <>Oct 23 15:45:07 n8 snmpd[3047]: Connection from UDP: [212.99.96.245]:45629 Oct 23 15:45:08 n8 last message repeated 45 times Oct 23 15:48:24 n8 kernel: br-xen: port 2(vif1.0) entering disabled state Oct 23 15:48:24 n8 kernel: device vif1.0 left promiscuous mode Oct 23 15:48:24 n8 kernel: audit(1193147304.991:4): dev=vif1.0 prom=0 old_prom=256 auid=4294967295 Oct 23 15:48:24 n8 kernel: br-xen: port 2(vif1.0) entering disabled state Oct 23 15:48:25 n8 logger: /etc/xen/scripts/vif-bridge: offline XENBUS_PATH=backend/vif/1/0 Oct 23 15:48:25 n8 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/1/2049 Oct 23 15:48:25 n8 logger: /etc/xen/scripts/vif-bridge: brctl delif br-xen vif1.0 failed Oct 23 15:48:25 n8 logger: /etc/xen/scripts/vif-bridge: ifconfig vif1.0 down failed Oct 23 15:48:25 n8 logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/1/2049 Oct 23 15:48:25 n8 logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge offline for vif1.0, bridge br-xen. Oct 23 15:48:25 n8 logger: /etc/xen/scripts/vif-bridge: online XENBUS_PATH=backend/vif/2/0 Oct 23 15:48:25 n8 logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vif/1/0 Oct 23 15:48:25 n8 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/2/2049 Oct 23 15:48:25 n8 kernel: device vif2.0 entered promiscuous mode Oct 23 15:48:25 n8 kernel: audit(1193147305.747:5): dev=vif2.0 prom=256 old_prom=0 auid=4294967295 Oct 23 15:48:25 n8 kernel: ADDRCONF(NETDEV_UP): vif2.0: link is not ready Oct 23 15:48:25 n8 logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif2.0, bridge br-xen. Oct 23 15:48:25 n8 logger: /etc/xen/scripts/vif-bridge: Writing backend/vif/2/0/hotplug-status connected to xenstore. Oct 23 15:48:25 n8 logger: /etc/xen/scripts/block: Writing backend/vbd/2/2049/physical-device fe:0 to xenstore. Oct 23 15:48:25 n8 logger: /etc/xen/scripts/block: Writing backend/vbd/2/2049/hotplug-status connected to xenstore. Oct 23 15:48:26 n8 kernel: [ cut here ] Oct 23 15:48:26 n8 kernel: kernel BUG at drivers/xen/core/evtchn.c:481! Oct 23 15:48:26 n8 kernel: invalid opcode: [#1] Oct 23 15:48:26 n8 kernel: SMP Oct 23 15:48:26 n8 kernel: Modules linked in: xt_physdev iptable_filter ip_tables x_tables button ac battery ipv6 bridge sg sr_mod loop usb_storage 8250_pnp psmouse 8250 serial_core serio_raw rtc pcspkr shpchp pci_hotplug joydev evdev ext3 jbd mbcache usbhid dm_mirror dm_snapshot dm_mod ide_cd cdrom generic sd_mod piix ide_core ehci_hcd uhci_hcd usbcore bnx2 megaraid_sas scsi_mod thermal processor fan Oct 23 15:48:26 n8 kernel: CPU:5 Oct 23 15:48:26 n8 kernel: EIP:0061:[]Not tainted VLI Oct 23 15:48:26 n8 kernel: EFLAGS: 00010046 (2.6.18-5-xen-686 #1) Oct 23 15:48:26 n8 kernel: EIP is at retrigger+0x1f/0x35 Oct 23 15:48:26 n8 kernel: eax: ebx: 0208 ecx: 0026 edx: f55f6000 Oct 23 15:48:26 n8 kernel: esi: c0317860 edi: 011a ebp: esp: c039feb0 Oct 23 15:48:26 n8 kernel: ds: 007b es: 007b ss: 0069 Oct 23 15:48:26 n8 kernel: Process xenwatch (pid: 29, ti=c039e000 task=c0ead000 task.ti=c039e000) Oct 23 15:48:26 n8 kernel: Stack: c013b201 c0317860 011a c0317888 c013af57 db38dec0 Oct 23 15:48:26 n8 kernel:db38dec0
Bug#447611: update-initramfs triggerisation
maximilian attems <[EMAIL PROTECTED]> writes: >> > > +binary-install/initramfs-tools:: >> > > +install -m 644 -o 0 -g 0 debian/initramfs-tools.triggers \ >> > > +debian/initramfs-tools/DEBIAN/triggers >> > >> > no i-t uses cdbs, >> > please add to debian/initramfs-tools.install >> > but maybe i misread and there is no cdbs support for that yet?? >> >> Stuffing files into DEBIAN/ with .install seemed a bit wrong to me, >> and I thought this approach with a hook was better. >> >> In the future I imagine debhelper will copy .triggers into >> the right place itself. > > debhelper does it according to joeyh, > i haven't looked yet at how i'd have to invoke it. http://packages.qa.debian.org/d/debhelper/news/20071022T181701Z.html -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
maximilian attems writes ("Re: Bug#447611: update-initramfs triggerisation"):
> thanks for your quick reply.
NP
> On Tue, 23 Oct 2007, Ian Jackson wrote:
> > Changes to debian/changelog always tend to get rejected if you apply a
> > patch to a different version because the context is the previous
> > version which contains the previous version number.
>
> yeah it is a primitive versioning system.
Annoying, isn't it. It's nice to see some efforts towards improving
the situation ...
> > test(1) has really strange argument parsing, [...]
>
> ok thanks for the lesson.
> never the less i'd prefer to have more readable code,
> then to take into account crazy non posix sh.
> update-initramfs is anyway linux specific.
I think you misunderstood me. I'm not saying that failing to use
"x$..." is nonportable. I'm saying that it can be ambiguous in the
sense that even the test(1) we're actually using (in practice, the
builtins in bash and dash) may sometimes get it wrong, where `wrong'
means `not what we intended'.
My example was that if you write
test '(' "$var" ')'
then it will go wrong when var='=' because it is interpreted as if you
had meant
test "$a" = "$b"
with a='(' and b=')'.
The exact circumstances in which the expression can be ambiguous are
very complicated. The best approach therefore is to prefix the
arguments to these kind of comparisons with `x' so that they cannot be
misinterpreted by test as operators. Ie the solution is to write
test "x$var" != x
which can never look like anything except a comparison because none of
test's operators or syntax start with an x.
If we write our scripts this way all of the time then there is no
possibility that someone who later makes the code more complicated by
adding additional clauses to the test, or introduces additional
possible values for the inputs, will cause it to break. And we get
into the habit of writing code which is always correct, without having
to prove each time that the particular construction we use can never
be misunderstood by test(1).
This area is a subset of the principle of argument unparsing - that
is, how to pass arbitrary arguments to a program without possibility
of misunderstanding.
In general if you see constructions of the form
command-name "$inputvariable" ...
you should be suspicious. What if inputvariable contains a string
which is meaningful to command-name as an option ? Hence
command-name -- "$inputvariable" ...
et al.
> > In the future I imagine debhelper will copy .triggers into
> > the right place itself.
>
> debhelper does it according to joeyh,
> i haven't looked yet at how i'd have to invoke it.
Oh, has he added that already ? The version I had to hand didn't seem
to but perhaps I misread the documentation or was reading the wrong
version.
> i'll see to push a variant in git next days,
> may ping you for review..
Sure.
> so that i can upload it promptly with new dpkg.
Excellent. (As I said, though, I think there is no need to wait.)
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
thanks for your quick reply.
On Tue, 23 Oct 2007, Ian Jackson wrote:
[snipp ubuntu explanation]
> I obviously thought it would be better to send you the patch we were
> actually using rather than some `special' version which we hadn't
> tested. You are of course free to remove tests of this kind, but in
> the general that just makes a bit more work for the Ubuntu developer
> who next has to merge initramfs-tools from Debian.
curious on review :)
> Changes to debian/changelog always tend to get rejected if you apply a
> patch to a different version because the context is the previous
> version which contains the previous version number.
yeah it is a primitive versioning system.
> test(1) has really strange argument parsing, which is sometimes
> ambiguous. Prefixing unknown input strings with x avoids accidentally
> treating those strings as operators or syntactic elements.
>
> For example, consider:
> test '(' '=' ')'
>
> Is this
> test '(' EXPR ')' where EXPR is '=', equivalent to -n '='
> or
> test A '=' Bwhere A is '(' and B is ')'
> ?
>
> It may be possible in particular cases to show that the problem cannot
> arise. SuSv3 has a crazy set of explicit rules which only go as far
> as up to 4 arguments (and so answers my question above). So both to
> avoid having to do a detailed analysis of test(1)'s argument parsing
> and of the possible input strings, and as a matter of good programming
> habit, it is better to write code the way it will always work (even if
> a subsequent programmer makes it more complex).
ok thanks for the lesson.
never the less i'd prefer to have more readable code,
then to take into account crazy non posix sh.
update-initramfs is anyway linux specific.
> In your version the "..." around `triggered' are superfluous. When I
> see that in a shell script I start to wonder whether the author knows
> the proper sh quoting rules. I trust that you do :-) but I would
> suggest avoiding idioms which tend to undermine the reader's
> confidence in the author.
ack
> > > +interest update-initramfs
> > "interest" ???
>
> `interest' is the directive name used in the triggers file to specify
> that this package needs to know about activations of the named
> trigger.
ok, thanks i'll add your comment.
> I chose the explicit trigger name `update-initramfs' since it seemed
> like an obvious choice. The guideance in the triggers spec (which I
> wrote, of course) says that it's often good to choose a command or
> package name and the command name seems like a good choice here.
>
> Do you have a different view ?
no,
the meaning of the keywoard "interest" is new to me.
> > > +binary-install/initramfs-tools::
> > > + install -m 644 -o 0 -g 0 debian/initramfs-tools.triggers \
> > > + debian/initramfs-tools/DEBIAN/triggers
> >
> > no i-t uses cdbs,
> > please add to debian/initramfs-tools.install
> > but maybe i misread and there is no cdbs support for that yet??
>
> Stuffing files into DEBIAN/ with .install seemed a bit wrong to me,
> and I thought this approach with a hook was better.
>
> In the future I imagine debhelper will copy .triggers into
> the right place itself.
debhelper does it according to joeyh,
i haven't looked yet at how i'd have to invoke it.
> I agree that this isn't the best style. One reason why I did it this
> way because I wanted to be sure that it did only and exactly what I
> intended it to. Another way of looking at it is that I regarded
> myself as wrapping update-initramfs. Obviously since update-initramfs
> is a script this could be done in code at the top of the script.
i see.
> > you may want to checkout latest git
> > git clone git://git.debian.org/git/kernel/initramfs-tools.git
>
> Would you like me to prepare a new patch based on your comments ?
no need,
patch is explicit enough.
i'll see to push a variant in git next days,
may ping you for review..
so that i can upload it promptly with new dpkg.
amicalement
--
maks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
maximilian attems writes ("Re: Bug#447611: update-initramfs triggerisation"):
> hmm the relevant bug reports didn't get cc'ed to dpkg speaking of
> #447609
You mean this comment:
Couldn't file triggers be used, so ldconfig is triggered after any
package installs a library file? That's much more how I expected
triggers to be used, rather than needing an ugly ldconfig wrapper. I
think it also addresses drow's point about libraries in nonstandard
locations, since those packages could just run ldconfig as usual.
Meanwhile, packages installing libraries to standard locations could
stop calling ldconfig.
?
That's about ldconfig. It doesn't really make sense for
update-initramfs because the set of files which might need to activate
the trigger is all of the files which are copied into the initramfs.
The resulting list is (a) large, (b) hard to compute and (c) not
fixed.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
maximilian attems writes ("Re: Bug#447611: update-initramfs
triggerisation"):
> [stuff]
Thanks for looking at my patch.
> > + dpkg --compare-versions "$DPKG_RUNNING_VERSION" ge '1.14.5ubuntu10~~'
> > +then
>
> ubuntu specific, would with high probab trigger on the wrong versions,
> also why is this needed?
> has there been a buggy dpkg trigger support!?
There was indeed a buggy dpkg trigger support version in some versions
of Ubuntu gutsy before it was released. Early in the release cycle of
a particular Ubuntu version many features are thrown into the Ubuntu
archive in a fairly ill-tested state - much more so than you would
typically do in Debian unstable.
So it shouldn't be seen as alarming or unusual that some bugs were in
the Ubuntu archive version at that stage, any more than it would be
alarming or unusual for a Debian developer to locally try out buggy
code, or share it with co-developers eg via experimental, while doing
pre-sid testing.
To be honest I don't have complete records of which versions were
buggy in the relevant way. That test is harmless in Debian because
none of the buggy versions were ever in Debian, and all
trigger-supporting versions in Debian will have a higher version
number. (We're not going to be backporting this large change, I
assume.)
At the time when I wrote the patch, that test served to protect Ubuntu
testers and developers who had the buggy dpkg from the consequences of
the bug. Using that particular syntax (with the ~~) also meant that I
was able to test the effect using some private versions I had built
locally without editing the version string just before upload (which
is obviously error-prone).
I obviously thought it would be better to send you the patch we were
actually using rather than some `special' version which we hadn't
tested. You are of course free to remove tests of this kind, but in
the general that just makes a bit more work for the Ubuntu developer
who next has to merge initramfs-tools from Debian.
In this particular case since the buggy dpkg existed only in early
versions of Ubuntu gutsy, I think this test has served its purpose and
can be discarded from Ubuntu as well as Debian.
> need to get a deeper look in git-dch as debian changelog only generates
> conflicts, better snipped for now also as ubuntu specific:
> patching file debian/changelog
> Hunk #1 FAILED at 1.
> 1 out of 1 hunk FAILED -- saving rejects to file debian/changelog.rej
Changes to debian/changelog always tend to get rejected if you apply a
patch to a different version because the context is the previous
version which contains the previous version number.
> > +if [ "x$1" != xtriggered ] && \
>
> if [ "$1" != "triggered" ] && \
>
> seems more readable, don't know why the oldstyle x$string = string
> remains in usage?
test(1) has really strange argument parsing, which is sometimes
ambiguous. Prefixing unknown input strings with x avoids accidentally
treating those strings as operators or syntactic elements.
For example, consider:
test '(' '=' ')'
Is this
test '(' EXPR ')' where EXPR is '=', equivalent to -n '='
or
test A '=' Bwhere A is '(' and B is ')'
?
It may be possible in particular cases to show that the problem cannot
arise. SuSv3 has a crazy set of explicit rules which only go as far
as up to 4 arguments (and so answers my question above). So both to
avoid having to do a detailed analysis of test(1)'s argument parsing
and of the possible input strings, and as a matter of good programming
habit, it is better to write code the way it will always work (even if
a subsequent programmer makes it more complex).
In your version the "..." around `triggered' are superfluous. When I
see that in a shell script I start to wonder whether the author knows
the proper sh quoting rules. I trust that you do :-) but I would
suggest avoiding idioms which tend to undermine the reader's
confidence in the author.
> > update-initramfs -u
> > + # ... this activates the trigger, if triggers are working
>
> please comment before command.
Sorry, I evidently didn't look down far enough to see your existing
coding style, which I should of course have copied.
> > +interest update-initramfs
> "interest" ???
`interest' is the directive name used in the triggers file to specify
that this package needs to know about activations of the named
trigger.
I chose the explicit trigger name `update-initramfs' since it seemed
like an obvious choice. The guideance in the triggers spec (which I
wrote, of course) says that it's often good to choose a command or
package name and the command name seems like a good choice here.
Do you have a different view ?
> > +binary-install/initramfs-tools::
> > + install -m 644 -o 0 -g 0 debian/initramfs-tools.triggers \
> > + debian/initramfs-tools/DEBIAN/triggers
>
> no i-t uses cdbs,
> please add to debian/initramfs-tools.install
> but maybe i misread and there is no cdbs support for that yet??
Stuffing files
Bug#405232: include rt2400/rt2500/rt2570/rt2x00
On Wed, Oct 10, 2007 at 06:54:05PM +0200, Daniel Baumann wrote: > What is the status of this, should/can I include the drivers into > linux-modules-extra-2.6 now? I don't remember what was the problem, but I guess now they can be included. Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
On Tue, Oct 23, 2007 at 12:25:10PM +0100, Ian Jackson wrote:
> maximilian attems writes ("Re: Bug#447611: update-initramfs triggerisation"):
> > it is a prerequisite, until not merged i have zero evidence that the
> > interface may not have changed. afais on dpkg devel joeyh raised
> > good critics on how the trigger support is done.
>
> The only message I can find recently from Joey Hess on debian-dpkg
> regarding triggers is this one:
> http://lists.debian.org/debian-dpkg/2007/10/msg00047.html
> in which he seems keen. Where should I be looking, please ?
hmm the relevant bug reports didn't get cc'ed to dpkg speaking of
#447609
--
maks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
maximilian attems writes ("Re: Bug#447611: update-initramfs triggerisation"):
> it is a prerequisite, until not merged i have zero evidence that the
> interface may not have changed. afais on dpkg devel joeyh raised
> good critics on how the trigger support is done.
The only message I can find recently from Joey Hess on debian-dpkg
regarding triggers is this one:
http://lists.debian.org/debian-dpkg/2007/10/msg00047.html
in which he seems keen. Where should I be looking, please ?
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409271: initramfs-tools: NFSv4 not supported
I've played around a bit with this and although I don't have anything that works yet, here's some ideas on how it could be implemented: I assume that DHCP and ip config is already taken care of (as the nfs support has that code already). I also assume that most people will be using NFSv4 with Kerberos authentication (it seems to be the most common setup). The following files would need to be added to the initramfs: /usr/sbin/rpc.gssd /usr/sbin/rpc.idmapd Config files for kerberos and the two rpc daemons Kernel modules (nfs and rpcsec_gss_krb5) nfs4 capable mount program Since it would probably be a bad thing to store the kerberos keytab inside the initramfs image, my idea was to use kadmin to get the nfs principal (usually nfs/[EMAIL PROTECTED]) from the kdc, so /usr/sbin/kadmin would be added as well. A initramfs config file can hold the principal to use for nfs and the realm. Then the setup would be: 1. Setup networking 2. Use kadmin to get nfs/[EMAIL PROTECTED] and store to /etc/krb5.keytab: kadmin -r REALM -p userprincipal -q "ktadd -k /etc/krb5.keytab nfs/[EMAIL PROTECTED]" (note: userprincipal defaults to root/admin) 3. Mount rpc_pipefs on /var/lib/nfs/rpc_pipefs 4. Load kernel modules 5. Start rpc.gssd and rpc.idmapd 6. Mount NFS root When initramfs is done, it will nuke the contents of the initramfs (including the keytab) from memory. The keytab to use thereafter is expected to be found in /etc/krb5.keytab after pivot_root as usual. The main problems seem to be: o How and when should the rpc daemons be restarted so that the ones from the nfs-root-fs are used instead of the ones from initramfs? This is especially important if some of the hacks below are used... o All these programs make for a quite fat initramfs and little use of klibc (libc6 and a bunch of other libraries will be pulled in). A hacked version of idmapd could possibly be written (the real one is about 1k lines of code) which always maps everything to root (since we are running in the initramfs context anyway), but I'm not so sure about the other tools. Changes to the klibc nfsmount also seem doable, but that leaves rpc.gssd and the kerberos tools. rpc.gssd might be simplified by the fact that for the root user it uses the machine credentials, but there is still a lot of code... -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396185: Status ?
What is the status of this bug ? It happens on my server too (2.6.18-5-amd64): kernel: sky2 v1.5 addr 0xddffc000 irq 169 Yukon-EC (0xb6)rev 2 kernel: sky2 eth0: Link is up at 100 Mbps, full duplex, flow control none ... kernel: sky2 status report lost? kernel: NETDEV WATCHDOG: eth0: transmit timed out kernel: sky2 eth0: tx timeout kernel: sky2 eth0: transmit ring 328 .. 287 report=329 done=329 $ ethtool -i eth0 driver: sky2 version: 1.5 firmware-version: N/A bus-info: :02:00.0 -- kiu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
Joey Hess writes ("Re: Bug#447611: update-initramfs triggerisation"):
> Ian Jackson wrote:
> Content-Description: message body text
> > + && test x"$DPKG_MAINTSCRIPT_PACKAGE" != x \
>
> I take it that this is a magic flag variable set by dpkg when running a
> postinst?
Yes. This is a new feature introduced in the triggers patch, so I'm
afraid you can't rely on it yet in general.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
On Tue, Oct 23, 2007 at 01:45:46AM -0700, Steve Langasek wrote: > On Mon, Oct 22, 2007 at 06:12:44PM +0200, maximilian attems wrote: > > i'm following dpkg git, once this cool feature is merged, > > i'm happy to apply a patch using it. i didn't see it merged in > > the master tree yet. as i didn't follow the dpkg discsussions > > i don't know current status. > > Why should that be a prerequisite for merging these changes for > initramfs-tools? Reducing the diff between the Debian and Ubuntu packages > of initramfs-tools will make it easier to pass bugfixes between the two > distros for this package, and I don't see any reason to think this code will > make initramfs-tools less maintainable, so it seems like a good idea to me > to merge this change even if it's not yet useful in Debian. it is a prerequisite, until not merged i have zero evidence that the interface may not have changed. afais on dpkg devel joeyh raised good critics on how the trigger support is done. i agree that i like to keep the diff small and current shape of initramfs-tools would be cool for a merge in the next weeks. > > > + dpkg --compare-versions "$DPKG_RUNNING_VERSION" ge '1.14.5ubuntu10~~' > > > +then > > ubuntu specific, would with high probab trigger on the wrong versions, > > also why is this needed? > > but the previous bit of code says that this only fires when the maintainer > script is called with "trigger" as the first argument. As there aren't any > older versions of dpkg in Debian that will ever call the maintainer scripts > this way, that seems reasonable to me? ok > Hmm, installing files into the DEBIAN/ directory using dh_install -- eew? > :-) > > Anyway, Joey's solution is better. yup, what's the invocation? > $ type test > test is a shell builtin > $ > > ? thanks for the lection, forgot that differs from current codingstyle, so i prefer the way i said and i don't like the getopt parsing ;) > I'm glad to hear it, I'd very much like to see Debian able to take advantage > of these speed-ups soon. :) full ack -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
On Mon, Oct 22, 2007 at 06:12:44PM +0200, maximilian attems wrote:
> i'm following dpkg git, once this cool feature is merged,
> i'm happy to apply a patch using it. i didn't see it merged in
> the master tree yet. as i didn't follow the dpkg discsussions
> i don't know current status.
Why should that be a prerequisite for merging these changes for
initramfs-tools? Reducing the diff between the Debian and Ubuntu packages
of initramfs-tools will make it easier to pass bugfixes between the two
distros for this package, and I don't see any reason to think this code will
make initramfs-tools less maintainable, so it seems like a good idea to me
to merge this change even if it's not yet useful in Debian.
> > + dpkg --compare-versions "$DPKG_RUNNING_VERSION" ge '1.14.5ubuntu10~~'
> > +then
> ubuntu specific, would with high probab trigger on the wrong versions,
> also why is this needed?
but the previous bit of code says that this only fires when the maintainer
script is called with "trigger" as the first argument. As there aren't any
older versions of dpkg in Debian that will ever call the maintainer scripts
this way, that seems reasonable to me?
> has there been a buggy dpkg trigger support!?
Should that matter, given that any versions of dpkg with that bug are, as
you say, Ubuntu-specific? :)
> > diff -ruN ../orig/initramfs-tools-0.85eubuntu16/debian/rules
> > initramfs-tools-0.85eubuntu18/debian/rules
> > --- ../orig/initramfs-tools-0.85eubuntu16/debian/rules 2006-12-21
> > 23:32:07.0 +
> > +++ initramfs-tools-0.85eubuntu18/debian/rules 2007-08-16
> > 16:10:49.0 +0100
> > @@ -8,3 +8,7 @@
> > for x in `find scripts/ -maxdepth 1 -type d | tail -n+2`; do \
> > chmod -R +x $$x; \
> > done
> > +
> > +binary-install/initramfs-tools::
> > + install -m 644 -o 0 -g 0 debian/initramfs-tools.triggers \
> > + debian/initramfs-tools/DEBIAN/triggers
> no i-t uses cdbs,
> please add to debian/initramfs-tools.install
Hmm, installing files into the DEBIAN/ directory using dh_install -- eew?
:-)
Anyway, Joey's solution is better.
> but maybe i misread and there is no cdbs support for that yet??
> > diff -ruN ../orig/initramfs-tools-0.85eubuntu16/update-initramfs
> > initramfs-tools-0.85eubuntu18/update-initramfs
> > --- ../orig/initramfs-tools-0.85eubuntu16/update-initramfs 2007-04-10
> > 16:07:41.0 +0100
> > +++ initramfs-tools-0.85eubuntu18/update-initramfs 2007-08-16
> > 16:56:23.0 +0100
> > @@ -4,11 +4,24 @@
> > BOOTDIR=/boot
> > CONF=/etc/initramfs-tools/update-initramfs.conf
> > KPKGCONF=/etc/kernel-img.conf
> > +USETRIGGERS=true
> >
> > set -e
> >
> > [ -r ${CONF} ] && . ${CONF}
> >
> > +if$USETRIGGERS \
> > + && test x"$DPKG_MAINTSCRIPT_PACKAGE" != x \
> > + && test $# = 1 \
> > + && test x"$1" = x-u \
> > + && dpkg-trigger --check-supported 2>/dev/null
> why not using built-ins?
$ type test
test is a shell builtin
$
?
> don't get me wrong, i highly like the idea of that work
> and i'm happy to use it soon.
I'm glad to hear it, I'd very much like to see Debian able to take advantage
of these speed-ups soon. :)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
On Mon, 22 Oct 2007, Joey Hess wrote: > maximilian attems wrote: > > no i-t uses cdbs, > > please add to debian/initramfs-tools.install > > but maybe i misread and there is no cdbs support for that yet?? > > More simply, debhelper supports it as of version 5.0.59. hmmm with all due respect cdbs is simpler to use. cool i'd hope cdbs uses debhelper support otherwise that bug needs to be cloned. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 447682
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.9.26 > tags 447682 + pending Bug#447682: linux-2.6: please package new upstream version (2.6.23) There were no tags set. Tags added: pending > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#447682: RFP: linux-source-2.6.23 needed
Processing commands for [EMAIL PROTECTED]: > reassign 447682 linux-2.6 Bug#447682: linux-2.6: please package new upstream version (2.6.23) Bug reassigned from package `linux-2.6' to `linux-2.6'. > -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
