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

Groups > linux.debian.kernel > #90600 > unrolled thread

Bug#1009106: Now missing kernel module blocklayoutdriver

Back to article view | Back to linux.debian.kernel

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#1009106: Now missing kernel module blocklayoutdriver Andrei POPESCU <andreimpopescu@gmail.com> - 2025-12-29 12:00 +0100
    Bug#1009106: Now missing kernel module blocklayoutdriver Salvatore Bonaccorso <carnil@debian.org> - 2025-12-29 22:10 +0100
      Bug#1009106: Now missing kernel module blocklayoutdriver Andrei POPESCU <andreimpopescu@gmail.com> - 2025-12-30 11:30 +0100
        Bug#1009106: Now missing kernel module blocklayoutdriver Salvatore Bonaccorso <carnil@debian.org> - 2026-01-14 18:10 +0100
          Bug#1009106: Now missing kernel module blocklayoutdriver Andrei POPESCU <andreimpopescu@gmail.com> - 2026-01-15 09:10 +0100

#90600 — Bug#1009106: Now missing kernel module blocklayoutdriver

Package: nfs-common
Version: 1:2.8.4-1
Followup-For: Bug #1009106
X-Debbugs-Cc: andreimpopescu@gmail.com

Hi,

In trixie and current sid the paths are correct, but apparently
the kernel module 'blocklayoutdriver' must be loaded before
attempting to start nfs-blkmap.service.

I could verify the error disappears if loading the module manually
(e.g. by booting in rescue mode).

Kind regards,
Andrei

[toc] | [next] | [standalone]

#90604

Hi Andrei,

On Mon, Dec 29, 2025 at 11:26:26AM +0100, Andrei POPESCU wrote:
> Package: nfs-common
> Version: 1:2.8.4-1
> Followup-For: Bug #1009106
> X-Debbugs-Cc: andreimpopescu@gmail.com
> 
> Hi,
> 
> In trixie and current sid the paths are correct, but apparently
> the kernel module 'blocklayoutdriver' must be loaded before
> attempting to start nfs-blkmap.service.
> 
> I could verify the error disappears if loading the module manually
> (e.g. by booting in rescue mode).

Please note that the service is not failing:

● nfs-blkmap.service - pNFS block layout mapping daemon
     Loaded: loaded (/usr/lib/systemd/system/nfs-blkmap.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-29 21:24:36 CET; 13min ago
 Invocation: a675909952d447de985b7adcce301b3a
       Docs: man:blkmapd(8)
    Process: 801 ExecStart=/usr/sbin/blkmapd (code=exited, status=0/SUCCESS)
   Main PID: 812 (blkmapd)
      Tasks: 1 (limit: 4674)
     Memory: 384K (peak: 2M)
        CPU: 4ms
     CGroup: /system.slice/nfs-blkmap.service
             └─812 /usr/sbin/blkmapd


Dec 29 21:24:36 sid systemd[1]: Starting nfs-blkmap.service - pNFS block layout mapping daemon...
Dec 29 21:24:36 sid blkmapd[812]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory
Dec 29 21:24:36 sid systemd[1]: Started nfs-blkmap.service - pNFS block layout mapping daemon.

but right the message can be irritating.

As we do not really want to diverge from upstream I will see with them
how we could improve the user experience here, either making it more
clear that when PNFS_BLOCK is enabled as module, the blocklayoutdriver
needs to be enabled, making the service only start as you suggested if
the blocklayoutdriver is loaded and the rpc file present, clearer
documentation or something else.

Regards,
Salvatore

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

#90612

On Mon, 29 Dec 2025 at 21:42, Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> As we do not really want to diverge from upstream I will see with them
> how we could improve the user experience here, either making it more
> clear that when PNFS_BLOCK is enabled as module, the blocklayoutdriver
> needs to be enabled, making the service only start as you suggested if
> the blocklayoutdriver is loaded and the rpc file present, clearer
> documentation or something else.

Interestingly nfs.systemd(7) suggests nfs-blkmap.service needs to be
enabled when required, so maybe it should be shipped disabled instead?

Kind regards,
Andrei

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

#90808

Contol: tags -1 confirmed

Hi Andrei,

On Tue, Dec 30, 2025 at 11:19:05AM +0100, Andrei POPESCU wrote:
> On Mon, 29 Dec 2025 at 21:42, Salvatore Bonaccorso <carnil@debian.org> wrote:
> >
> > As we do not really want to diverge from upstream I will see with them
> > how we could improve the user experience here, either making it more
> > clear that when PNFS_BLOCK is enabled as module, the blocklayoutdriver
> > needs to be enabled, making the service only start as you suggested if
> > the blocklayoutdriver is loaded and the rpc file present, clearer
> > documentation or something else.
> 
> Interestingly nfs.systemd(7) suggests nfs-blkmap.service needs to be
> enabled when required, so maybe it should be shipped disabled instead?

I asked upstream (see the forwarded reference), and as the blocklayout
is deprecated and only that one needs blkmapd, the approach will
acutally be to wait that
https://lore.kernel.org/linux-nfs/20260114145435.826165-1-smayhew@redhat.com/
lands, and then we will not ship blkmapd anymore.

I could in theory already now pass --disable=nfsv41, which only
purpose is to enable blkmapd, but I think it is not urgent that we
should not wait to have this landed and get blkmapd away.

It will be a good target to get it away for the forky release and we
have enough exposure until then to see if there is actually someone
complaining about the lost blkmapd.

Regards,
Salvatore

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

#90812

On Wed, 14 Jan 2026 at 18:07, Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> I asked upstream (see the forwarded reference), and as the blocklayout
> is deprecated and only that one needs blkmapd, the approach will
> acutally be to wait that
> https://lore.kernel.org/linux-nfs/20260114145435.826165-1-smayhew@redhat.com/
> lands, and then we will not ship blkmapd anymore.
>
> I could in theory already now pass --disable=nfsv41, which only
> purpose is to enable blkmapd, but I think it is not urgent that we
> should not wait to have this landed and get blkmapd away.
>
> It will be a good target to get it away for the forky release and we
> have enough exposure until then to see if there is actually someone
> complaining about the lost blkmapd.

Sounds good to me, FWIW.

Kind regards,
Andrei

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web