LMDE BREAKAGES - tracking TESTING

[sidneyk]

I had the same issue a few days ago with the kexec thing. I had temporarily enabled the sid repos in order to get at the 2.6.38.1 kernel as I had heard that it was offering some better performance, particularly for my laptop which has ATI X1200 graphics. I thought it came through the sid repos possibly, but maybe it came from the testing repos (kexec and kexec-tools), I'm not sure. My understanding was that it was meant to be a tool for people that build and / or test different kernels to be able to do the kernel reboots and get into the newer or custom kernel to test it without going through a complete reboot. The idea was nice, as long as it didn't mess anything else up or change any functionality of the running system, but it was kind of a pain to have to figure out that the only way to get back to grub was to do a complete shutdown first because, like you said, after kexec install, every time I hit the restart option, expecting just that - a restart as I have come to expect it to mean the same as a reboot - I would just get back to my desktop login screen instead of where I wanted. After some extensive searching, I finally came upon the solution, other than uninstalling kexec (or kexec-tools?). If you have this installed but also multi-boot, another reason for desiring a full reboot, then you can run this command:

sudo dpkg-reconfigure kexec-tools

This will bring up another box which gives a brief explanation of the intent of kexec and asks should kexec-tools handle reboots? Answer no and you will be right back to where you want to be, with kexec in place should you decide you want or need it at some point, but with the expected reboot behavior from before. Again, the idea is kind of nice but maybe another option needed to be added to the "Quit" menu giving you the choice of warm (kexec) reboot or full reboot to grub or better yet, kexec, if it is being used, should ask you what you want to do instead of just imposing it's actions. That would make it a pretty useful tool for some folks.

[mads]

I know that, but have you actually tried it?

Yes, I've enabled it. Works fine, no selective logging.

[Jaime Frontero]

If you have this installed but also multi-boot, another reason for desiring a full reboot, then you can run this command:

sudo dpkg-reconfigure kexec-tools

This will bring up another box which gives a brief explanation of the intent of kexec and asks should kexec-tools handle reboots? Answer no and you will be right back to where you want to be, with kexec in place should you decide you want or need it at some point, but with the expected reboot behavior from before.

Yup, that works.

I'm running LMDE 64-bit, and my first hint of breakage was the inability to mount USB devices, and then any drives other than my boot drive. Then I lost Pulse Audio to the null device. Setting kexec-tools boot handling to "no" appears to be a clean fix. Thank you kindly.

[viking777]

If you have this installed but also multi-boot, another reason for desiring a full reboot, then you can run this command:

sudo dpkg-reconfigure kexec-tools

This will bring up another box which gives a brief explanation of the intent of kexec and asks should kexec-tools handle reboots? Answer no and you will be right back to where you want to be, with kexec in place should you decide you want or need it at some point, but with the expected reboot behavior from before.

An elegant solution, but I can't help but wonder one thing. As the sole point of kexec-tools seems to be to handle reboots, if you are going to deny it the ability to do that, then what it the point of having it installed at all?

BTW. I can confirm what jam666 says. The package is no longer offered for install even if you unpin it. I guess the original inclusion was just a mistake.

[GeneC]

Not sure if this report is best posted here, as it applies to a modified LMDE.

This LMDE is the standard following "testing" with all updates, but has been modified to use the "Liquorix" kernel, and Nvidia 195 drivers.

This mornings (Mar 25) updates included an update of the Liquorix kernel from

Linux 2.6.37-4.dmz.1-liquorix-amd64 to

Linux 2.6.38-1.dmz.1-liquorix-amd64 .

Upon reboot into the new kernel, I was greeted with a black screen with nothing else. No prompt, no cursor, nothing. None of the fucntions keys did anything. Re-boot into safe mode = same thing. I suspect a problem with the Nvidia drivers? I downloded these from synaptic.
Thing is, I had several updates to the Liquorix kernel over the last couple of months with no problems. I just updated the kernels through the standard synaptic update procedure, and they installed and rebuilt the Nvidia drivers. This time seems not. Perhaps something to be aware of if using Liquorix, and Nvidia. Perhaps it was just specific to me.

P.S.
A reboot into the old Linux 2.6.37-4.dmz.1-liquorix-amd64 kernel works fine.

[clem]

Just a quick note for LMDE users: mintupdate 4.2.3 was added to LMDE today. It features most of the improvements planned for Mint 11 (better speed, simplification of the check process, asynchronous changelog retrieval, embedded rules file) together with a fix for the following bug: https://bugs.launchpad.net/linuxmint/+bug/565013

This bug relates to some of the problems described in this thread and brings a fix to the "Broken packages" dialog.

This is a first step for LMDE, an update that brings it the upcoming improvements from Mint 11. What's coming next is an alteration of mintupdate that is specific to Debian. We'll snapshot the Debian repositories and "open the tap" at regular intervals (monthly for instance). Users will be upgrading to a snapshot we're familiar with, and the update manager will not only list updates but inform users about particular problems for this snapshot and maybe even solve some of them automatically. From a communication point of view, it will also ease the process, as you won't be referring to a particular date (as you did in this thread) but to a snapshot number.

LMDE is still young and as you can see it's not yet a 100% smooth experience, but we're working on it.

Enjoy the new mintupdate and let us know if you find any issue

Clem.

[Jaime Frontero]

Shucks, clem - this is FUN. ...and the best way I know of to learn an OS.

Wouldn't want it to be too easy, now would we?

[sidneyk]

If you have this installed but also multi-boot, another reason for desiring a full reboot, then you can run this command:

sudo dpkg-reconfigure kexec-tools

This will bring up another box which gives a brief explanation of the intent of kexec and asks should kexec-tools handle reboots? Answer no and you will be right back to where you want to be, with kexec in place should you decide you want or need it at some point, but with the expected reboot behavior from before.

An elegant solution, but I can't help but wonder one thing. As the sole point of kexec-tools seems to be to handle reboots, if you are going to deny it the ability to do that, then what it the point of having it installed at all?

BTW. I can confirm what jam666 says. The package is no longer offered for install even if you unpin it. I guess the original inclusion was just a mistake.

Well, except that the stated intention of kexec was to allow you to reboot into a new kernel without going through the entire reboot process and that functionality worked real well, if you are expecting it. This was supposedly helpful and a time saver for those that like to experiment with new kernels or do a lot of kernel customization. There just should have been more communication to let the end user know that now you would have to do a complete shutdown to get back to the grub menu or that you would have to either uninstall kexec or reconfigure as above for kexec to not handle "reboots". I don't know if there were any special keys you could press to bring up a full reboot option or not, I couldn't find that info. I'm just saying that I can see the usefulness for someone that has to continually reboot to test new kernels or something or other development work, but if you're going to force it on us in an upgrade then it should have come out of the box with changed options in the 'Quit' dialog or some help explanation when you started the 'reboot' that made it clear what was taking place and gave you the opportunity to make a choice you wanted to make or simply jus gave you the info so you could turn it off instead of having to search high and low for the answer.

[sidneyk]

Not sure if this report is best posted here, as it applies to a modified LMDE.

This LMDE is the standard following "testing" with all updates, but has been modified to use the "Liquorix" kernel, and Nvidia 195 drivers.

This mornings (Mar 25) updates included an update of the Liquorix kernel from

Linux 2.6.37-4.dmz.1-liquorix-amd64 to

Linux 2.6.38-1.dmz.1-liquorix-amd64 .

Upon reboot into the new kernel, I was greeted with a black screen with nothing else. No prompt, no cursor, nothing. None of the fucntions keys did anything. Re-boot into safe mode = same thing. I suspect a problem with the Nvidia drivers? I downloded these from synaptic.
Thing is, I had several updates to the Liquorix kernel over the last couple of months with no problems. I just updated the kernels through the standard synaptic update procedure, and they installed and rebuilt the Nvidia drivers. This time seems not. Perhaps something to be aware of if using Liquorix, and Nvidia. Perhaps it was just specific to me.

P.S.
A reboot into the old Linux 2.6.37-4.dmz.1-liquorix-amd64 kernel works fine.

I'm using the 2.6.38-1amd64 kernel that came from the sid repos a few days ago. As far as I know it is not the liquorix kernel and on 2 machines it worked without a hitch. As far as the nvidia drivers, I think at the time I did the kernel upgrade I may have had nouveau driver installed but later noticed that sid had some newer proprietary drivers and installed those after I did the kernel upgrade. That isn't always a very smooth process. I had a backup copy of xorg.conf fortunately which was working with previous closed drivers and that got me back in operation. I've found with the nvidia non-free drivers, whether from the repos or direct from nvidia that you build the modules for yourself, that they don't seem to build a proper xorg.conf with at least a standard set of monitor options which those drivers seem to depend on. I know you can reboot back to some standard open, non-3d driver by just getting rid of xorg.conf, but it would be nice if at least the repo closed drivers would include a basic xorg.conf so that we're not greeted to the famous black screen when we reboot after the driver install. It sure would make life easier.

[CiaW]

Not sure if this report is best posted here, as it applies to a modified LMDE.
Upon reboot into the new kernel, I was greeted with a black screen with nothing else. No prompt, no cursor, nothing. None of the fucntions keys did anything. Re-boot into safe mode = same thing. I suspect a problem with the Nvidia drivers? I downloded these from synaptic.
A reboot into the old Linux 2.6.37-4.dmz.1-liquorix-amd64 kernel works fine.

You'll probably want to install the nvidia-kernel-dkms package also, here's part of the description from synaptic:

This package builds the NVIDIA Xorg binary kernel module needed by
nvidia-glx, using DKMS.
Provided that you have the kernel header packages installed, the kernel
module will be built for your running kernel and automatically rebuilt for
any new kernel headers that are installed.

I'm going to guess that you get new kernel-headers with your liquorix kernel, I believe it needs those and then it'll automatically rebuild the nvidia module for any new kernels, rather than having to wait for a specific rebuilt kernel for nvidia. HTH.

[clem]

Right... I took the opportunity to fix a few more things, so here's all the changes in mintupdate coming up today in LMDE:

mintupdate (4.2.5) katya; urgency=low

* Small cosmetic bug fix on /tmp/mintUpdate chmod call

-- Clement Lefebvre <root@linuxmint.com> Fri, 25 Mar 2011 15:53:00 +0000

mintupdate (4.2.4) katya; urgency=low

* Modal synaptic dialogs
* Synaptic dialog closes itself automatically after a successful upgrade
* Cleaned up warning due to windows sockets
* Cleaned up child (root) update manager killing parent (user) application, relying on killall instead.

-- Clement Lefebvre <root@linuxmint.com> Fri, 25 Mar 2011 15:40:00 +0000

mintupdate (4.2.3) katya; urgency=low

* Mint 11 changes:
* Removed warning and extra info tabs
* Asynchronous changelog retrieval
* Cleaned up upstream changelog retrieval
* Migrated from wget to urllib2 for changelog retrieval
* Only show mintupdate update when available to make sure rules are updated first
* Removed proxy settings (delegated to APT/Desktop)
* Fixed "broken packages" bug occuring when some packages need to be removed
* In history of updates, dates now follow the format YYY.MM.DD
* Fixed permission bug on /tmp/mintUpdate log folder

-- Clement Lefebvre <root@linuxmint.com> Wed, 23 Mar 2011 13:23:00 +0000

[kmb42vt]

Not sure if this report is best posted here, as it applies to a modified LMDE.
Upon reboot into the new kernel, I was greeted with a black screen with nothing else. No prompt, no cursor, nothing. None of the fucntions keys did anything. Re-boot into safe mode = same thing. I suspect a problem with the Nvidia drivers? I downloded these from synaptic.
A reboot into the old Linux 2.6.37-4.dmz.1-liquorix-amd64 kernel works fine.

You'll probably want to install the nvidia-kernel-dkms package also, here's part of the description from synaptic:

This package builds the NVIDIA Xorg binary kernel module needed by
nvidia-glx, using DKMS.
Provided that you have the kernel header packages installed, the kernel
module will be built for your running kernel and automatically rebuilt for
any new kernel headers that are installed.

I'm going to guess that you get new kernel-headers with your liquorix kernel, I believe it needs those and then it'll automatically rebuild the nvidia module for any new kernels, rather than having to wait for a specific rebuilt kernel for nvidia. HTH.

This problem that that GeneC encountered also happened to me when I attempted the update. Now I've been using the Liquorix kernel all along and have been updating on a regularly basis without a problem until this last update which failed to patch the Nvidia driver to the new kernel. And "nvidia-kernel-dkms" has been installed since the day I installed LMDE and added the Nvidia driver manually. Since previous updates to the Liquorix kernel have gone without a hitch I have to believe then that there is a bug in the Liquorix 2.38.* kernel update that's keeping the Nvidia driver from being patched into the kernel during the update process. I've done an initial search on the problem on Google and the same problem is just beginning to show for other ebian and Debian based distros users who are running the Liquorix kernel. The search results will probably be more definitive later in the day I'd imagine.

[GeneC]

sidneyk wrote:

I'm using the 2.6.38-1amd64 kernel that came from the sid repos a few days ago. As far as I know it is not the liquorix kernel and on 2 machines it worked without a hitch. As far as the nvidia drivers, I think at the time I did the kernel upgrade I may have had nouveau driver installed

I have a 2nd installation of LMDE and its tracking SID, I am also using the 2.6.38-1amd64 kernel on it, that came through with the std. upgrades from SID. It works perfectly with the noveau drivers. I tried installing the Nvidia 195 drivers with the same procedure that I did for my LMDE- "testing" installation and it did not work, there either. Something about the 2.6.38 kernel and Nvidia, at least on this machine.? Not an issue there, as the noveau works perfectly...

=============================================

CiaW wrote:

You'll probably want to install the nvidia-kernel-dkms package also, here's part of the description from synaptic:

"...This package builds the NVIDIA Xorg binary kernel module needed by
nvidia-glx, using DKMS.
Provided that you have the kernel header packages installed, the kernel
module will be built for your running kernel and automatically rebuilt for
any new kernel headers that are installed..."

I'm going to guess that you get new kernel-headers with your liquorix kernel, I believe it needs those and then it'll automatically rebuild the nvidia module for any new kernels, rather than having to wait for a specific rebuilt kernel for nvidia. HTH.

That is the issue. I had the nvidia-kernel-dkms package installed and in the past through several upgrades of the Liquorix kernel (like 5 or 6). Nvidia always rebuilt. Not this time.

I dont want to make a big issue of it on this thread, as I dont want to confuse people not using Liquorix, and Nvidia. Just to point it out to folks who are and might reconsider that update.

============================================================

kmb42vmt wrote:

Since previous updates to the Liquorix kernel have gone without a hitch I have to believe then that there is a bug in the Liquorix 2.38.* kernel update that's keeping the Nvidia driver from being patched into the kernel during the update process.

Yep! I am going to check out the Liquorix forum..

Thanks all.

[GeneC]

Yep! I am going to check out the Liquorix forum..

Yes, there does seem to be a problem with the new kernel. The headers dont install.

http://techpatterns.com/forums/about1810.html

Posted: Mar 24, 11, 23:22 Can't install linux-headers-2.6.38-liquorix-amd64
Today there was an update for my liquorix kernel from 2.6.37 to 2.6.38, but I can't install the new linux-headers-2.6.38-1.dmz.1-liquorix-amd64 because depends on gcc-4.5 which is a virtual package.

DMKS need the kernel headers to build update modules for VirtualBox, for example.

I'm on Debian Squeeze.

Guess, its just best to wait on that update till the Liquorix folks get it fixed.

[kmb42vt]

Yep! I am going to check out the Liquorix forum..

Yes, there does seem to be a problem with the new kernel. The headers dont install.

http://techpatterns.com/forums/about1810.html

Posted: Mar 24, 11, 23:22 Can't install linux-headers-2.6.38-liquorix-amd64
Today there was an update for my liquorix kernel from 2.6.37 to 2.6.38, but I can't install the new linux-headers-2.6.38-1.dmz.1-liquorix-amd64 because depends on gcc-4.5 which is a virtual package.

DMKS need the kernel headers to build update modules for VirtualBox, for example.

I'm on Debian Squeeze.

Guess, its just best to wait on that update till the Liquorix folks get it fixed.

Well that's just plain strange. I checked Synaptic and I have gcc-4.5 already installed (15 MB) and the VirtualBox module (vboxhost I think it's called) was the only thing that did build correctly to the new Liquorix kernel during the update. It was Nvidia that failed. Still, it has to be a problem with the Liquorix update so like you said, best wait a few days and then check again. As a note, once I uninstalled the Liquorix 2.38.* kernel (both headers and image), they're no longer offered as updates. Of course I haven't rebooted yet so that may change.

[kmb42vt]

Right... I took the opportunity to fix a few more things, so here's all the changes in mintupdate coming up today in LMDE:

mintupdate (4.2.5) katya; urgency=low

* Small cosmetic bug fix on /tmp/mintUpdate chmod call

-- Clement Lefebvre <root@linuxmint.com> Fri, 25 Mar 2011 15:53:00 +0000

mintupdate (4.2.4) katya; urgency=low

* Modal synaptic dialogs
* Synaptic dialog closes itself automatically after a successful upgrade
* Cleaned up warning due to windows sockets
* Cleaned up child (root) update manager killing parent (user) application, relying on killall instead.

-- Clement Lefebvre <root@linuxmint.com> Fri, 25 Mar 2011 15:40:00 +0000

mintupdate (4.2.3) katya; urgency=low

* Mint 11 changes:
* Removed warning and extra info tabs
* Asynchronous changelog retrieval
* Cleaned up upstream changelog retrieval
* Migrated from wget to urllib2 for changelog retrieval
* Only show mintupdate update when available to make sure rules are updated first
* Removed proxy settings (delegated to APT/Desktop)
* Fixed "broken packages" bug occuring when some packages need to be removed
* In history of updates, dates now follow the format YYY.MM.DD
* Fixed permission bug on /tmp/mintUpdate log folder

-- Clement Lefebvre <root@linuxmint.com> Wed, 23 Mar 2011 13:23:00 +0000

Thanks for the updates, Clem and for all the work that's been done so far. It will be quite the accomplishment getting MintUpdate to work properly in a rolling distro based on Debian testing no matter how it's done. Especially considering the way the updates fluctuate and change as far as occasionally missing dependencies and critical package removals go. Even though I do appreciate that Linux Mint Main is based on Ubuntu I also appreciate that there's the choice of a rolling version of Linux Mint as well. Here's to future breakage! (or the lack thereof?)

[viking777]

Clem.

I installed mintupdate 4.2.3 when you first announced it and then ran it until it showed the first update (mintupdate 4.2.5) and installed that. Now one update is not much to go on I will agree, but its behaviour is still exactly the same as it was before. As soon as you hit 'install updates' it goes away and does it.

Contrast that to Synaptic. When you hit 'mark all upgrades' it gives you a full list of what it is about to do. When you hit 'apply' it does the same again. That might be overkill, but telling you nothing and just going ahead is worse.

That is the problem with mintupdate, it should give a clear indication of what it is about to do BEFORE it does it (and give you the chance to back out/alter things if you think it necessary), and so far that does not seem to be what is happening.

[ukbrian]

@clem Many thanks for the update and a great Linux distro
While understanding the point viking777 makes about not seing what is going on your proposed method of releasing updates at monthly intervals after they have been tested for problems by the Debian testing, Aptosid and Antix users seems a perfect solution.

Snapshots would avoid the few problems that inexperienced(me) LMDE users have encountered to date and make a newcomer to LMDE first experience a whole lot better.

I guess to achieve this means replacing the Debian testing Repos with Mint snapshot ones and I wonder if this proves successful if it could be possible/desirable to do something similar with snapshots of the Debian Sid(unstable) repos?

A very happy and contented LMDE user
ukbrian

[tjweaver]

Issue with new version of Mint Update Manager.

After installing the new version of the Update Manager I now get this error at the bottom of the window when I hit the refresh button:

/usr/lib/linuxmint/mintUpdate/checkAPT.py:70: DeprecationWarning: Deprecated, please use 'get_changes()' instead
changes = cache.getChanges()

I don't get any kind of error messages when hitting the reload button in Synaptic. Just in the update manager.

[CiaW]

Clem, thanks for the update about the updater. I'm a bit concerned about this:
* Fixed "broken packages" bug occuring when some packages need to be removed

I guess I (we) could wait to see what that means, but I thought I'd ask for clarification. Does it mean it will remove whatever the dist-upgrade would want to remove without our confirmation? (i.e. recently VLC was removed for some, I chose 'no' to the dist-upgrade rather than removing VLC and then waited until the issue was sorted out; and I also recently had it remove Xiphos but it turns out a newer version was right there and installed fine...)

Or, will the monthly or so snapshot solve that issue? (maybe bi-weekly when coming off of a final release?) Since I also like using debdelta I may continue with at least a partial update via terminal, but I'm curious how those situations would be handled in this bug-fix? Basically I don't want it to remove something I use regularly, with no warning, and replace it with nothing. Thanks!