LMDE BREAKAGES - tracking TESTING

[barryp]

Hi folks,

I've been using LMDE on my Toshiba Tecra laptop very happily & keeping an eye on the forum in general & this - very useful & interesting - thread, thanks to all.

I've been updating with

sudo apt-get update && apt-get dist-upgrade

about every week or two.

I decided to respond to Mads request for us to try Mintupdate again, so I did a quick "&&" first, but I noticed an error message during the process when it stopped & restarted nfs-common: failed.

I use nfs to access my NAS HDD via a sheeva plug. It has been working very well.

The first thing I did was a hard reboot & got an nfs fail during that process. I then used Synaptic to try to reinstall nfs-common & got another fail when it tried to restart nfs-common as part of that process.

My nfs volumes are mounted by fstab so if I I try:

sudo mount -a
[sudo] password for barry:
/bin/sh: Illegal option -p
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified
/bin/sh: Illegal option -p
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified
/bin/sh: Illegal option -p
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified
/bin/sh: Illegal option -p
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified

The four repetitions represent 4 partitions on my external drive. I assume that the error is just telling me that nfs-common isn't running. If I try to restart nfs:

barry@toshiba ~ $ sudo /etc/init.d/nfs-common restart
Stopping NFS common utilities: idmapd statd.
Starting NFS common utilities: statd failed!

Any ideas?

==

Later.

I removed the package

1:1.2.3-1 (source: nfs-utils 1:1.2.3-1)

& Installed an nearlier version

1:1.2.2-5 (source: nfs-utils 1:1.2.2-5)

from here:
http://snapshot.debian.org/binary/nfs-common/

Which has fixed the problem for me, now, but the question remains was the package broken? Also I am here to learn - was there a neater way to get an earlier version of the package, could I have done it entirely in the terminal, for instance?

BTW this forum is the best place I have found to learn about linux & I read it most days.

Thanks
Barry

[mads]

I decided to respond to Mads request for us to try Mintupdate again...

Hi barryp.
Before you use mintUpdate (Update Manager in Menu) to update your system,
go to Edit > Preferences > Levels and check all 10 boxes there.

[viking777]

was there a neater way to get an earlier version of the package, could I have done it entirely in the terminal, for instance?

Providing you haven't used the commands 'apt-get clean' or 'apt-get autoclean' or used something like bleachbit that runs those commands for you then you should find your package history in var/cache/apt/archives which will usually contain the previous version of the package you want to replace.

The only downside to this is that if you dont clean or autoclean the archive file it can become huge, particularly on a rolling release, so if you get a warning one day to say that your disk is out of space you know where to look first

NB I just had a look in my cache file and it is already up to 1.3Gb!

[barryp]

Mads: Thanks for the reminder! Should I run Mint Update straight away?

Viking: Uh-oh, I did autoclean recently I'm pretty sure, but it's a useful tip which I'll remember. Ta.

[mads]

Mads: Thanks for the reminder! Should I run Mint Update straight away?

Yes, you can. I've been using it for 3 days, and it works just fine.

Short explanation about levels. The default settings (i.e. only 3 levels checked) are for users who are
running ordinary Linux Mint releases. For Debian based releases, all levels should be checked.

Another function which some users might find helpful is "History of updates":
Update Manager > View > History of updates
It shows Date, Time, Level, Package name, New version, and Old version of packages installed. Good
to know this info in case of breakages or issues related to new updates.

[CiaW]

I removed the package

1:1.2.3-1 (source: nfs-utils 1:1.2.3-1)

& Installed an nearlier version

1:1.2.2-5 (source: nfs-utils 1:1.2.2-5)

from here:
http://snapshot.debian.org/binary/nfs-common/

Which has fixed the problem for me, now, but the question remains was the package broken? Also I am here to learn - was there a neater way to get an earlier version of the package, could I have done it entirely in the terminal, for instance?
Thanks
Barry

I deleted most of the post, but after reading this I checked MintUpdate and it showed an update to nfs-common among a couple of other things. nfs-common and nfs-kernel-server were just updated a couple of days ago. When I updated then I did it in the terminal, and was asked if I wanted to keep or replace the /etc/default/nfs-common and kernel-server files or keep the current ones. I made copies of the current ones and selected the option to update to the new ones. Then I tested a mount on my laptop and it worked. When I just now updated I used MintUpdate and it didn't ask about keeping the current file or updating to the new one, and when I checked the directory apparently it kept the old one as they had Sunday's date.

I tried to mount to my laptop and it failed. I decided to restart my whole system which houses the nfs-server and here are messages from the boot log, I cut out the lines between the ones that failed for nfs-related things:

• Thu Apr 7 08:12:07 2011: Starting portmap daemon....
  Thu Apr 7 08:12:07 2011: Starting NFS common utilities: statd failed!
  Thu Apr 7 08:12:10 2011: Starting portmap daemon...Already running..
  Thu Apr 7 08:12:10 2011: Starting NFS common utilities: statd failed!
  Thu Apr 7 08:12:11 2011: Exporting directories for NFS kernel daemon....
  Thu Apr 7 08:12:11 2011: Starting NFS kernel daemon: nfsd mountd failed!

So if someone else is using NFS and hasn't updated yet you might want to try it using the terminal instead of MintUpdate and see if there are any differences. Or don't update the NFS-related files because it appears it's broken. Now I have to get ready for work...thankfully having NFS available isn't mission-critical for me or anything. But having a fix would be nice.

[sgosnell]

Today's updates fixed my problem. It now boots normally. No idea what happened, but it's now fixed.

This thread is about the updates that break the system, not about the updates that fix the system.
Glad that the problem is fixed, but I cannot find which post you are referring to.

This one: http://forums.linuxmint.com/viewtopic.p ... 64#p399764

Fixed the link, I hope.

[viking777]

Today's updates fixed my problem. It now boots normally. No idea what happened, but it's now fixed.

This thread is about the updates that break the system, not about the updates that fix the system.
Glad that the problem is fixed, but I cannot find which post you are referring to.

This one: http://forums.linuxmint.com/report.php?f=141&p=399764

There is something wrong with you link sgosnell - the one above opens a "report this post" screen.

[tjweaver]

My nfs shares/mounts are also broken after the most recent update. Does anyone else have any info or idea if a fix is on its way or do i need to downgrade to the previous version of nfs packages?

Thanks for your time and help.

UPDATE: Found a work around - replace portmap with rpcbind:
http://www.held.org.il/blog/2010/01/deb ... ransition/

Here's the Debian Bug report on the issue:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620059


I haven't tried this fix just because i'm worried about breaking other packages that depend on portmap (I have no idea what those packages might be though) and I'm worried I wont be able to easily undo the above changes.

UPDATE2: 4/11/2011 (copied and pasted from a later post)

I just ran a

Code: Select all

sudo apt-get update && sudo apt-get -s dist-upgrade

To see what was showing up in terminal (after completing a fairly large update, including new kernel upgrade, in the mint update tool.) I have mint update set to ignore nfs-kernel-server and nfs-common as I'm currently running on the older version to prevent nfs breakage.

Here was the result:

Code: Select all

The following packages will be REMOVED:
portmap
The following NEW packages will be installed:
rpcbind
The following packages will be upgraded:
nfs-common nfs-kernel-server

So i'm guessing it is ok to take the newer version of the nfs packages since the switch is being made from portmap to rpcbind automatically this time.

I applied all of the above updates taking the new version of nfs-common and nfs-kernel-server and replacing portmap with rpcbind. Everything is working great. All of my nfs shares and client mounts are working fine without any extra config settings or other changes.

[blowtorch]

My nfs shares/mounts are also broken after the most recent update. Does anyone else have any info or idea if a fix is on its way or do i need to downgrade to the previous version of nfs packages?

Thanks for your time and help.

Update: Found a work around - replace portmap with rpcbind:
http://www.held.org.il/blog/2010/01/deb ... ransition/

Here's the Debian Bug report on the issue:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620059


I haven't tried this fix just because i'm worried about breaking other packages that depend on portmap (I have no idea what those packages might be though) and I'm worried I wont be able to easily undo the above changes.

I myself am surprised to see that these problems have been passed down from sid to testing ... i gave up on sid way too much breakage lately

[sidneyk]

Here are some observations that I have made over the past couple of days or so. A few days ago, I was running the gnome-shell from experimental successfully and finding my way around in it. I wound up borking my system, like I sometimes inadvertently do, and couldn't figure out what I had done wrong exactly or how to fix it. Since LMDE isn't my only or primary system at the moment, I decided to just reinstall. I had previously installed the base LMDE system from the DVD, rebooted and installed all updates for testing using sudo apt-get update, sudo apt-get dist-upgrade, rebooting, then installed nvidia drivers and got them working. I probably installed other various software packages also, then at some point, I changed my repos to point to unstable and did the same routine, sudo apt-get update, sudo apt-get dist-upgrade and rebooted and everything worked fine seemingly. I then added the experimental repo and did sudo apt-get -t experimental install gnome-shell and rebooted and logged into the gnome-shell and grabbed some other apps and program upgrades that seemed to be for gnome 3. This was all working pretty good for a couple of days or so, until Monday 4-6-11 when I came home and with experimental turned off, but unstable still on, I tried to do a sudo apt-get update and sudo apt-get dist-upgrade and it completely broke the system. So, since then I've reformatted partitions and reinstalled LMDE a few times to always come back to the same place after installing the nvidia drivers, I would get to the login screen where my mouse would be frozen and no keyboard response and by all appearances the system was completely locked up, requiring me to hold the power button down until my machine shut off and then reboot. If I went into recovery mode, I could delete the xorg.conf file and reboot and get back in, of course not using the nvidia drivers. I noticed also that during boot I was getting an error message that read "startpar:service(s) returned failure:udev...failed!". After researching this a bit I discovered that this was a bug in the new udev packages from unstable (version 167.1). So, today I took a different approach. I reinstalled LMDE from DVD and rebooted to the freshly installed system and did sudo apt-get update and sudo apt-get upgrade, because today, even with the default testing repos, a dist-upgrade was going to uninstall mint-codecs and a few other mint-packages which I was trying to avoid. So I chose to do upgrade to only upgrade already installed packages and checking to make sure that udev packages weren't being upgraded to the 167.1 version, so far so good. I then rebooted, using the default kernel from testing (2.6.32**) and installed the nvidia drivers and got them working. After rebooting, I then added the unstable repo so I could investigate what upgrade suggestions were being made from there. If I tried the dist-upgrade method like I had done before then of course the udev pkgs. would get upgraded to the buggy versions and bork everything again, so again I decided to only do a upgrade to unstable packages, ignoring udev, libudev0, and libgudev-1.0-0 packages so that they would not get upgraded. This was after I had also upgraded to the 2.6.38.2 kernel in unstable and rebooted and had nvidia drivers working like they should. This time, I didn't bork my system. I added the experimental repo back and did sudo apt-get -t experimental install gnome-shell, rebooted and grabbed some related gnome stuff, rebooted again and I am posting this while in gnome shell. Long and short of it is this, if you are using nvidia proprietary drivers, either from the repos or from nvidia website or plan to then DON'T ALLOW THESE PACKAGES FROM UNSTABLE, AS THEY ARE BUGGY AND WILL GIVE YOU MAJOR HEADACHES: udev, libudev0, libgudev-1.0-0. It seems that the newer version of these, because of some bugs that aren't closing something that should be closed are also not properly loading needed device drivers and causing a lockup at boot, at least while trying to use the nvidia closed drivers. The version 166.1 of these seems to be OK.

[kmb42vt]

Sorry for the off topic post here but once again the forums have stopped sending me notifications of new posts on threads I have subscribed to. So it's trying to tell me I'm not that important?

[dawgdoc]

I ran the listbugs command for nfs-common and found a number of bugs that may be contributing. Some are fairly recent, others are at least 3 months old. Here is a partial output in case anyone wants the bug numbers to see if any may apply to their setup.

Code: Select all

important bugs of nfs-common (-> ) <unfixed>
 #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access
   Merged with: 493667
 #621027 - Invalid shell option in start-statd
 #514910 - nfs: Fail to mount older NFS export
 #562821 - nfs-common: Fails to map user id's via idmapd
 #551821 - [nfs-common] directory not mounted at boot-time 
 #446238 - nfs-common: Locks when using nfs4 sec=krb5 and user ticket expires
 #620088 - rpc.statd[7623]: failed to create RPC listeners, exiting
 #600871 - nfs-common: Very slow and unreliable performance of GUI(KDE) when /home nfs mounted
 #515754 - nfs-common: Mounting with sec=krb5p fails with "access denied by server while mounting"
 #522926 - client cannot write to new files on server, only edit/delete/create
 #618473 - general: Problems to handle NIS group names
normal bugs of nfs-common (-> ) <unfixed>
 #503310 - mount.nfs: np-1b:/vol/dev_src failed, security flavor not supported
 #524458 - nfs-common: Can't read large files
 #568288 - mount.nfs: mount(2): Invalid argument
 #559296 - nfs-common: Unable to umount
 #557954 - nfs-common: showmount -e fails on NFS servers that only offer NFSv3 mountd (rpc mount export: RPC: Program/version mismatch; low version = 3, high version = 3)
 #472341 - nfs-common: ./configure error searching for KRBDIR
 #610953 - nfs-common: Upgrade from Lenny to Squeeze prevents mounting previously set up nfs exports
   Merged with: 609487
 #504512 - nfs-common: expired kerberos credentials cause significant syslog spam
 #301953 - mount: retry option for nfs is completely broken
 #621707 - nfs-common fails to start during boot
 #572406 - "users" Mount Option Broken
 #562737 - installation failed with "Starting NFS common utilities: statd failed!" (Fixed: nfs-utils/1:1.2.2-5)
 #575079 - nfs-common: nfs I/O never fails with udp and soft mount options in case of network failure

[hzsolt94]

Depedency problems with mint-meta-codec
There are some missing packages,

Bug: https://bugs.launchpad.net/linuxmint/+bug/754758
Thread: http://forums.linuxmint.com/viewtopic.p ... 7&p=396658

[viking777]

Depedency problems with mint-meta-codec
There are some missing packages,

Bug: https://bugs.launchpad.net/linuxmint/+bug/754758
Thread: http://forums.linuxmint.com/viewtopic.p ... 7&p=396658

There is no such package as mint-meta-codec, although there is a package called mint-meta-codecs, but like all meta packages it is of absolutely no importance once it has installed its constituent packages. In fact you are better off deleting it. It is certainly not a bug (unless you have a brand new install when I suppose it could be).

[CiaW]

My nfs shares/mounts are also broken after the most recent update. Does anyone else have any info or idea if a fix is on its way or do i need to downgrade to the previous version of nfs packages?

Update: Found a work around - replace portmap with rpcbind:
http://www.held.org.il/blog/2010/01/deb ... ransition/

Here's the Debian Bug report on the issue:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620059
I haven't tried this fix just because i'm worried about breaking other packages that depend on portmap (I have no idea what those packages might be though) and I'm worried I wont be able to easily undo the above changes.

Thank you very much for this information. I unselected portmap in the services gui then removed it in synaptic and it wanted to mark rpcbind to install so it saved me that step.

Then following the info. on the blog linked above, under step 5, step d. says to: Add rpcbind to /etc/insserv.conf, in the “portmap” line; and while I found that file I didn't see a portmap line so I left it alone. And step c. talks about creating an init script, however it appears there's already an init script that I can't really decipher, so I also left that alone. Basically the only thing I did after un-selecting and removing portmap and installing rpcbind was step e., which was to run (as root):

Code: Select all

insserv /etc/init.d/rpcbind

and then I ran

Code: Select all

service nfs-kernel-server start

and it did, no failed messages this time. And I just mounted my exported share on my laptop with no issues.

[tjweaver]

@ciaW - Glad it was of some help. Are you planning on reinstalling portmap after it is updated and in the repos or will you just leave things as you are. I just ended up downgrading nfs-kernel-server and nfs-common to get my nfs mounts back up and running and am hoping an upgrade to fix this issue will come down before too long.

Btw - i'm about and 1 1/2 hours S. of you in Moscow, Idaho. Nice to see a fellow LMDE user not too far away.

[CiaW]

@ciaW - Glad it was of some help. Are you planning on reinstalling portmap after it is updated and in the repos or will you just leave things as you are. I just ended up downgrading nfs-kernel-server and nfs-common to get my nfs mounts back up and running and am hoping an upgrade to fix this issue will come down before too long.

From what I could gather on the blog link posted, it sounded to me as though rpcbind is going to replace portmap, so I don't know if an update will be coming or not? Since rpcbind is working and it's apparently IPv6 ready whereas portmap isn't, I'll just stick with rpcbind I believe... but I'm hardly an expert on these things or I didn't read the article carefully enough. It's working now and if it needs to change back to portmap down the road I'll cross that proverbial bridge when I come to it. And isn't it nice to finally see a bit of sunshine here in the Northwest?

[tjweaver]

And isn't it nice to finally see a bit of sunshine here in the Northwest?

Yeah, it's freaking me out just a bit. I've actually forgotten what blue sky looks like.

From the site I posted a link to:

UPDATE2: THE BUG WAS SOLVED! Alexander Wirt patched nfs-kernel-server: by removing the linkage of libtirpc, it now uses the previously method of IPv4 binding, thus not triggering the problem. When/if would rpcbind replace portmap – I don’t know.

No mention of the version number or when it will be out though. But if the rpcbind works why fix it? If I don't see something in the way of an updated nfs-kernel-server come down in the repos in the near future I might go ahead and try replacing portmap just to get Mint Update to stop nagging me about my outdated nfs* versions.

[dawgdoc]

@CiaW and tjweaver

Part of the problem may not be coming from nfs packages. When I saw where the steps mentioned insserv I recalled seeing a report of a serious bugs involving init scripts. In brief it is

Code: Select all

serious bugs of insserv (1.14.0-2.1 -> ) <unfixed>
 #598020 - barfs when there are "invalid" init scripts

I had waited a week or more before installing that package to make sure it was not going to cause a problem.

But anyway, I am glad it is now working, and that is due to your diligence.