Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.rc > #324166 > unrolled thread

Bug#864423: Software RAID is not activated at boot time

Back to article view | Back to linux.debian.bugs.rc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#864423: Software RAID is not activated at boot time Chris Hofstaedtler <zeha@debian.org> - 2022-07-30 19:30 +0200
    Bug#864423: Software RAID is not activated at boot time Cyril Brulebois <kibi@debian.org> - 2022-07-31 14:40 +0200
      Bug#864423: Software RAID is not activated at boot time Chris Hofstaedtler <zeha@debian.org> - 2022-08-03 01:50 +0200

#324166 — Bug#864423: Software RAID is not activated at boot time

Hi debian-boot,

* László Böszörményi (GCS) <gcs@debian.org> [220730 15:34]:
> On Sat, Jul 30, 2022 at 1:50 PM Chris Hofstaedtler <zeha@debian.org> wrote:
> > whats the status of dmraid? Do you have dmraid hardware or is this
> > merely on life-support?
>  Please note dmraid upstream is dead for more than ten years. I might
> find an old i386 hardware that needs it.
> But yes, it's only on life-support.

[..]

> > I'm wondering if we should remove dmraid support from the d-i as a
> > first step. AFAICT Intel Software RAID is supported by mdraid, not
> > sure if the other RAID platforms are still sold.
>  Sounds like a good idea. This will show users early Debian doesn't
> plan to ship it anymore.

I was digging around in the d-i code, and it appears for dmraid to
be invoked, one has to boot with disk-detect/dmraid/enable. 

I have opened merge requests to remove the dmraid/sataraid code from
d-i. The changes look like low risk to me, but obviously I have no
idea. For the lack of a build environment I also didn't test them.

Given d-i does nothing with dmraid unless the boot flag is present,
I want to ask if dmraid could also stop shipping its udeb, if thats
ok with debian-boot?

Thanks,
Chris

[toc] | [next] | [standalone]

#324244

[Multipart message — attachments visible in raw view] — view raw

Chris Hofstaedtler <zeha@debian.org> (2022-07-30):
> Hi debian-boot,
> 
> * László Böszörményi (GCS) <gcs@debian.org> [220730 15:34]:
> > On Sat, Jul 30, 2022 at 1:50 PM Chris Hofstaedtler <zeha@debian.org> wrote:
> > > whats the status of dmraid? Do you have dmraid hardware or is this
> > > merely on life-support?
> >  Please note dmraid upstream is dead for more than ten years. I might
> > find an old i386 hardware that needs it.
> > But yes, it's only on life-support.
> 
> [..]
> 
> > > I'm wondering if we should remove dmraid support from the d-i as a
> > > first step. AFAICT Intel Software RAID is supported by mdraid, not
> > > sure if the other RAID platforms are still sold.
> >  Sounds like a good idea. This will show users early Debian doesn't
> > plan to ship it anymore.
> 
> I was digging around in the d-i code, and it appears for dmraid to
> be invoked, one has to boot with disk-detect/dmraid/enable. 
> 
> I have opened merge requests to remove the dmraid/sataraid code from
> d-i. The changes look like low risk to me, but obviously I have no
> idea. For the lack of a build environment I also didn't test them.
> 
> Given d-i does nothing with dmraid unless the boot flag is present,
> I want to ask if dmraid could also stop shipping its udeb, if thats
> ok with debian-boot?

Given how specific it is, opt-in, on a specific arch, and dead upstream,
looks like a wholesale removal would be the best way forward, yes.

Thanks for digging into that.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#324400

[Multipart message — attachments visible in raw view] — view raw

Hi,

* Holger Wansing <hwansing@mailbox.org> [220802 23:37]:
> Cyril Brulebois <kibi@debian.org> wrote (Sun, 31 Jul 2022 14:31:20 +0200):
> > > I was digging around in the d-i code, and it appears for dmraid to
> > > be invoked, one has to boot with disk-detect/dmraid/enable. 
> > > 
> > > I have opened merge requests to remove the dmraid/sataraid code from
> > > d-i. The changes look like low risk to me, but obviously I have no
> > > idea. For the lack of a build environment I also didn't test them.
> > > 
> > > Given d-i does nothing with dmraid unless the boot flag is present,
> > > I want to ask if dmraid could also stop shipping its udeb, if thats
> > > ok with debian-boot?
> > 
> > Given how specific it is, opt-in, on a specific arch, and dead upstream,
> > looks like a wholesale removal would be the best way forward, yes.
> 
> I have merged the merge requests filed by Chris (partman-base, partman-auto,
> hw-detect, grub-installer).
> 
> The packages build fine with those changings.
> And a locally built mini.iso with those changings in local udebs also 
> installs fine (default install) in QEMU VM.

Great, thanks for testing!

Maybe these changes can make it into unstable soon?

I'm attaching a draft patch to drop udebs from src:dmraid. Maybe you
want to use this as a starting point, László?

I would also suggest keeping dmraid for one more release, and
putting something into the release notes. To keep dmraid, I think
the severity of this bug also might need adjusting, or something.

Thanks everyone for your helping hands.

Best,
Chris

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.rc

csiph-web