Content-Type: text/plain
debian-user-digest Digest Volume 2022 : Issue 680
Today's Topics:
Re: Why are some Debian bugs ignored [ Stefan Monnier <monnier@iro.umontre ]
Re: must i consider zfs or lvm for s [ Stefan Monnier <monnier@iro.umontre ]
Re: must i consider zfs or lvm for s [ <tomas@tuxteam.de> ]
Comments on upgrade steps from one v [ John Boxall <jboxall47@gmail.com> ]
Re: Why are some Debian bugs ignored [ Chuck Zmudzinski <brchuckz@netscape ]
Re: Why are some Debian bugs ignored [ Stefan Monnier <monnier@iro.umontre ]
Re: Comments on upgrade steps from o [ Charles Curley <charlescurley@charl ]
Re: Why are some Debian bugs ignored [ Chuck Zmudzinski <brchuckz@netscape ]
Re: must i consider zfs or lvm for s [ David Christensen <dpchrist@holgerd ]
Re: Comments on upgrade steps from o [ Chuck Zmudzinski <brchuckz@netscape ]
Re: Comments on upgrade steps from o [ John Boxall <jboxall47@gmail.com> ]
Re: Comments on upgrade steps from o [ John Boxall <jboxall47@gmail.com> ]
nfs-kernel-server [ Wylie <wylieq@twqua.com> ]
Re: nfs-kernel-server [ Greg Wooledge <greg@wooledge.org> ]
Re: Why are some Debian bugs ignored [ <tomas@tuxteam.de> ]
Date: Sat, 20 Aug 2022 14:06:33 -0400
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: debian-user@lists.debian.org
Subject: Re: Why are some Debian bugs ignored for a long time?
Message-ID: <[🔎] jwv35dq3iei.fsf-monnier+gmane.linux.debian.user@gnu.org>
Content-Type: text/plain
> So that means "free" software written and maintained by volunteers will never be as
> stable and secure as software that is written by people who are paid by the hour.
Not necessarily. Have you filed a bug report about a problem you
perceived in macOS, Windows, other your usual shrink wrapped software?
Has it always been fixed promptly?
If you want your bugs to be fixed, you generally need resort to some
kind of support contract, which you can get for Free Software just as
easily as for proprietary software (probably more easily, actually).
Notice also that the goal of Free Software is not to be technically
better (you may be confusing it for Open Source software), but
ethically better.
I suspect most maintainers who don't respond promptly to bug reports
aren't happy about that fact: its demoralizing to be in charge of
something you can't devote the resources it really deserves.
But note that *you* can help, by taking on some of the work, looking for
bugs that haven't gotten an answer yet and trying to address them.
I don't think anyone can do that for any random bug, but I'm pretty sure
most people on this list would be able to do that for at least one of
the pending bug reports.
Stefan
Date: Sat, 20 Aug 2022 14:35:35 -0400
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: debian-user@lists.debian.org
Subject: Re: must i consider zfs or lvm for smr large drive?
Message-ID: <[🔎] jwvwnb22393.fsf-monnier+gmane.linux.debian.user@gnu.org>
Content-Type: text/plain
> i have a new 4tb portable external drive. i want it to have a huge partition.
I love LVM and use it as a matter-of-course everywhere (except for /boot
partition which I still keep as a separate partition out of habit).
But FWIW, using LVM with external drives is not super smooth: it's OK if
the drive is almost always connected, but otherwise I don't think LVM
handles the case of plugging/unplugging the drive smoothly enough
(AFAICT there's no real problem at the lower levels, but at the UI level
it's just not "plug&play" enough IMO).
The main issue is that after plugging the drive in, you need to
"activate" its volumes (e.g. `vgchange -ay`, which AFAICT does not
affect the disk itself but only the host OS, making the volumes appear
under /dev/mapper), and they won't get deactivated automatically when
you unplug it (so you end up with ghost entries in /dev/mapper unless
you're careful to unmount everything and `vgchange -an` before
unplugging).
Maybe you can activate them once and for all and later just
unplug&replug and that'll work but I wouldn't bet on it (IIRC it depends
on whether it gets the same /dev/sdX label when you plug it back in).
So if your plugging and unplugging is done in a disciplined enough way
(and is already accompanied by running some scripts, e.g. to initiate
a backup onto the drive) I would recommend the use of LVM, but otherwise
you're probably better off without it.
> but now i am thinking, with smr, the drive could pseudo-brick,
Last I heard, SMR drives aren't significantly less reliable than CMR, so
I'm not sure you should base your decision on that. Of course, you'll
want to keep backups (unless that drive is the backup for others,
obviously).
Stefan
Date: Sat, 20 Aug 2022 20:53:58 +0200
From: <tomas@tuxteam.de>
To: debian-user@lists.debian.org
Subject: Re: must i consider zfs or lvm for smr large drive?
Message-ID: <[🔎] YwEtxmFD4Atg5uKD@tuxteam.de" target="_blank" rel="noreferrer">[🔎] YwEtxmFD4Atg5uKD@tuxteam.de>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="6QSkMZZGoHD2VXhp"
Content-Disposition: inline
--6QSkMZZGoHD2VXhp
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Aug 20, 2022 at 02:35:35PM -0400, Stefan Monnier wrote:
[...]
> > but now i am thinking, with smr, the drive could pseudo-brick,
>=20
> Last I heard, SMR drives aren't significantly less reliable than CMR, so
> I'm not sure you should base your decision on that. Of course, you'll
> want to keep backups (unless that drive is the backup for others,
> obviously).
Agreed. They are designed for another use-case. I don't know whether there
are file systems which work nicely with SMR.
Cheers
--=20
t
--6QSkMZZGoHD2VXhp
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCYwEtvwAKCRAFyCz1etHa
RgKIAJ9ShCG6Ng3I+ZjR1CBaMai4WW10nQCcDKoTT9IFW3reZ02+rltzXmgZyB4=
=8w6C
-----END PGP SIGNATURE-----
--6QSkMZZGoHD2VXhp--
Date: Sat, 20 Aug 2022 15:48:53 -0400
From: John Boxall <jboxall47@gmail.com>
To: "debian-user@lists.debian.org" <debian-user@lists.debian.org>
Subject: Comments on upgrade steps from one version of Debian to another
Message-ID: <[🔎] 89a753f9-5f2c-c3a3-b80c-ccd615bf9c23@gmail.com" target="_blank" rel="noreferrer">[🔎] 89a753f9-5f2c-c3a3-b80c-ccd615bf9c23@gmail.com>
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
I created an upgrade script based on something I found a few years ago
that indicated the steps to follow to upgrade from one version of Debian
to another (e.g. Buster 10 to Bullseye 11). As I am going to need to run
this script at some point (I am still running Buster/10 on my systems),
I thought I'd ask the Debian user brain trust to comment/critique the
scripted steps. So here they are:
############### Start
apt -y install aptitude
aptitude search \'~o\'
apt update
apt -y upgrade
apt -y full-upgrade
dpkg -C
apt-mark showhold
#
Update sources.list
#
Update files in sources.list.d
(I don't even have this part started yet....didn't know I needed it the
last time I ran it)
#
apt-get check
apt update
apt list --upgradable
apt-get check
apt -y upgrade
apt -y full-upgrade
aptitude search \'~o\'
############### End
Thoughts/critique/criticism/flames/etc
--
Regards,
John Boxall
Date: Sat, 20 Aug 2022 16:20:21 -0400
From: Chuck Zmudzinski <brchuckz@netscape.net>
To: debian-user@lists.debian.org
Subject: Re: Why are some Debian bugs ignored for a long time?
Message-ID: <[🔎] 93454b87-37db-97c2-ffec-9d656d56abe2@netscape.net" target="_blank" rel="noreferrer">[🔎] 93454b87-37db-97c2-ffec-9d656d56abe2@netscape.net>
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
On 8/20/2022 2:06 PM, Stefan Monnier wrote:
> > So that means "free" software written and maintained by volunteers will never be as
> > stable and secure as software that is written by people who are paid by the hour.
>
> Not necessarily. Have you filed a bug report about a problem you
> perceived in macOS, Windows, other your usual shrink wrapped software?
> Has it always been fixed promptly?
>
> If you want your bugs to be fixed, you generally need resort to some
> kind of support contract, which you can get for Free Software just as
> easily as for proprietary software (probably more easily, actually).
>
> Notice also that the goal of Free Software is not to be technically
> better (you may be confusing it for Open Source software), but
> ethically better.
>
> I suspect most maintainers who don't respond promptly to bug reports
> aren't happy about that fact: its demoralizing to be in charge of
> something you can't devote the resources it really deserves.
>
> But note that *you* can help, by taking on some of the work, looking for
> bugs that haven't gotten an answer yet and trying to address them.
That's a fair point. It may not be so easy for me to work on a bug that does not affect
my systems, but I am willing to help with bugs important to the Debian project now, as
the bookworm development process continues. I will take some time and see if I can
help out with some other open bugs that do not directly affect my systems. Such bugs
can be found by querying BTS for bugs marked as critical or grave by the maintainer
and bugs that are blocking a release, as these are the ones most important to the
maintainers and developers. I don't know if I have the skills to fix such bugs which are
probably not so easy to fix, but it wouldn't hurt to ask if there is anything I can do to
help. One thing that is always helpful are testers to test the proposed fixes for open
bugs, and I could help with that in cases when the bug affects a package on one or more
of my systems, at least to tell the maintainer, "that proposed fix looks good, it does not
break anything on my systems."
Thanks,
Chuck
> I don't think anyone can do that for any random bug, but I'm pretty sure
> most people on this list would be able to do that for at least one of
> the pending bug reports.
>
>
> Stefan
>
Date: Sat, 20 Aug 2022 16:28:52 -0400
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: debian-user@lists.debian.org
Subject: Re: Why are some Debian bugs ignored for a long time?
Message-ID: <[🔎] jwva67y1x2i.fsf-monnier+gmane.linux.debian.user@gnu.org>
Content-Type: text/plain
Chuck Zmudzinski [2022-08-20 16:20:21] wrote:
> That's a fair point. It may not be so easy for me to work on a bug that does not affect
> my systems, but I am willing to help with bugs important to the Debian project now, as
> the bookworm development process continues. I will take some time and see if I can
> help out with some other open bugs that do not directly affect my systems. Such bugs
> can be found by querying BTS for bugs marked as critical or grave by the maintainer
> and bugs that are blocking a release, as these are the ones most important to the
> maintainers and developers. I don't know if I have the skills to fix such bugs which are
> probably not so easy to fix, but it wouldn't hurt to ask if there is anything I can do to
> help. One thing that is always helpful are testers to test the proposed fixes for open
> bugs, and I could help with that in cases when the bug affects a package on one or more
> of my systems, at least to tell the maintainer, "that proposed fix looks good, it does not
> break anything on my systems."
Yes, there are many things one can do to help. E.g. several bugs are
misfiled (for example, sent to the Debian maintainer instead of being
sent to the package's developer even though the bug is unrelated to the
Debian packaging itself). Or often the bug report lacks information to
reproduce it.
Stefan
Date: Sat, 20 Aug 2022 14:24:46 -0600
From: Charles Curley <charlescurley@charlescurley.com>
To: Debian Users <debian-user@lists.debian.org>
Subject: Re: Comments on upgrade steps from one version of Debian to another
Message-ID: <[🔎] 20220820142446.10cda924@hawk.localdomain>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Sat, 20 Aug 2022 15:48:53 -0400
John Boxall <jboxall47@gmail.com> wrote:
> Thoughts/critique/criticism/flames/etc
I would not do that as a script. You have a good recipe there, but I
would run each step manually so I could correct errors, adjust
configuration files, and otherwise shoot trouble as it appears.
You should probably run 'apt auto-remove' from time to time in there as
needed.
--
Does anybody read signatures any more?
https://charlescurley.com
https://charlescurley.com/blog/
Date: Sat, 20 Aug 2022 17:06:02 -0400
From: Chuck Zmudzinski <brchuckz@netscape.net>
To: debian-user@lists.debian.org
Subject: Re: Why are some Debian bugs ignored for a long time?
Message-ID: <[🔎] 79b3d2ea-54f1-d37a-fcb0-850ca1c5c8cb@netscape.net" target="_blank" rel="noreferrer">[🔎] 79b3d2ea-54f1-d37a-fcb0-850ca1c5c8cb@netscape.net>
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
On 8/20/22 4:28 PM, Stefan Monnier wrote:
> Chuck Zmudzinski [2022-08-20 16:20:21] wrote:
> > That's a fair point. It may not be so easy for me to work on a bug that does not affect
> > my systems, but I am willing to help with bugs important to the Debian project now, as
> > the bookworm development process continues. I will take some time and see if I can
> > help out with some other open bugs that do not directly affect my systems. Such bugs
> > can be found by querying BTS for bugs marked as critical or grave by the maintainer
> > and bugs that are blocking a release, as these are the ones most important to the
> > maintainers and developers. I don't know if I have the skills to fix such bugs which are
> > probably not so easy to fix, but it wouldn't hurt to ask if there is anything I can do to
> > help. One thing that is always helpful are testers to test the proposed fixes for open
> > bugs, and I could help with that in cases when the bug affects a package on one or more
> > of my systems, at least to tell the maintainer, "that proposed fix looks good, it does not
> > break anything on my systems."
>
> Yes, there are many things one can do to help. E.g. several bugs are
> misfiled (for example, sent to the Debian maintainer instead of being
> sent to the package's developer even though the bug is unrelated to the
> Debian packaging itself). Or often the bug report lacks information to
> reproduce it.
>
>
> Stefan
>
On Debian, the best thing users can do to help, AFAICT, is to run the
testing distribution on non-critical systems to see if the development
of the next stable Debian version is causing problems. The more people
who run testing and give the developers feedback about problems on BTS,
the more likely the stable version won't break someone's current setup
when it is released and users start upgrading to the new stable version
in larger numbers. Still, for this development process that Debian uses to
be effective, when problems are reported to BTS, the developers and
maintainers need to respond to the bugs that are reported and not ignore
them.
Best regards,
Chuck
Date: Sat, 20 Aug 2022 15:03:42 -0700
From: David Christensen <dpchrist@holgerdanske.com>
To: debian-user@lists.debian.org
Subject: Re: must i consider zfs or lvm for smr large drive?
Message-ID: <[🔎] 42314837-3dcb-1e92-c4ba-5482e455b465@holgerdanske.com" target="_blank" rel="noreferrer">[🔎] 42314837-3dcb-1e92-c4ba-5482e455b465@holgerdanske.com>
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
> Am 20.08.2022 um 02:43 schrieb David Christensen:
>> My SOHO file and backup servers are FreeBSD with encrypted ZFS root. I
>> use single 2.5" SSD's for the OS drive. I hacked the installer to set
>> copies=2 for boot and root, and enabled mirror for swap.
On 8/20/22 00:30, DdB wrote:
> Hey! This sounds like you know, what you are doing, and more advanced
> compared to me. Sorry for having stated the obvious, then.
>
> Have fun with it. :-)
> DdB
The obvious choices are one drive and RAID. Both are supported by the
Debian and FreeBSD installers.
I prefer one drive per OS image, and keep all of my data in RAID on a
file server. The FreeBSD installer is a shell script, and already
features encrypted ZFS on root. Adding "copies=2" was straight-forward.
The key was being able to read and write Bourne shell scripts.
David
Date: Sat, 20 Aug 2022 19:27:23 -0400
From: Chuck Zmudzinski <brchuckz@netscape.net>
To: debian-user@lists.debian.org
Subject: Re: Comments on upgrade steps from one version of Debian to another
Message-ID: <[🔎] f345ae68-ed11-e898-f7e5-ec12d4364c75@netscape.net" target="_blank" rel="noreferrer">[🔎] f345ae68-ed11-e898-f7e5-ec12d4364c75@netscape.net>
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
On 8/20/2022 3:48 PM, John Boxall wrote:
> I created an upgrade script based on something I found a few years ago
> that indicated the steps to follow to upgrade from one version of Debian
> to another (e.g. Buster 10 to Bullseye 11). As I am going to need to run
> this script at some point (I am still running Buster/10 on my systems),
> I thought I'd ask the Debian user brain trust to comment/critique the
> scripted steps. So here they are:
>
>
> ############### Start
> apt -y install aptitude
> aptitude search \'~o\'
> apt update
> apt -y upgrade
> apt -y full-upgrade
> dpkg -C
> apt-mark showhold
> #
> Update sources.list
> #
> Update files in sources.list.d
> (I don't even have this part started yet....didn't know I needed it the
> last time I ran it)
> #
> apt-get check
> apt update
> apt list --upgradable
> apt-get check
> apt -y upgrade
> apt -y full-upgrade
> aptitude search \'~o\'
> ############### End
>
> Thoughts/critique/criticism/flames/etc
>
Hi John, here are my suggestions:
You can use apt, apt-get, or aptitude to run the commands that do most of the work, and in your script you chose apt for that task. I recall reading that they do not all use the same algorithm to determine which packages to upgrade and in what order, at each stage of the upgrade. I think I read somewhere that aptitude has the best algorithm, but apt-get is more suitable for a script. I don't remember if there are advantages or disadvantages to using apt. So you should do a little research to try to find the most up-to-date information about the pros and cons of the different apt related tools. The Debian wiki has a page on that, I think. Also, you might want to make sure you record the upgrade session in a logfile so you can examine what the script actually did in case there are problems. And of course, backup or take a snapshot beforehand so you can restore the system back to a working state in case things get broken badly.
HTH,
Chuck
Date: Sat, 20 Aug 2022 19:45:24 -0400
From: John Boxall <jboxall47@gmail.com>
To: "debian-user@lists.debian.org" <debian-user@lists.debian.org>
Subject: Re: Comments on upgrade steps from one version of Debian to another
Message-ID: <[🔎] e717d584-0aee-74dc-33f9-3771e40f3bd0@gmail.com" target="_blank" rel="noreferrer">[🔎] e717d584-0aee-74dc-33f9-3771e40f3bd0@gmail.com>
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2022-08-20 19:27, Chuck Zmudzinski wrote:
> On 8/20/2022 3:48 PM, John Boxall wrote:
>> I created an upgrade script based on something I found a few years ago
>> that indicated the steps to follow to upgrade from one version of Debian
>> to another (e.g. Buster 10 to Bullseye 11). As I am going to need to run
>> this script at some point (I am still running Buster/10 on my systems),
>> I thought I'd ask the Debian user brain trust to comment/critique the
>> scripted steps. So here they are:
>>
>>
>> ############### Start
>> apt -y install aptitude
>> aptitude search \'~o\'
>> apt update
>> apt -y upgrade
>> apt -y full-upgrade
>> dpkg -C
>> apt-mark showhold
>> #
>> Update sources.list
>> #
>> Update files in sources.list.d
>> (I don't even have this part started yet....didn't know I needed it the
>> last time I ran it)
>> #
>> apt-get check
>> apt update
>> apt list --upgradable
>> apt-get check
>> apt -y upgrade
>> apt -y full-upgrade
>> aptitude search \'~o\'
>> ############### End
>>
>> Thoughts/critique/criticism/flames/etc
>>
>
> Hi John, here are my suggestions:
>
> You can use apt, apt-get, or aptitude to run the commands that do most of the work, and in your script you chose apt for that task. I recall reading that they do not all use the same algorithm to determine which packages to upgrade and in what order, at each stage of the upgrade. I think I read somewhere that aptitude has the best algorithm, but apt-get is more suitable for a script. I don't remember if there are advantages or disadvantages to using apt. So you should do a little research to try to find the most up-to-date information about the pros and cons of the different apt related tools. The Debian wiki has a page on that, I think. Also, you might want to make sure you record the upgrade session in a logfile so you can examine what the script actually did in case there are problems. And of course, backup or take a snapshot beforehand so you can restore the system back to a working state in case things get broken badly.
>
> HTH,
>
> Chuck
>
Thanks Chuck, very good points.
apt always tells you that it isn't reliable in a script, which I am
aware of, however, I'll check the wiki. I "think" that applies to
apt-get as well. I've never used aptitude for anything but the one
command (it was one of those recommended on the web page I saw), but
will investigate it further.
I use "tee" extensively in the script and record all of the command output.
As for a backup, I will be cloning the drive to a backup and performing
a test update to that drive first.
My only real concern is the non-Debian software that I've installed over
the years. We'll see how it goes.
--
Regards,
John Boxall
Date: Sat, 20 Aug 2022 19:49:33 -0400
From: John Boxall <jboxall47@gmail.com>
To: debian-user@lists.debian.org
Subject: Re: Comments on upgrade steps from one version of Debian to another
Message-ID: <[🔎] 98dac9b5-4139-923d-191f-b6196f748b79@gmail.com" target="_blank" rel="noreferrer">[🔎] 98dac9b5-4139-923d-191f-b6196f748b79@gmail.com>
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2022-08-20 16:24, Charles Curley wrote:
>
> I would not do that as a script. You have a good recipe there, but I
> would run each step manually so I could correct errors, adjust
> configuration files, and otherwise shoot trouble as it appears.
>
I did a lot of testing the first time I ran the script and feel that I
can get away with it. I do have a complete log of all command output.
> You should probably run 'apt auto-remove' from time to time in there as
> needed.
>
That is a good point. I'll probably through at least one in before
updating the sources.list files. Maybe one at the end as well.
--
Regards,
John Boxall
Date: Sat, 20 Aug 2022 18:21:21 -0700
From: Wylie <wylieq@twqua.com>
To: debian-user@lists.debian.org
Subject: nfs-kernel-server
Message-ID: <[🔎] 6921d8eb-5cb2-aa38-73fa-5f84e7eab276@twqua.com" target="_blank" rel="noreferrer">[🔎] 6921d8eb-5cb2-aa38-73fa-5f84e7eab276@twqua.com>
Content-Type: multipart/alternative;
boundary="------------A2AD9FBA71891412170BDB7D"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------A2AD9FBA71891412170BDB7D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
i am getting this error ... on a fresh install of nfs-kernel-server
mount.nfs: access denied by server while mounting
192.168.42.194:/ShareName
i'm not having this issue on other machines installed previously
i've tried re-installing Debian and nfs several times
Wylie!
--------------A2AD9FBA71891412170BDB7D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<font size="-1">i am getting this error ... on a fresh install of
nfs-kernel-server <br>
<br>
mount.nfs: access denied by server while mounting
192.168.42.194:/ShareName<br>
<br>
i'm not having this issue on other machines installed previously<br>
i've tried re-installing Debian and nfs several times<br>
<br>
<br>
Wylie!<br>
</font>
</body>
</html>
--------------A2AD9FBA71891412170BDB7D--
Date: Sat, 20 Aug 2022 22:25:23 -0400
From: Greg Wooledge <greg@wooledge.org>
To: debian-user@lists.debian.org
Subject: Re: nfs-kernel-server
Message-ID: <[🔎] YwGXk5g0rKxAc6fR@wooledge.org" target="_blank" rel="noreferrer">[🔎] YwGXk5g0rKxAc6fR@wooledge.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
On Sat, Aug 20, 2022 at 06:21:21PM -0700, Wylie wrote:
>
> i am getting this error ... on a fresh install of nfs-kernel-server
>
> mount.nfs: access denied by server while mounting
> 192.168.42.194:/ShareName
>
> i'm not having this issue on other machines installed previously
> i've tried re-installing Debian and nfs several times
What's in your /etc/exports file on the server? What's the client's
IP address and hostname? If you attempt to resolve the client's IP
address from the server, what do you get?
If the client changed IP address or name, or if you changed its entry
in /etc/exports on the server, did you restart the NFS server service?
Date: Sun, 21 Aug 2022 07:11:49 +0200
From: <tomas@tuxteam.de>
To: debian-user@lists.debian.org
Subject: Re: Why are some Debian bugs ignored for a long time?
Message-ID: <[🔎] YwG+laRYGfRP13qk@tuxteam.de>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="yxoy1FyIjMlPqxb3"
Content-Disposition: inline
--yxoy1FyIjMlPqxb3
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Aug 20, 2022 at 04:20:21PM -0400, Chuck Zmudzinski wrote:
> On 8/20/2022 2:06 PM, Stefan Monnier wrote:
[...]
> > But note that *you* can help, by taking on some of the work, looking for
> > bugs that haven't gotten an answer yet and trying to address them.
>=20
> That's a fair point. It may not be so easy for me to work on a bug that d=
oes not affect
> my systems, but I am willing to help with bugs important to the Debian pr=
oject now, as
> the bookworm development process continues [...]
Yay! Thank you!
Cheers
--=20
t
--yxoy1FyIjMlPqxb3
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCYwG+lQAKCRAFyCz1etHa
Rhq0AJ908VnaYnfEeFwOaQ+jRZB5EHQjIQCfQxiw9rixOJkwf6JyPs9UtlZNj50=
=s/Yz
-----END PGP SIGNATURE-----
--yxoy1FyIjMlPqxb3--