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

Groups > linux.debian.user > #219320 > unrolled thread

Unable to use Buster as an nfs client

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

Contents

  Unable to use Buster as an nfs client Mark Raynsford <list+org.debian@io7m.com> - 2020-02-22 14:10 +0100
    Re: Unable to use Buster as an nfs client Reco <recoverym4n@enotuniq.net> - 2020-02-22 14:50 +0100
      Re: Unable to use Buster as an nfs client Mark Raynsford <list+org.debian@io7m.com> - 2020-02-22 15:10 +0100
        Re: Unable to use Buster as an nfs client Reco <recoverym4n@enotuniq.net> - 2020-02-22 15:40 +0100
          Re: Unable to use Buster as an nfs client Mark Raynsford <list+org.debian@io7m.com> - 2020-02-22 15:50 +0100
            Re: Unable to use Buster as an nfs client rhkramer@gmail.com - 2020-02-22 16:30 +0100
              Re: Unable to use Buster as an nfs client Mark Raynsford <list+org.debian@io7m.com> - 2020-02-22 16:40 +0100
              Re: Unable to use Buster as an nfs client Greg Wooledge <wooledg@eeg.ccf.org> - 2020-02-24 15:40 +0100

#219320 — Unable to use Buster as an nfs client

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

Hello!

I have a fresh install of Buster installed in a VM. I have
the following in /etc/apt/sources.list:

deb http://ftp.uk.debian.org/debian/ buster main
deb http://ftp.uk.debian.org/debian/ buster-updates main
deb http://security.debian.org/debian-security buster/updates main
deb-src http://ftp.uk.debian.org/debian/ buster main
deb-src http://ftp.uk.debian.org/debian/ buster-updates main
deb-src http://security.debian.org/debian-security buster/updates main

I'm completely up-to-date according to "apt update; apt upgrade".

I've installed nfs-common as per the manual, but I'm unable to load the
nfs kernel module:

# modprobe nfs
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.9.0-9-amd64/modules.dep.bin'
modprobe: FATAL: Module nfs not found in directory /lib/modules/4.9.0-9-amd64

There is no /lib/modules/4.9.0-9-amd64. There IS a
/lib/modules/4.19.0-8-amd64 directory, although forcibly trying to
"insmod" the nfs.ko file in it results in:

# insmod /lib/modules/4.19.0-8-amd64/kernel/fs/nfs/nfs.ko 
[ 1341.478240] nfs: disagrees about version of symbol module_layout
insmod: ERROR: could not insert module /lib/modules/4.19.0-8-amd64/kernel/fs/nfs/nfs.ko: Invalid module format

I've rebooted the VM several times, so it's definitely not a case of
running the wrong kernel.

# uname -a
Linux bloodorange.int.arc7.info 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11) x86_64 GNU/Linux

Is there some special magic I need to do to get the right kernel
modules?

-- 
Mark Raynsford | http://www.io7m.com

[toc] | [next] | [standalone]

#219321

	Hi.

On Sat, Feb 22, 2020 at 12:53:38PM +0000, Mark Raynsford wrote:
> I've rebooted the VM several times, so it's definitely not a case of
> running the wrong kernel.
> 
> # uname -a
> Linux bloodorange.int.arc7.info 4.9.0-9-amd64

And yet it is a case of running a wrong kernel.
You see, buster's kernel currently has version 4.19.0-8, but yours
(4.9.0-9) looks like an outdated stretch one.
And you do have a kernel 4.9, but you don't have the modules for it.
You do have a kernel 4.19 (with the modules), but you do not boot it.


> Is there some special magic I need to do to get the right kernel
> modules?

I'd start by fixing a bootloader (GRUB, most probably), because whatever
it boots it's not the kernel that Debian gives you in a buster.

Reco

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

#219322

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

On 2020-02-22T16:44:18 +0300
Reco <recoverym4n@enotuniq.net> wrote:
>
> And yet it is a case of running a wrong kernel.
> You see, buster's kernel currently has version 4.19.0-8, but yours
> (4.9.0-9) looks like an outdated stretch one.
> And you do have a kernel 4.9, but you don't have the modules for it.
> You do have a kernel 4.19 (with the modules), but you do not boot it.

Hm, I see. For this VM, I installed from the (slightly outdated)
debian-10.0.0-amd64-xfce-CD-1.iso install media, but I allowed the
installer to update from a public network mirror during the install,
so I should be running 10.3.

I'm curious as to how I even got a stretch kernel.

> > Is there some special magic I need to do to get the right kernel
> > modules?  
> 
> I'd start by fixing a bootloader (GRUB, most probably), because whatever
> it boots it's not the kernel that Debian gives you in a buster.

This is a Debian guest running on the bhyve[0] hypervisor. These are
the grub commands I use to boot the VM:

linux (hd0,msdos1)/vmlinuz root=/dev/sda1 init=/sbin/init
initrd (hd0,msdos1)/initrd.img
boot

I believe these are pretty standard and I think they, as a result,
just end up delegating to whatever configuration is present in the
guest. I haven't touched the default configuration in the guest, so
it's not clear to me how or why I would be booting something that's
misconfigured (unless there's some installer bug that nobody's caught).

These are the kernels I appear to have in the guest filesystem:

# ls -alF /boot/
total 67460
drwxr-xr-x  3 root root     4096 Feb 22 11:31 ./
drwxr-xr-x 22 root root     4096 Feb 22 12:18 ../
-rw-r--r--  1 root root   206212 Jun 19  2019 config-4.19.0-5-amd64
-rw-r--r--  1 root root   206194 Jan 26 20:01 config-4.19.0-8-amd64
drwxr-xr-x  5 root root     4096 Feb 22 11:32 grub/
-rw-r--r--  1 root root 25561139 Feb 22 11:12 initrd.img-4.19.0-5-amd64
-rw-r--r--  1 root root 25807344 Feb 22 11:29 initrd.img-4.19.0-8-amd64
-rw-r--r--  1 root root  3371003 Jun 19  2019 System.map-4.19.0-5-amd64
-rw-r--r--  1 root root  3408461 Jan 26 20:01 System.map-4.19.0-8-amd64
-rw-r--r--  1 root root  5221616 Jun 19  2019 vmlinuz-4.19.0-5-amd64
-rw-r--r--  1 root root  5270768 Jan 26 20:01 vmlinuz-4.19.0-8-amd64

Is there some way I can determine if my setup is "wrong" somehow? I'm
not sure what I should be looking for.

[0] https://www.freebsd.org/doc/handbook/virtualization-host-bhyve.html

-- 
Mark Raynsford | http://www.io7m.com

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

#219324

On Sat, Feb 22, 2020 at 02:03:55PM +0000, Mark Raynsford wrote:
> On 2020-02-22T16:44:18 +0300
> Reco <recoverym4n@enotuniq.net> wrote:
> >
> > And yet it is a case of running a wrong kernel.
> > You see, buster's kernel currently has version 4.19.0-8, but yours
> > (4.9.0-9) looks like an outdated stretch one.
> > And you do have a kernel 4.9, but you don't have the modules for it.
> > You do have a kernel 4.19 (with the modules), but you do not boot it.
> 
> Hm, I see. For this VM, I installed from the (slightly outdated)
> debian-10.0.0-amd64-xfce-CD-1.iso install media, but I allowed the
> installer to update from a public network mirror during the install,
> so I should be running 10.3.
> 
> I'm curious as to how I even got a stretch kernel.

A leftover from an old installation maybe?

> > > Is there some special magic I need to do to get the right kernel
> > > modules?  
> > 
> > I'd start by fixing a bootloader (GRUB, most probably), because whatever
> > it boots it's not the kernel that Debian gives you in a buster.
> 
> This is a Debian guest running on the bhyve[0] hypervisor. These are
> the grub commands I use to boot the VM:
> 
> linux (hd0,msdos1)/vmlinuz root=/dev/sda1 init=/sbin/init
> initrd (hd0,msdos1)/initrd.img
> boot

Aha. So basically your grub.conf does not come into the play.
And that means:

ls -la /vmlinuz /initrd.img

On a ordinary Debian systems they are symlinks to the files in /boot.
Apparently on yours they aren't.


> These are the kernels I appear to have in the guest filesystem:
> 
> # ls -alF /boot/
> total 67460
> drwxr-xr-x  3 root root     4096 Feb 22 11:31 ./
> drwxr-xr-x 22 root root     4096 Feb 22 12:18 ../
> -rw-r--r--  1 root root   206212 Jun 19  2019 config-4.19.0-5-amd64
> -rw-r--r--  1 root root   206194 Jan 26 20:01 config-4.19.0-8-amd64
> drwxr-xr-x  5 root root     4096 Feb 22 11:32 grub/
> -rw-r--r--  1 root root 25561139 Feb 22 11:12 initrd.img-4.19.0-5-amd64
> -rw-r--r--  1 root root 25807344 Feb 22 11:29 initrd.img-4.19.0-8-amd64
> -rw-r--r--  1 root root  3371003 Jun 19  2019 System.map-4.19.0-5-amd64
> -rw-r--r--  1 root root  3408461 Jan 26 20:01 System.map-4.19.0-8-amd64
> -rw-r--r--  1 root root  5221616 Jun 19  2019 vmlinuz-4.19.0-5-amd64
> -rw-r--r--  1 root root  5270768 Jan 26 20:01 vmlinuz-4.19.0-8-amd64
> 
> Is there some way I can determine if my setup is "wrong" somehow? I'm
> not sure what I should be looking for.

Nothing seems to be wrong in /boot at a first glance. But then again,
it's the root filesystem that's interesting here.

Reco

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

#219326

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

I've discovered what the problem was...

On 2020-02-22T17:39:05 +0300
Reco <recoverym4n@enotuniq.net> wrote:
>
> A leftover from an old installation maybe?

It's a new VM, but this actually _was_ the problem, amusingly. I had
the following in the bhyve device.map:

(hd0) /dev/zvol/storage/vm/peppermint/disk1
(cd0) /storage/images/debian-10.0.0-amd64-xfce-CD-1.iso

... However, I was actually running the VM specifying that
the root disk device was /dev/zvol/storage/vm/bloodorange/disk0.

In other words, it was booting using an initrd from the disk device
of another VM (peppermint) entirely!

Thanks for your time. Problem was in front of keyboard. :)

-- 
Mark Raynsford | http://www.io7m.com

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

#219327

On Saturday, February 22, 2020 09:42:32 AM Mark Raynsford wrote:
> It's a new VM, but this actually _was_ the problem, amusingly. I had
> the following in the bhyve device.map:

I sometimes get too curious, but is bhyve a typo, or something real?  (I tried 
locate on my system, didn't find anything.)

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

#219328

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

On 2020-02-22T10:27:41 -0500
rhkramer@gmail.com wrote:

> On Saturday, February 22, 2020 09:42:32 AM Mark Raynsford wrote:
> > It's a new VM, but this actually _was_ the problem, amusingly. I had
> > the following in the bhyve device.map:  
> 
> I sometimes get too curious, but is bhyve a typo, or something real?  (I tried 
> locate on my system, didn't find anything.)

It's a BSD hypervisor:

  https://bhyve.org/

The host machine is a rather large thing running FreeBSD, with a mix of
Debian, OpenBSD, and FreeBSD guests.

-- 
Mark Raynsford | http://www.io7m.com

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

#219390

On Sat, Feb 22, 2020 at 10:27:41AM -0500, rhkramer@gmail.com wrote:
> On Saturday, February 22, 2020 09:42:32 AM Mark Raynsford wrote:
> > It's a new VM, but this actually _was_ the problem, amusingly. I had
> > the following in the bhyve device.map:
> 
> I sometimes get too curious, but is bhyve a typo, or something real?  (I tried 
> locate on my system, didn't find anything.)

I'd never heard of it before, but it looks like a pun name.  It's
probably pronounced "bee hive".  So, probably not a typo.

[toc] | [prev] | [standalone]

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

csiph-web