Linux Mint Forums

clem wrote:@kmb42vt: I can reproduce it here. It drops me to a console with a lot of disturbing symbols on the screen From there I can CTRL+ALT+F1 to gain access to a normal console though, and even CTRL+ALT+F7 to get back to X. I think that's been like that for a while though,

It has, as I mentioned in the other thread. It was reported on the debian bug tracker 21-06-2011 and I first encountered it 26-06-2011.
http://lists.debian.org/debian-kernel/2 ... 00536.html
http://forums.linuxmint.com/viewtopic.php?f=141&t=75848
Several people have confirmed it.

and I'm not exactly sure if it's kernel related or caused by something else...

Sorry, I don't quite understand that. It's a kernel panic. It says so on the screen. How can that be not kernel related?

What I mean by that is that I can't associate it with a particular package update/version, i.e. I don't have enough info to identify the regression.

clem wrote:@kmb42vt: I can reproduce it here. It drops me to a console with a lot of disturbing symbols on the screen From there I can CTRL+ALT+F1 to gain access to a normal console though, and even CTRL+ALT+F7 to get back to X. I think that's been like that for a while though, and I'm not exactly sure if it's kernel related or caused by something else...

@timmythepirate: That looks like a bug, but I need more info to flag this as a problem related to Update Pack 1.

Clem: Interesting, my system simply locks up and I'm unable to do anything except force my system to power off. This may be due to doing a fresh install of the Dec. 2010 (amd64) LMDE release and using the new update system to update LMDE from there. We, meaning zerozero and a few others on the "LMDE Breakages" thread, have basically eliminated the newer Ubuntu based kernel running in LM 11 (2.6.39.2), the Arch kernel (2.6.39-2) running in Chakra testing and the latest Liquorix (2.6.39-2.dmz.1-liquorix-amd64) running in LMDE as far as having the same problem.

In my experience, when selecting "Safely remove drive" from the right-click context menu for any mounted removable hard drive it should first unmount the drive and apparently it's not doing this for USB connected hard drives. Unmounting the drive first parks the heads on a removable hard drive which is not necessary for a flash based thumb drive so the problem does not occur. If I first unmount my USB connected hard drive in Nautilus (the drive heads then park) and then select "Safely remove drive" from the right-click context menu the system does not lock up. So it could be a combination of the kernel and a bug in LMDE as well?

Just half thinking out loud here.

kmb42vt wrote:So it could be a combination of the kernel and a bug in LMDE as well?

I doubt that. After all, it's not happening on just LMDE.

Don't forget about the Debian Testing user who originally reported the bug (see my previous post). And possibly this one, also pure Debian Testing: http://forums.debian.net/viewtopic.php?f=10&t=66437 (not absolutely certain here as the original poster didn't mention the kernel version, but the "After some recent upgrade" suggests a recent one).

Edit: another new remark about this in my original thread: http://forums.linuxmint.com/viewtopic.p ... 48#p446194

grizzler wrote:

kmb42vt wrote:So it could be a combination of the kernel and a bug in LMDE as well?

I doubt that. After all, it's not happening on just LMDE.

Don't forget about the Debian Testing user who originally reported the bug (see my previous post). And possibly this one, also pure Debian Testing: http://forums.debian.net/viewtopic.php?f=10&t=66437 (not absolutely certain here as the original poster didn't mention the kernel version, but the "After some recent upgrade" suggests a recent one).

Edit: another new remark about this in my original thread: http://forums.linuxmint.com/viewtopic.p ... 48#p446194

Thanks for the links. I edited my original comment earlier and thought I had removed the last line as well (the one you quote) after I double checked the thread you referenced. Obviously I missed it. That's what I get for editing a comment when I'm over tired.

python-imaging upgrade from v.1.1.7.2 to v.1.1.7.3 breaks MintInstall http://forums.linuxmint.com/viewtopic.p ... 11#p447211

zerozero wrote:python-imaging upgrade from v.1.1.7.2 to v.1.1.7.3 breaks MintInstall http://forums.linuxmint.com/viewtopic.p ... 11#p447211

Probably should note that the problem occurs if you're updating from Debian "Testing", not Update Pack 1? (Incoming) Good to know though.

Indeed, update pack 1 provides 1.1.7-2+b1.

When we're at Update Pack 2, we'll bring a fix in mintinstall itself.

Initial thoughts:
The repo is too slow, to the point of being unacceptable. If I was using my local debian repo it would be 6+ times faster.
EDIT: I am assuming you have mirrored the debian repo at a point in time for this debian incomming repo.
If this repo is not going to be replicated by mirror sites (and I dont think any will) I suggest you find a better way of creating/distributing update packs.
You could to somehow hold packages at the versions in the update pack.
This could be done with a meta-package listing all packages and max versions. This could then also use a method like mint update, only enable debian repo when installing/upgrading the update-pack.deb.
This would also save you replicating the debian repo at a point in time. Also saves $$ for the project.
Another advantage of not replicating the debian repo is people could use their closest debian mirror which may not count towards their download limit.

bring back leveling inside the update pack, or some sort of package grouping. Or maybe I have just got use to the preaty numbers and colours.

Cheers
Jamie

I installed mint debian on my new system and installed mintupdate-debian and added the debian.linuxmint.com repo and updated.
It was esentially updating every package, it took forever to DL and has failed to the point that i wil have to reinstall.
ie It went from 1100+ packages installed to 425 and 4 broken, and 301 to be removed. LOL

Boo wrote:I installed mint debian on my new system and installed mintupdate-debian and added the debian.linuxmint.com repo and updated.
It was esentially updating every package, it took forever to DL and has failed to the point that i wil have to reinstall.
ie It went from 1100+ packages installed to 425 and 4 broken, and 301 to be removed. LOL

I did this myself a little over a week ago. Installed the Dec. 2010 (64 bit) release and installed "mintupdate-debian" and pointed LMDE to the new "latest" repository before upgrading (deb http://debian.linuxmint.com/latest testing main contrib non-free). My results were about the same as yours, Boo--8 broken packages and 2 failures by the new MintUpdate to complete the update. However, after installing the original 8 month old release of LMDE a half a dozen times over the past 2 months (just trying new stuff out) I fully expected this to happen and between Synaptic and the terminal I completed the update. To make matters a bit more complicated there were also a few, what I would consider (for everyday users) major tweaks, before I could get LMDE with the revamped update system to boot up without seeing several errors during the boot up process. It always succeeded booting into the desktop but the boot up errors had to be fixed nonetheless. It's been running fine since then with the exception of having no login sound but I also expected this.

I should probably note that if I stay with the original "debian testing" repository for updating rather than the new repositories I always select a mirror repo for updating as trying to drag in well over 1100 updates from the Debian.org server is mind numbingly slow.

The point being is that attempting to do a fresh install of the original LMDE release is pretty much a non-starter now and imho, shouldn't be considered a viable base for any new Mint release as updating a fresh install, even using the new update system, cannot be completed successfully unless the user really (and I mean really) knows what they're doing.

That being said, the LMDE "respin" that's supposed to be coming out fairly soon coupled with the new update system should solve all these problems, yes?

For my first install i used the origional mintupdate before installing mintupdate-debian and changing the repo.
This system is still running great.
I expect the respin to fix most of the LMDE problems.
Anyway off to reinstall the new box, and use the origional method.

kmb42vt wrote:In reference to the problem of system lock up when selecting "Safely remove drive" for a USB connected external hard drive, I installed the latest Liquorix kernel (2.6.39-2.dmz.1-liquorix-amd64) and the problem does not occur. Just FYI.

Also the problem was confirmed by zerozero and a few others on the LMDE Breakages thread.

I actually ran into that problem before with my 1TB WD MyBook USB drive when I was using the testing repos pre update packs. I haven't run into the problem since and I'm sure the issue will be fixed soon based on your feedback.

Like yourself, I also run the Liquorix kernel because I have a Ralink RT2870 chipset (WUSB600N v1) and the Liquorix kernel includes a driver (rt2870sta) instead of the generic one (rt2800usb) in 2.6.38 and above. I find the rt2800usb to have terrible performance with my RT2870 based USB dongle with inconsistent bandwidth and dropped connections. I believe the Liquorix driver is maxed out at 54 mb/sec which obviously doesn't make full use of my N router, but the stability is solid.

It would be awesome if RT2870 support is looked into with these update pack. If its too much of a hassle, I can continue to run Liquorix or manually compile the driver with each kernel update.

@Clem, the nvidia issue is solved with the migration of 07-5 to testing today, so it's safe to include this one in the update pack 2;
Tks

I re-installed a 'fresh' install of LMDE (gnome)

Added the new mint-debian-testing 'incoming' repros, then - updated to the new Mint-Update App - before doing any updates.

The updates took a while, but all went well ... no problems, what-so-ever.

Thanks zerozero, we'll get started on update pack 2 in incoming asap.