The biggest breaker of Arch Linux, ever...

tpowa · 2006-02-21 13:26:05

Just my comment on this,
The main error source of the upgrade problems:
we had a problem with mirrors syncing,
The upgrade itself is smooth if you have the latest packages from a source that contains all packages.
We did the mistake to not stop syncing with mirrors, we will probably do this next time, we moved over 500 packages on this evening, the server went down etc. and then the mirrors synced wrong, well that was a lesson we learned out of it and we will get a new server soon, that will be more robust.
The few programs that have dependecy problems will be fixed very quick.

And also keep in mind, for us it's no fun to see so many systems breaking, we always try to avoid this.
greetings
tpowa

hypermegachi · 2006-02-21 13:59:48

tpowa wrote:

Just my comment on this,
The main error source of the upgrade problems:
we had a problem with mirrors syncing

i hope this is true....cuz xorg in testing went very very very smooth for me. so it was a huge surprise for me to see that everything broke in my system. what was most surprising is that a lot of packages didn't solve their dependencies. gnome and kde both couldn't load applets because the corresponding libxss and libxcomposite were not installed as dependencies. well....pacman -Sy gives me 222 megs of updates right now, so let's hope that everything's fixed.

pikass · 2006-02-21 14:11:44

Woohoo, there you are. I'am quite suprised to see the 'where is the arch spirit gone, i leave immediately' posts that late.

I mean, no one can use Arch in real production stage as server for several services online if one update fucks up everthing.... Then your customers will get you on the phone, loose trust in your skills etc.

And your customer would be right about your skills. Someone who lets pass such an update without testing on productive systems should go and look for another job. (every pacman upgrade is in someway comparable to a dist-upgrade in the apt package system)
Let me explain this on another example:
Every postgres admin should know that databases are incompatible between bigger release changes. So if pacman asks you about upgrading postgres you should be fully aware of the situation and if not, inform yourself before you update because your databases (critcal in productive) may won't come up later. This situation won't appear in let's say Sarge or RH 9, that's exactly why they have their release system. You need to know your apps using arch.

Maybe we should have beside current and extra somtehing like current_conservative and extra_conservative? For those who want to be less bleeding after all? I would be much more work to maintain...

And when would be the time to drop support for these extra repos, which have to contain big parts of the current/extra/community repos and need regular security fixes?
That's the release system Debian, Suse, Fedora, Frugal and most of the others use. Arch is different. Maybe you are using the wrong distro? (Frugal is very similar to arch but without rolling release system)

Pacman's question if he should go on is not just some sort of politeness, take it for real.

bpisciot · 2006-02-21 15:07:41

I have no issues with the bleeding/leading edge nature of Arch. It's why I switched from Slackware. I love running an up-to-date OS, and pacman is a great tool for this.

Nor do I have any issues with the recent major upgrades. Both the devfs->udev and initrd upgrades were announced well in advance. The information for a smooth transition was there for the reading.

My only/major complaint about this upgrade was with the quality/quantity of supporting information and the lack of support tools. Without a working copy of hwd, we were forced into manual creation of a new xorg.conf (at least, I'm not aware of any competing tools). By manual creation, I'm referring to both xorgconfig and Xorg -configure. For many Arch users, this is a tall order since the file needed to be tweaked to get it working.

I may have misread some things, but the announcements of the xorg upgrade were fairly sparse. I do not recall seeing anything about workarounds for the problems many people encountered. The initrd and udev upgrades had clear information about the preparation steps needed.

At this point, this is all quibbling for me, since my new X system is mostly working. I'll bet there are still many other Arch users who are struggling to get their systems back in business.

anykey · 2006-02-21 16:28:29

This is exactly what I am ranting about.

Bleeding Edge is no bad thing per se. But If I really want to do nothing besides configuring xorg a whole freaking day and night long, I can do it with LFS at my leisure.

The step might be bleeding edge, but it is yet to be shown whether all users are friends with that particular upgrade. I mostly managed a couple of friends to be up and running again, I just dont want this to happen too often.

and NO, it is not a solution to get insulting towards criticism with "you are just using the wrong distro, you are not enough an elitist to keep up with arch".

Nowhere have I stated I left Arch, I just do not want this to happen out of the blue like it did.

Well, if there were syncing issues with the repositories, it has just become a great deal more understandable -- which does arise another question: what can be done to prevent this from happening in the future (ie. make a release of $PACKAGE only if all $COMPONENTS have been made available on $MIRRORS when $UPGRADE is being considered by pacman)?

sorry, those brackets above delimit pretty weird a knot.

Neuro · 2006-02-21 16:33:02

The move to udev didn't suprise me, I was already using it myself for a loong while then. As for initrd - I couldn't care less. I've been running a custom-built kernel since I moved to Arch.

Custom kernels.... if you know what you are doing fine never saw any point to it to gain a nano (get it!) second more speed (just update yer hardware!)

It's not about taking that nano second out of your hardware. It's about knowing how your stuff works, not needing 90% of the modules, applying my own patches etc. It's having my system my way.

And as for Xorg... Been running it form testing almost from the beginning with no problems at all. The last update could have caused me a bit of a hassle, but it didn't. I read the news page. I knew that something could cause problems. However, something like a built-in notification system in pacman could be really nice. Like for example: when you do pacman -Syu announces pop out. That would be really handy.

Dusty · 2006-02-21 17:22:35

KISS is dying??

Mr Green · 2006-02-21 17:32:29

noo just takin' a break

loserMcloser · 2006-02-21 17:33:28

hmm, xorg7 upgrade went pretty smoothly over here. only had to make minor adjustments to my existing xorg.conf as outlined in the wiki, and removed some leftover files in /usr/X11R6/.

for those who had trouble and couldn't get on the web to look for a solution/explanation -- lynx is a handy thing to have installed for just such an occasion...

anyways, thanks to the devs for all your hard work, and don't let the complainers get to you!

kth5 · 2006-02-21 18:39:35

it might be that i miss the point behind some people posting in this thread but i believe that someone who needs a day to fix his x11 installation is not even an intermediate *nix user. this is such a common thing to do, that if something like an off-sync-mirror breaks your system, you should be able to figure out what's going on within minutes. know your hardware. :!:

setting up a fresh arch takes only like 20 minutes - substracting the time for downloading the packages. if you need a day to make it perfect to get work done, that's ok. no offense - a day to figure out that the xorg packages are broken and not the local configuration doesn't sound too skilled to me.

anyway, i see a greater problems in other places. i already asked about this on irc:

why do things like xorg7 or udev get announced when they hit the repos an hour ago?

xorg7 has been in testing for quite a while, so most users who left their systems with current/extra only probably forgot about it and felt perfectly safe. then the horror started for them. an upgrade like this should get announced at least 3 days before it happens in my opinion. is a 3 day long delay a thing that cannot go alongside with the bleeding edge?

Mr Green · 2006-02-21 18:56:49

I am not complaining about xorg7 because Arch is a bleeding edge distro & these things are going to happen...

As you say you need to be able to fix your system after all most of us are sys admin, like we maintain our own systems as best we can

udev initrd & now xorg7 are big changes but things will calm down I'm sure

I have had xorg7 working under vmplayer (if slowly!) but it did take some time not sure I want to mess up my main system in that way (/me looks for Archie CD!)

Arch is free (as in beer) & it takes a lot of time + effort to keep things going for that I'm grateful

But I hate not being able to play UT2004 any more lol

cactus · 2006-02-21 19:06:52

if (User.has(valid complaint)) {
echo "You are teh noobish!";
echo "Rolling release && bleeding edge!";
echo "Quit whining! Nobody can ever complain about anything..valid or not!";
echo "You should be using "+randomize(distro);
}

awesome.

I salute anykey. For he has of yet..been one of the only people in this thread to propose action towards some type of prevention/resolution of these issues.

/me tips his hat

apeiro · 2006-02-21 19:17:16

I'll chime in for the heck of it.

First off, my apologies to everyone that has had troubles. Xorg is pretty much the most painful "package" to upgrade, and believe me, it wasn't fun. I think JGC went bald just trying to figure out how to transition to a fully-modular Xorg.

Not that it means a damn to anyone but me, but I didn't have any troubles upgrading here. I ran into a problem with a ttf-bistream-vera conflict, but the wiki page already had it there. So basically, my upgrade procedure went like this:

1. pacman -Syu
2. saw the conflict, followed the wiki instructions
3. pacman -Su (xorg installs properly this time)
4. pacman -S xf86-video-ati (install my proper video driver)
5. restart X

There are a couple reasons I can think of as to why my upgrade was easier than some of yours.

1. I was downloading from ftp.archlinux.org, so there were no mirror sync issues.
2. My xorg.conf has no paths in it, so I had none to change.

I think the mirror sync issue was a big problem for lots of you. This is the first time I can remember where we've had a mirror issue like this, and we'll know next time that mirroring must be disabled until a package move of this size is complete. The whole situation was exacerbated by the fact that our main server is crumpling under the load of syncing mirrors, web, cvsup/abs, aur, and the many people hitting the wiki for help on the upgrade. We're working on getting a better server soon (but that's a topic for another thread).

I think kth5 is right about the announcements. For those of you that blissfully ignore Testing, the xorg7 upgrade was like a bomb dropped on your lap. Not fair. Next time we'll try to warn you in advance so you can prepare (buy a case of beer and a carton of cigarettes -- it makes the upgrades more bearable).

So again, apologies to everyone that isn't having as easy a time upgrading as I did. If you haven't upgraded yet or are still fighting xorg problems, please see these two pages for upgrade info. They do have workarounds for various problems people have encountered, as well as the path changes that are necessary for some people's xorg.conf files.

- http://wiki.archlinux.org/index.php/Xorg7
- http://www.archlinux.org/blog/2006/01/0 … rade-xorg/

- J

Mr Green · 2006-02-21 19:33:34

/me keeps thoughts to myself

polarrr · 2006-02-21 20:04:47

This is just an idea, and probably I sound like an ass saying this, so I'll just mention it for the sake of discussion.

How about add a functionality in pacman that can receive something like a que card from the repo or central server? What I mean by que card is a little list or script the servers tell pacman to ignore packageX for update. Pacman purse the list, and acts like these aren't even on the server for the time being.

The purpose of it would be to wait for servers to synch. So the devs or maintainers can upload the que card a couple of days before the big update that requires all servers to synch to avoid partial updates.

Que card can be either dated to expire (a day or two after the completion of package uploads to allow servers to synch) or devs/maintainer uploads a new list (blank) when deemed ready and new que card writes over the list on client machines, so allowing the client machines to upgrade. To do that, maybe pacman would retrieve the que card from central location rather than from individual server (maybe it would be too costly for the bandwidth, though).

When packages are ignored, pacman can still do the normal operation, but just adds a little message in the end saying "packageX upgrade is on hold awaiting server synchronization" or something along the line. Of course, user can comment out the que card option in pacman.conf or something if he/she chooses.

Like someone else mentioned, it can be used to send a message for the upgrade of certain packages, so when the que card is updated, it will say "packageX will be available in a couple of days...please check wiki/forum/newsletter for info/instruction" or some such.

Or maybe I'm overly complicating things. Ah I don't know. It's just an idea. I hope it's not too dumb. Honestly I don't know a whole a lot about these things.

phrakture · 2006-02-21 20:43:04

Yeah, yeah, ok. I think most of us here get it. The xorg7 upgrade did not go as smoothly as planned.

I'll side with kth5 in wondering why there wasn't alot of information made available before the upgrade, but I'm not going to sit here and scream and yell.

Yes, the upgrade went fine for me (except that I was using nethack at first, which had sync issues). That's not the point.

We're all well aware that things broke. We're all well aware that things can be fixed. So let's focus on that.

It seems the biggest puzzle piece here is missing information. I charge all of you here to add just one piece of information to the wiki. If every person in this thread adds one sentence to the Xorg7 upgrade wiki, the information will be complete.
I'm not excusing anything. I'm simply saying "hey, it happened, let's move on and fix it" - people are still having issues with Xorg upgrades. Let's make sure that, in the true spirit of a community working together, we can learn from our collective mistakes. People will run into issues on a new install, and if there's no where to get help, they will be at a loss.

Let's all try and be constructive, and see what we can do.

cactus · 2006-02-21 21:16:30

I agree with phrakture. We have said our piece. Now lets move on.

ozar · 2006-02-21 21:43:22

cactus wrote:

We have said our piece. Now lets move on.

Yep, I agree...

My purpose for opening this thread was meant only to see if anyone remembered there ever being a bigger "breaker" of Arch, and it appears that my suspicions have been confirmed, so I'm all for locking this thread "at the thread starter's request" if there's an admin/mod that wants to lock her up. If not, that's okay, too.

Thanks for the input, everyone.

ozar

Dusty · 2006-02-21 23:17:30

aww, come on, I was just starting to have fun. Oh well, at least I get the last message. 8)

Dusty

dtw · 2006-02-22 09:31:03

Do you?

Dusty · 2006-02-22 16:30:05

Always. 8)

hm, a new sport, locked thread hijacking...

Arch Linux

#26 2006-02-21 13:26:05

Re: The biggest breaker of Arch Linux, ever...

#27 2006-02-21 13:59:48

Re: The biggest breaker of Arch Linux, ever...

#28 2006-02-21 14:11:44

Re: The biggest breaker of Arch Linux, ever...

#29 2006-02-21 15:07:41

Re: The biggest breaker of Arch Linux, ever...

#30 2006-02-21 16:28:29

Re: The biggest breaker of Arch Linux, ever...

#31 2006-02-21 16:33:02

Re: The biggest breaker of Arch Linux, ever...

#32 2006-02-21 17:22:35

Re: The biggest breaker of Arch Linux, ever...

#33 2006-02-21 17:32:29

Re: The biggest breaker of Arch Linux, ever...

#34 2006-02-21 17:33:28

Re: The biggest breaker of Arch Linux, ever...

#35 2006-02-21 18:39:35

Re: The biggest breaker of Arch Linux, ever...

#36 2006-02-21 18:56:49

Re: The biggest breaker of Arch Linux, ever...

#37 2006-02-21 19:06:52

Re: The biggest breaker of Arch Linux, ever...

#38 2006-02-21 19:17:16

Re: The biggest breaker of Arch Linux, ever...

#39 2006-02-21 19:33:34

Re: The biggest breaker of Arch Linux, ever...

#40 2006-02-21 20:04:47

Re: The biggest breaker of Arch Linux, ever...

#41 2006-02-21 20:43:04

Re: The biggest breaker of Arch Linux, ever...

#42 2006-02-21 21:16:30

Re: The biggest breaker of Arch Linux, ever...

#43 2006-02-21 21:43:22

Re: The biggest breaker of Arch Linux, ever...

#44 2006-02-21 23:17:30

Re: The biggest breaker of Arch Linux, ever...

#45 2006-02-22 09:31:03

Re: The biggest breaker of Arch Linux, ever...

#46 2006-02-22 16:30:05

Re: The biggest breaker of Arch Linux, ever...

Board footer