Re: Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues
Petter Reinholdtsen p...@hungry.com writes: [Goswin von Brederlow] There is one big problem with an event based startup. Specifically for raid1/4/5/6 devices. Those you can use just fine with missing devices but the boot should really wait for all device to be present. This problem is not specific for event based startup. It also exist with the current sequence based boot system. There are heaps of setups that fail to boot because the required are missing when the init.d script using them are running during boot. The only known solution today is to add a long delay during boot to try to increase the chance of having all devices available when they are needed. :( The big question is how long do you wait? Please, for the love of everything sane, ask a low priority debconf question with a default of five minutes[1] — and display a note in the initramfs about what you are waiting for, and how long. (Actually, the countdown from the DRBD init script, including the prompt to override the configured wait time, would be absolutely wonderful to have here, since it gives excellent feedback, a good UI to bypass things, and is generally quite informative.) How do you detect that a device is actually broken/missing and its event will never come? You can't even check if there are any pending events (udev-settle) because the device might be slow to start (e.g. a disk on a SATA port multiplier or SCSI with delayed spin up or external enclosures) and no event has yet been initialized for it. Yeah. With the current Linux kernel, I am not aware of any way to answer these questions. :( You can't answer them, ever, for some busses: there is no possible way to determine that you have completed enumeration of a USB bus. ATAoE, and iSCSI present similar problems. It just can't be done. So, eventually you have to accept that you either wait, or give up, for as long as the owner of the machine will accept. (Especially if what you are waiting for is, oh, the second machine in your DRBD pair to boot. Not that I have an agenda or anything. ;) Daniel Footnotes: [1] Long enough for most things to boot, short enough that an admin who can't read will not go entirely crazy waiting. -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hlgtznm@rimspace.net
Re: Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues
Goswin von Brederlow goswin-...@web.de writes: Daniel Pittman dan...@rimspace.net writes: Petter Reinholdtsen p...@hungry.com writes: [Goswin von Brederlow] [... waiting for enough devices to show up ...] The only known solution today is to add a long delay during boot to try to increase the chance of having all devices available when they are needed. :( The big question is how long do you wait? Please, for the love of everything sane, ask a low priority debconf question with a default of five minutes[1] — and display a note in the initramfs about what you are waiting for, and how long. For most people that is about 4 minutes and 30 seconds too long. And don't forget that this needs to be multiple times. Usualy once in the initramfs and once in the real system. But if devices are really multilayered you can end up having to do this for every layer. The multipath waits for both its paths. Then the raid waits for all its devices. Then the drbd waits for both its other hosts to boot. That is 15 minutes already in case of a bad error. *nod* (Actually, the countdown from the DRBD init script, including the prompt to override the configured wait time, would be absolutely wonderful to have here, since it gives excellent feedback, a good UI to bypass things, and is generally quite informative.) Which I think is a verry good compromise. As long as you have a keyboard to press ctrl-c. :) One small problem though. This requires that you know beforehand what devices to expect at all. It took me two tries to understand what you were saying here. Yes, that would be an issue, even if it can be solved in some cases. The waiting for is for the root device to show up, and what is happening is event-driven stuff is building — and, hopefully, eventually that creates the root device. So, either the system would need to document the path to the root device somewhere, and use that to drive the what we are waiting for next part, or you would need to treat that as a global timeout. The later would at least reduce it from one-wait-per-device worst case, I guess. ;) Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vd8z7tv7@rimspace.net
Re: Using a perl lib from postinst
Patrick Matthäi pmatth...@debian.org writes: Tollef Fog Heen schrieb: ]] Dominique Dumont | Since the postinst is a shell script, you cannot call directly the | perl lib. Postinsts can be written in any language, including perl, so he could just write it in perl and use the relevant module. Yep and what is with: #!/bin/sh # some foo to be inserted here perl -e -MMy::Module 'My::Module-do_something_nasty();' Er, it wasn't in Debian, but in a couple of bits of my private packaging I did something akin to that in order to use the debhelper shell script injected into the postinst easily. Given that one line of Perl was required it looked the nicer strategy, and less prone to break strangely if the debhelper shell code did something strange. Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: emacs23 uploaded to unstable
Rob Browning r...@defaultvalue.org writes: Rob Browning r...@defaultvalue.org writes: Daniel Moerner dmoer...@gmail.com writes: Thanks for packaging this, I think you mean: http://alioth.debian.org/~rlb/tmp/emacs23/ Daniel Yes, and thanks. I've just uploaded 23.1+1-2 which fixes some significant problems with 23.1+1-1. 403 Forbidden: You don't have permission to access /~rlb/tmp/emacs23/emacs23_23.1+1-2_i386.changes on this server. Regards, Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: emacs23 uploaded to unstable
Rob Browning r...@defaultvalue.org writes: I've uploaded the first emacs23 packages (23.1+1-1) to unstable. Please file bugs as appropriate. Note that we have also begun the process of removing emacs21 from unstable/testing. Thanks for packaging this. I grabbed the source packages you made available, built for amd64, and it emacs23-gtk presently working very nicely. Regards, Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: XEmacs/GTK 21.1.11
On 30 Aug 2000, Joachim Trinkwitz [EMAIL PROTECTED] wrote:
Juhapekka Tolvanen [EMAIL PROTECTED] writes:
I fear, that it will take so much time, that we must have separately
packaged XEmacs/Gtk meanwhile. And I fear, that latest upstream
sources of XEmacs will ship with too old version of XEmacs/Gtk. Just
check out, how old version of Gnus and Auctex ships with latest
XEmacs, if you don't believe me.
The strategy of the emacs{19|20} Debian packages, which have much more
separate lisp packages, though born of need, results in much fresher
modules and quicker update cycles, which would be nice to have for
XEmacs too (never mind my english, I hope you understand what I mean).
Maybe all those Debian packages like psgml, auctex, gnus etc. should
be made for XEmacs too.
For what it's worth, the latest packages update gnus and PSGML[1] in
XEmacs. Also, XEmacs/GTK just landed as a branch in the mainline CVS,
although the merge isn't yet done.
For what it's worth. I am not really a developer...
Daniel
Footnotes:
[1] At least; I don't use Auctex, so don't know about it.
--
What good is the Moon? You can't buy it or sell it.
-- Ivan F. Boesky
