Re: release notes mentioning dropped support?
Hi Kernel team, Last release I sent out the message below and in the end we included something [1] in the Release Notes mentioning dropped support. Is there something like that worth mentioning this time around? Paul [1] https://www.debian.org/releases/bullseye/armel/release-notes/ch-information.en.html#no-longer-supported-hardware On 24-05-2021 06:55, Paul Gevers wrote: Hi Kernel team, I happen to own a QNAP (armel) and I spotted in the changelog that it's not going to be supported in bullseye. I was wondering, is that something that should be mentioned in the release notes? Obviously I don't mean because I own it, but I'm betting that support for particular hardware pieces has been dropped in the past too. I don't recall something like that in the buster release notes, but even if we didn't do it in the past, now could be a good moment to start if we think we should add it. Either way, I was wondering what would happen if I try to upgrade such a device. I'm *assuming* that the linux package would detect that the image is too big, but what would that leave me? A fully upgraded system with an old kernel, or is there any detection before any upgrade happens? For owners of such devices, is their only option to stay at buster? E.g. is there any chance in building a smaller custom kernel with less options enabled or is that impossible because nearly everything is build as module? Paul OpenPGP_signature Description: OpenPGP digital signature
Re: release notes mentioning dropped support?
wOn Mon, 2021-06-14 at 06:25 +0100, Justin B Rye wrote: > Paul Gevers wrote: > > + > > + Hardware that's no longer supported > > The contraction "that's" seems out of place in a title - probably we > should just use: > > No longer supported hardware > That would correctly be spelt with hyphens: No-longer-supported hardware > > + > > + Due to hardware limitations, it's no longer viable for Debian > > + to build the Linux kernel supporting a > > + number of armel based devices that were supported in > > + buster. The unsupported devices are: > > This sounds as if it's talking about one kernel supporting multiple > armel-based devices; if it means one kernel per device, that's plural. We've used only a single kernel flavour (marvell) for these devices since before the stretch release. [...] > > + Users of those platforms that wish to upgrade to bullseye > > + nevertheless should keep the buster APT sources enabled and, > > + before upgrading, add an APT preferences file containing > > + something like: > > Users of these platforms who wish to upgrade to bullseye > nevertheless should keep the buster APT sources enabled, and > before upgrading should add an APT preferences file containing > something like: > > (Or maybe as two sentences, "Before upgrading they should...") Also we should not say "something like" since that suggests that some system-specific adjustment is needed. I originally included those words because I hadn't tested this configuration, but Paul said he will. > > > + > > +Package: linux-image-marvell > > +Pin: release a=buster > > +Pin-Priority: 900 > > + > > + Obviously, the security support for this configuration will > > + end with the End Of Life of buster. > > Obviously, the security support for this configuration will > only last until buster's End Of Life. We (generally) shouldn't say "obviously" in documentation - if we bothered to document it, it must not be that obvious. Ben. -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part
Re: release notes mentioning dropped support?
Paul Gevers wrote: > + > + Hardware that's no longer supported The contraction "that's" seems out of place in a title - probably we should just use: No longer supported hardware > + > + Due to hardware limitations, it's no longer viable for Debian > + to build the Linux kernel supporting a > + number of armel based devices that were supported in > + buster. The unsupported devices are: This sounds as if it's talking about one kernel supporting multiple armel-based devices; if it means one kernel per device, that's plural. Due to hardware limitations, it's no longer viable for Debian to build the Linux kernels supporting a number of armel-based devices that were supported in buster. The unsupported devices are: Or maybe: For a number of armel-based devices that were supported in buster, it is no longer viable for Debian to build the required Linux kernels, due to hardware limitations. The unsupported devices are: > + > + > + > + > + QNAP TS-109/TS-209, TS-119/TS-219 and TS-409 > + > + > + > + > + HP Media Vault mv2120 > + > + > + > + > + Users of those platforms that wish to upgrade to bullseye > + nevertheless should keep the buster APT sources enabled and, > + before upgrading, add an APT preferences file containing > + something like: Users of these platforms who wish to upgrade to bullseye nevertheless should keep the buster APT sources enabled, and before upgrading should add an APT preferences file containing something like: (Or maybe as two sentences, "Before upgrading they should...") > + > +Package: linux-image-marvell > +Pin: release a=buster > +Pin-Priority: 900 > + > + Obviously, the security support for this configuration will > + end with the End Of Life of buster. Obviously, the security support for this configuration will only last until buster's End Of Life. > + > + > > > -- > 2.30.2 > -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Re: release notes mentioning dropped support?
Hi all, Proposed text for the release notes attached. On 11-06-2021 21:47, Ben Hutchings wrote: > On Sat, 2021-06-12 at 03:01 +0900, Roger Shimizu wrote: >> On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso >> wrote: >>> On Thu, Jun 10, 2021 at 11:32:23AM +0200, Paul Gevers wrote: On 24-05-2021 06:55, Paul Gevers wrote: > I happen to own a QNAP (armel) and I spotted in the changelog that it's > not going to be supported in bullseye. I was wondering, is that > something that should be mentioned in the release notes? Obviously I > don't mean because I own it, but I'm betting that support for particular > hardware pieces has been dropped in the past too. I don't recall > something like that in the buster release notes, but even if we didn't > do it in the past, now could be a good moment to start if we think we > should add it. >> >> for armel, the limitation is by: >> https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/armel/defines#L35 >> >> And from the list in that file, below devices are not supported now. >> # QNAP TS-119/TS-219: 2097152 - 64 = 2097088 >> # D-Link DNS-323: 1572864 - 8 - 64 = 1572792 (too small, no longer supported) >> # HP Media Vault mv2120: 2097152 - 8 - 64 = 2097080 >> # QNAP TS-109/TS-209 & TS-409: 2097152 - 8 - 64 = 2097080 >> >> I guess support for D-Link DNS-323 was dropped since buster, or earlier. > > Yes, since stretch. > >> > Either way, I was wondering what would happen if I try to upgrade such a > device. I'm *assuming* that the linux package would detect that the > image is too big, but what would that leave me? A fully upgraded system > with an old kernel, or is there any detection before any upgrade > happens? For owners of such devices, is their only option to stay at > buster? E.g. is there any chance in building a smaller custom kernel > with less options enabled or is that impossible because nearly > everything is build as module? >> >> The upgrade of kernel may succeed if /boot still have enough space, >> but reboot will fail because of the uboot configuration hard coded in >> those hardware. > [...] > > My understanding is that these devices load the kernel and initramfs > from fixed partitions on the on-board flash, not from the filesystem. > That's why the limits vary. flash-kernel is responsible for copying > the kernel and initramfs to these partitions. When the kernel is too> > Ben. > > large, it will report an error, which should abort the package > installation. > > To avoid this, users should keep the buster sources enabled and, before > upgrading, add an APT preferences file containing something like: > > Package: linux-image-marvell > Pin: release a=buster > Pin-Priority: 900 > > (not tested). Obviously this will only work as long as buster is > supported. As I own one of the unsupported devices, I intend to check if this works as intended and I'll not push the change until confirmed. If I'm really brave, I'll even check that flash-kernel errors out in the right way. Paul From a58174c17ad3b6cdb19f4e908428f0b0e8bf53c3 Mon Sep 17 00:00:00 2001 From: Paul Gevers Date: Sun, 13 Jun 2021 21:30:33 +0200 Subject: [PATCH] issues.dbk: unsupported armel hardware --- en/issues.dbk | 34 ++ 1 file changed, 34 insertions(+) diff --git a/en/issues.dbk b/en/issues.dbk index 805a15be..01184f9a 100644 --- a/en/issues.dbk +++ b/en/issues.dbk @@ -775,5 +775,39 @@ Environment=SYSTEMD_SULOGIN_FORCE=1 + + Hardware that's no longer supported + + Due to hardware limitations, it's no longer viable for Debian + to build the Linux kernel supporting a + number of armel based devices that were supported in + buster. The unsupported devices are: + + + + + QNAP TS-109/TS-209, TS-119/TS-219 and TS-409 + + + + + HP Media Vault mv2120 + + + + + Users of those platforms that wish to upgrade to bullseye + nevertheless should keep the buster APT sources enabled and, + before upgrading, add an APT preferences file containing + something like: + +Package: linux-image-marvell +Pin: release a=buster +Pin-Priority: 900 + + Obviously, the security support for this configuration will + end with the End Of Life of buster. + + -- 2.30.2 OpenPGP_signature Description: OpenPGP digital signature
Re: release notes mentioning dropped support?
On Sat, 2021-06-12 at 03:01 +0900, Roger Shimizu wrote: > On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso > wrote: > > > > Hi, > > > > On Thu, Jun 10, 2021 at 11:32:23AM +0200, Paul Gevers wrote: > > > Hi Kernel team, > > > > > > I know everybody is busy, but friendly ping. > > > > > > On 24-05-2021 06:55, Paul Gevers wrote: > > > > I happen to own a QNAP (armel) and I spotted in the changelog that it's > > > > not going to be supported in bullseye. I was wondering, is that > > > > something that should be mentioned in the release notes? Obviously I > > > > don't mean because I own it, but I'm betting that support for particular > > > > hardware pieces has been dropped in the past too. I don't recall > > > > something like that in the buster release notes, but even if we didn't > > > > do it in the past, now could be a good moment to start if we think we > > > > should add it. > > for armel, the limitation is by: > https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/armel/defines#L35 > > And from the list in that file, below devices are not supported now. > # QNAP TS-119/TS-219: 2097152 - 64 = 2097088 > # D-Link DNS-323: 1572864 - 8 - 64 = 1572792 (too small, no longer supported) > # HP Media Vault mv2120: 2097152 - 8 - 64 = 2097080 > # QNAP TS-109/TS-209 & TS-409: 2097152 - 8 - 64 = 2097080 > > I guess support for D-Link DNS-323 was dropped since buster, or earlier. Yes, since stretch. > > > > > Either way, I was wondering what would happen if I try to upgrade such a > > > > device. I'm *assuming* that the linux package would detect that the > > > > image is too big, but what would that leave me? A fully upgraded system > > > > with an old kernel, or is there any detection before any upgrade > > > > happens? For owners of such devices, is their only option to stay at > > > > buster? E.g. is there any chance in building a smaller custom kernel > > > > with less options enabled or is that impossible because nearly > > > > everything is build as module? > > The upgrade of kernel may succeed if /boot still have enough space, > but reboot will fail because of the uboot configuration hard coded in > those hardware. [...] My understanding is that these devices load the kernel and initramfs from fixed partitions on the on-board flash, not from the filesystem. That's why the limits vary. flash-kernel is responsible for copying the kernel and initramfs to these partitions. When the kernel is too large, it will report an error, which should abort the package installation. To avoid this, users should keep the buster sources enabled and, before upgrading, add an APT preferences file containing something like: Package: linux-image-marvell Pin: release a=buster Pin-Priority: 900 (not tested). Obviously this will only work as long as buster is supported. Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Re: release notes mentioning dropped support?
Hi Roger, Thanks for the reply, On 11-06-2021 20:01, Roger Shimizu wrote: > On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso > wrote: >>> On 24-05-2021 06:55, Paul Gevers wrote: I happen to own a QNAP (armel) and I spotted in the changelog that it's not going to be supported in bullseye. I was wondering, is that something that should be mentioned in the release notes? Obviously I don't mean because I own it, but I'm betting that support for particular hardware pieces has been dropped in the past too. I don't recall something like that in the buster release notes, but even if we didn't do it in the past, now could be a good moment to start if we think we should add it. > > for armel, the limitation is by: > https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/armel/defines#L35 > > And from the list in that file, below devices are not supported now. > # QNAP TS-119/TS-219: 2097152 - 64 = 2097088 > # D-Link DNS-323: 1572864 - 8 - 64 = 1572792 (too small, no longer supported) > # HP Media Vault mv2120: 2097152 - 8 - 64 = 2097080 > # QNAP TS-109/TS-209 & TS-409: 2097152 - 8 - 64 = 2097080 > > I guess support for D-Link DNS-323 was dropped since buster, or earlier. I found this part earlier indeed. I was mostly wondering what we did in the past (maybe nothing) and if we should mention it. Reading below, I think we should. Do the other architectures have similar devices where support is dropped, or is this specific for armel? Either way, I was wondering what would happen if I try to upgrade such a device. I'm *assuming* that the linux package would detect that the image is too big, but what would that leave me? A fully upgraded system with an old kernel, or is there any detection before any upgrade happens? For owners of such devices, is their only option to stay at buster? E.g. is there any chance in building a smaller custom kernel with less options enabled or is that impossible because nearly everything is build as module? > > The upgrade of kernel may succeed if /boot still have enough space, > but reboot will fail because of the uboot configuration hard coded in > those hardware. > It's possible to update the uboot configuration, but if something is > wrong, it may brick the device, and no easy way to recover, except you > the device support serial or JTAG, and you have serial or JTAG cable. Ouch. This sounds bad. And nothing is protecting the user against this? Wouldn't it be possible/wise to have a check in preinst and abort the upgrade in such cases? To protect the user from ending in such a state? > Of course, remove some unused built-in module and rebuild own kernel > is always an option. Good to know. I wasn't sure if the Debian Linux kernel was built lean with everything available as modules. > But it need continuous effort, for stable / security kernel updates. Sure. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: release notes mentioning dropped support?
On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso wrote: > > Hi, > > On Thu, Jun 10, 2021 at 11:32:23AM +0200, Paul Gevers wrote: > > Hi Kernel team, > > > > I know everybody is busy, but friendly ping. > > > > On 24-05-2021 06:55, Paul Gevers wrote: > > > I happen to own a QNAP (armel) and I spotted in the changelog that it's > > > not going to be supported in bullseye. I was wondering, is that > > > something that should be mentioned in the release notes? Obviously I > > > don't mean because I own it, but I'm betting that support for particular > > > hardware pieces has been dropped in the past too. I don't recall > > > something like that in the buster release notes, but even if we didn't > > > do it in the past, now could be a good moment to start if we think we > > > should add it. for armel, the limitation is by: https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/armel/defines#L35 And from the list in that file, below devices are not supported now. # QNAP TS-119/TS-219: 2097152 - 64 = 2097088 # D-Link DNS-323: 1572864 - 8 - 64 = 1572792 (too small, no longer supported) # HP Media Vault mv2120: 2097152 - 8 - 64 = 2097080 # QNAP TS-109/TS-209 & TS-409: 2097152 - 8 - 64 = 2097080 I guess support for D-Link DNS-323 was dropped since buster, or earlier. > > > Either way, I was wondering what would happen if I try to upgrade such a > > > device. I'm *assuming* that the linux package would detect that the > > > image is too big, but what would that leave me? A fully upgraded system > > > with an old kernel, or is there any detection before any upgrade > > > happens? For owners of such devices, is their only option to stay at > > > buster? E.g. is there any chance in building a smaller custom kernel > > > with less options enabled or is that impossible because nearly > > > everything is build as module? The upgrade of kernel may succeed if /boot still have enough space, but reboot will fail because of the uboot configuration hard coded in those hardware. It's possible to update the uboot configuration, but if something is wrong, it may brick the device, and no easy way to recover, except you the device support serial or JTAG, and you have serial or JTAG cable. Of course, remove some unused built-in module and rebuild own kernel is always an option. But it need continuous effort, for stable / security kernel updates. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: release notes mentioning dropped support?
Hi, On Thu, Jun 10, 2021 at 11:32:23AM +0200, Paul Gevers wrote: > Hi Kernel team, > > I know everybody is busy, but friendly ping. > > On 24-05-2021 06:55, Paul Gevers wrote: > > I happen to own a QNAP (armel) and I spotted in the changelog that it's > > not going to be supported in bullseye. I was wondering, is that > > something that should be mentioned in the release notes? Obviously I > > don't mean because I own it, but I'm betting that support for particular > > hardware pieces has been dropped in the past too. I don't recall > > something like that in the buster release notes, but even if we didn't > > do it in the past, now could be a good moment to start if we think we > > should add it. > > > > Either way, I was wondering what would happen if I try to upgrade such a > > device. I'm *assuming* that the linux package would detect that the > > image is too big, but what would that leave me? A fully upgraded system > > with an old kernel, or is there any detection before any upgrade > > happens? For owners of such devices, is their only option to stay at > > buster? E.g. is there any chance in building a smaller custom kernel > > with less options enabled or is that impossible because nearly > > everything is build as module? Let's explicitly ask the "porters" for arm as listed in (kernel-teamMAINTAINERS.Debian), Vagrant, Uwe, Roger, anyone from you can comment on the above on how to document it? Regards, Salvatore
Re: release notes mentioning dropped support?
Hi Kernel team, I know everybody is busy, but friendly ping. On 24-05-2021 06:55, Paul Gevers wrote: > I happen to own a QNAP (armel) and I spotted in the changelog that it's > not going to be supported in bullseye. I was wondering, is that > something that should be mentioned in the release notes? Obviously I > don't mean because I own it, but I'm betting that support for particular > hardware pieces has been dropped in the past too. I don't recall > something like that in the buster release notes, but even if we didn't > do it in the past, now could be a good moment to start if we think we > should add it. > > Either way, I was wondering what would happen if I try to upgrade such a > device. I'm *assuming* that the linux package would detect that the > image is too big, but what would that leave me? A fully upgraded system > with an old kernel, or is there any detection before any upgrade > happens? For owners of such devices, is their only option to stay at > buster? E.g. is there any chance in building a smaller custom kernel > with less options enabled or is that impossible because nearly > everything is build as module? Paul OpenPGP_signature Description: OpenPGP digital signature
Re: release-notes for buster and the kernel
Dear kernel team, I hope I didn't miss your response, but AFAICT the request below is still open. A reply like "no, there is no need for any specifics" is also very welcome. On 06-04-2019 21:50, Paul Gevers wrote: > Dear kernel team, > > I am reaching out to you as I help to coordinate this release's > release-notes. In most release-notes in the past, there have been words > about the kernel. For buster, is there anything that is worth mentioning > in the notes? > > We already mention that AppArmor is pulled in via Recommends. In case > you want to check what's there, you can find the current draft here: > https://www.debian.org/releases/buster/releasenotes > and the source of it here (merge requests welcome): > https://salsa.debian.org/ddp-team/release-notes/ Paul signature.asc Description: OpenPGP digital signature
Re: release notes
* dann frazier ([EMAIL PROTECTED]) [061115 01:47]: I've updated the text in svn, and added some more to help with a couple of the open bugs in your list. I would really appreciate it if others from the kernel team could review it for accuracy, especially the initramfs-tools/yaird stuff. Another question: What is the recommended installation order for this upgrade? We have different variants: From 2.2, 2.4 or 2.6-kernels (where we have different default kernel versions on different arches)? First packages, then kernel? Or first kernel? Or kernel first if it is 2.2 or 2.4, otherwise packages first? Or ...? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: release notes
* dann frazier ([EMAIL PROTECTED]) [061115 01:47]: aba: Let me know if you need any help incorporating this text, and once its merged, let me know so that I can kill off the version in svn. I know merge it to the release notes (should be visible with the next build). There are two changes I didn't merge: | arch=s390 | [waldi it needs documentation about the new s390 hardware configuration] | /arch This one is IMHO already part of bug #360582: s390 network. Waldi, when can we expect updates from you on that bug? | arch=ia64 | For example, an rx1600 with a single built-in serial port plus | an MP has these ports: |Old Old | MMIO (EFI console(EFI console | addresson builtin) on MP port) New | -- - | builtin 0xff5ettyS0 ttyS1 ttyS0 | MP UPS 0xf8031000ttyS1 ttyS2 ttyS1 | MP Console 0xf803ttyS2 ttyS0 ttyS2 | MP 20xf8030010ttyS3 ttyS3 ttyS3 | MP 30xf8030038ttyS4 ttyS4 ttyS4 I don't think we need this detailed level on the release notes. If we should have more details then we have now (and I even believe now it is already too detailed), one should create an extra document / wiki page / whatever, and we could cross-reference. About the open kernel-related bug reports: | #383982: release-notes: Describe replace of kernel-image package with | linux-image package has happened now. | #271315: kernel-image-2.6.8-1-sparc64: sun keyboard unusable does this bug affect us at all now? If so, we need some more input. | #341225: Etch: Upgrade path from devfs to udev needs documenting This should be also done now. | #325568: Upgrade path for udev needs documenting This has not happened yet, and also, it seems the answer in which order should the upgrade happen is related to that. | #343892: Should document NIC naming issue with udev This should be done now. | #395174: linux-2.6: Dell CERC ATA100/4ch with F/W 6.61 not supported in etch We need more info on that I think. | #360582: s390 network open, see above. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: release notes
On Wed, Nov 15, 2006 at 12:06:52PM +0100, Andreas Barth wrote: * dann frazier ([EMAIL PROTECTED]) [061115 01:47]: I've updated the text in svn, and added some more to help with a couple of the open bugs in your list. I would really appreciate it if others from the kernel team could review it for accuracy, especially the initramfs-tools/yaird stuff. Another question: What is the recommended installation order for this upgrade? We have different variants: From 2.2, 2.4 or 2.6-kernels (where we have different default kernel versions on different arches)? First packages, then kernel? Or first kernel? Or kernel first if it is 2.2 or 2.4, otherwise packages first? Or ...? I don't know of any issues with upgrading everything (in any order) before rebooting. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: release notes
On Tue, Nov 14, 2006 at 06:10:12PM +0100, Andreas Barth wrote: Hi, I have read the kernel release notes, and think we should put them into the regular release notes now. Fine by me, given no updates have been made since my first draft :( Should I just mark-up what we have now and send you a patch? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: release notes
* dann frazier ([EMAIL PROTECTED]) [061114 18:48]: On Tue, Nov 14, 2006 at 06:10:12PM +0100, Andreas Barth wrote: I have read the kernel release notes, and think we should put them into the regular release notes now. Fine by me, given no updates have been made since my first draft :( Should I just mark-up what we have now and send you a patch? Well, the problem is not as much to get the text from svn (I looked at it earlier today, but working on text for a few hours is a bit tiring for me), but rather to fill in the places unanswered so far. But perhaps you can give the text some final love from your side, and send it to me? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: release notes
On Tue, Nov 14, 2006 at 06:51:27PM +0100, Andreas Barth wrote: * dann frazier ([EMAIL PROTECTED]) [061114 18:48]: On Tue, Nov 14, 2006 at 06:10:12PM +0100, Andreas Barth wrote: I have read the kernel release notes, and think we should put them into the regular release notes now. Fine by me, given no updates have been made since my first draft :( Should I just mark-up what we have now and send you a patch? Well, the problem is not as much to get the text from svn (I looked at it earlier today, but working on text for a few hours is a bit tiring for me), but rather to fill in the places unanswered so far. But perhaps you can give the text some final love from your side, and send it to me? I've updated the text in svn, and added some more to help with a couple of the open bugs in your list. I would really appreciate it if others from the kernel team could review it for accuracy, especially the initramfs-tools/yaird stuff. aba: Let me know if you need any help incorporating this text, and once its merged, let me know so that I can kill off the version in svn. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
