HEADSHOT! 2011/6/30 Greg KH <gregkh@suse.de>:

On Thu, Jun 30, 2011 at 04:41:13PM +0000, Joe User wrote:

...

Users who want systemd can choose it during install. But it's too big a change to be the default choice. I don't want to change, until it's been proven and polished for several years.

I'm sorry to hear that, there are some distros that do provide you the choice of this, but I don't think that openSUSE will be one of them. Perhaps you might wish to switch to one of them instead?

...

I'm also opposed to dumping everything into /usr. I *like* having /bin vs. /usr/bin, /lib vs. /usr/lib, and /sbin vs. /usr/sbin.

What does that have to do with systemd?

...

If you need shared read only mounts for executables, then improve mount and/or the kernel so you can easily mount multiple paths all at once, to the same device. Don't force your organizational prejudices on me.

I don't understand the complaint here.

...

I'm a user, and I want what I want.

That's nice, but you also need to realize that things change, and they do so for good reasons.

...

Question is, do you want users, or not?

It sounds like openSUSE doesn't fit your neads, perhaps you might want to try out Debian?  They offer the ability to support many different types of configurations at once, and they suffer the problems that this incurs, but that might be better for you.

Best of luck,

greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-- Nelson Marques /* http://www.marques.so   nmo.marques@gmail.com */ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 30 June 2011 18:57, Joe User <iam.joeuser@gmail.com> wrote:

On Thu, Jun 30, 2011 at 5:06 PM, Greg KH <gregkh@suse.de> wrote:

...

...

Question is, do you want users, or not?

...

It sounds like openSUSE doesn't fit your neads, perhaps you might want to try out Debian?

Does your employer share your disdain for users?

Rather than switching, I would prefer to see you and your cohorts fired from your paying jobs. As independent members of the community, your arrogance would be more credible.

I'm sure Greg suggested Debian, because it has a reputation for stability and avoiding early adoption of new technologies; with support of alternative kernels & features because it's easier to provide them, than it is to have consensus. I would love to see the early boot fixed, so things can block on the filesystem parts where a mount is outstanding (bit like network filesystems do), but it's things like bluetooth support hooking into udev and not init(8) that wants /usr/{bin,lib} to be part of root filesystem, whether sysV init, systemd or Upstart. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thu, 2011-06-30 at 17:57 +0000, Joe User wrote:

On Thu, Jun 30, 2011 at 5:06 PM, Greg KH <gregkh@suse.de> wrote:

...

...

Question is, do you want users, or not?

...

It sounds like openSUSE doesn't fit your neads, perhaps you might want to try out Debian?

Does your employer share your disdain for users?

Rather than switching, I would prefer to see you and your cohorts fired from your paying jobs. As independent members of the community, your arrogance would be more credible.

It seems like you're the one with the actual disdain and arrogance here against the community. Joe, you seem to have a very strange interpretation of how the openSUSE Project works. Things move forward based on consensus and initiative. The community, which just so happens to have people employed by certain employers, are not directed by our primary sponsor. It is a project that thrives on mutual collaboration and a desire to maintain a quality community-based distro. That's not to say that we,, as a community, make perfect decisions every time, but we certainly relish positive and open dialogue with meaningful input about why we should go in one direction or another. You're making claims such as implying that we don't want users. Last time I checked, we were all users and we are all in this together. It was the community that argued for and pushed for systemd and it is the community that is rolling up its sleeves to make it work for openSUSE. If you have legitimate issues about why systemd should not be here, or if you find that it is too buggy, please provide some reasonings and file bug reports. SysgtemD (or any new technology implementation) will never work if we just split up into two camps of "I wanna"s and "I don't wannas". And let me make one more point here. Making insinuations against someone simply because of their employment is grossly out of bounds. We, in this Project, take pride in seeing every contributor here as individuals, not as employee vs. non-employee. No employee makes an overriding decision against the community and that's the way its been and will continue to be. Now, as for Greg making recommendations to consider other distros. I think that was a wise and very positive thing he did. Many of us admittedly are so loyal to openSUSE that we wouldn't dare to think of pointing to other distros. But he gave you a very nice and fair and impartial recommendation to consider a distro that fits your needs. And that was the right thing to do. If any one of us thinks there's a one-distro-fits-all out there... you're living with a pie in the sky. It is virtually impossible to ever achieve that, no matter how much we would love that for openSUSE. Sincerely Bryen M Yunashko openSUSE Board Member -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Bryen M. Yunashko wrote:

Joe, you seem to have a very strange interpretation of how the openSUSE Project works. Things move forward based on consensus and initiative.

So what was the 'consensus' on systemd? By my last understanding, it was that it would be made to support a separate /usr partition -- by forcing it to mount the hard disks first, before starting all the 'application' software that depends on /usr.... But that was my impression.... I'm just wondering if that was my wishful thinking or if that was really the consensus.... since if it wasn't the case, then I question the idea of it being consensus driven.... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Greg Freemyer wrote:

Linda, A status email for systemd came out today. It listed making it possible for /usr to be mounted early as a todo.

But the systemd maintainer also said it was not something he could address and was looking for developer help to make it a reality. ... I also never got an answer to my question about systems being upgraded. Is the plan to leave the current init system in place for those systems, or will 12.1 have a forced migration to systemd. Maybe that can't be answered yet, but I saw no feedback at all from the maintainers, etc.

Thanks for the update. Can I ask a question about this....and maybe someone could explain why this would be 'infeasible' Why not have 'init' start things as it does now up through the 'boot' scripts', then turn starting 'services' over to the task of 'systemd' when hardware to serve all the user -level application programs that expect it to be there during the 'startup' process? I.e. a Hybrid approach? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Fri, 1 Jul 2011, Linda Walsh wrote:

Linda Walsh wrote:

...

Can I ask a question about this....and maybe someone could explain why this would be 'infeasible'

Why not have 'init' start things as it does now up through the 'boot' scripts', then turn starting 'services' over to the task of 'systemd' when hardware to serve all the user -level application programs that expect it to be there during the 'startup' process?

I.e. a Hybrid approach?

---

Sorry let that off a bit before I fleshed it out... But the line between what comes before and what comes after, presumably would be something that could change in the future, as parts of the 'boot' scripts' that were (are) known to be safe to execute concurrently with other system startup processes, could be moved there as well...

It might even allow a stepping stone approach to moving toward systemd, as support is included to support things like early mounting, etc.... as those things are added, more processes/scripts could be turned over to systemd on subsequent releases....

This way, it seems like it could have be benefit of not having a major jolt or incompatibility worry...?

Just a thought, but everytime I try to rush to do something I'm almost guaranteed to 'miss something'....

I really like Linda's idea of a "hybrid approach". It would avoid the initial (huge!) disturbance systemd would serve us, and allow a smooth way to a "total" conversion when systemd really is ready, step-by-step. Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Moenkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen (GWDG) Am Fassberg 11, 37077 Goettingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschaeftsfuehrer: Prof. Dr. Oswald Haan und Dr. Paul Suren Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Goettingen Registergericht: Goettingen Handelsregister-Nr. B 598 ------------------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 2 July 2011 01:03, Greg KH <gregkh@suse.de> wrote:

On Sat, Jul 02, 2011 at 01:11:45AM +0200, Eberhard Moenkeberg wrote:

...

Hi,

On Fri, 1 Jul 2011, Linda Walsh wrote:

...

Linda Walsh wrote:

...

...

Can I ask a question about this....and maybe someone could explain why this would be 'infeasible'

Why not have 'init' start things as it does now up through the 'boot' scripts', then turn starting 'services' over to the task of 'systemd' when hardware to serve all the user -level application programs that

I really like Linda's idea of a "hybrid approach".

It would avoid the initial (huge!) disturbance systemd would serve us, and allow a smooth way to a "total" conversion when systemd really is ready, step-by-step.

No, systemd is designed to be init, and expects to run as init, so doing something like what you are mentioning would actually be more work than just doing the systemd integration properly.

And again, the remaining systemd tasks have all been described quite well, and you can test today, in Factory or Tumbleweed if you want to. Please let people know what is not working properly for you so it gets fixed in time for 12.1.

Furthermore it IS NOT systemd that requires /usr to be in /, but the application hooks for things like Bluetooth into udev! systemd just prints a warning about running a flakey unsupported configuration. It is the initrd responsibile for mounting / and populating /dev from a minimal "memory" Linux environment, that would need to be changed to know how to mount /usr. What ppl really want is not startup to be delayed until all the local filesystems are mounted, but to have some path resolution block when they hit scheduled mount points that haven't been completed (started even) yet so it's much finer grained, effectively like network automount but on any mount point. But again, even with that kernel support udev would have to be altered to expect rules to block, and a list of future mount points would have to be loaded to block on them. In old days, it would take ages for an array of disks to spin up, then you had some long fsck(8) checks on some Archive, which kept the whole machine out of service, when it COULD already be serving home directories & routing email say. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Per Jessen wrote:

Rob OpenSuSE wrote:

...

In old days, it would take ages for an array of disks to spin up,

Staggered spin-up is still the norm.

I have 24 external and 8 internal RAID disks (3 are 15K SAS, the rest are 2TB SATA), ... My init-d start takes all of 20 seconds -- that's with all disks mounted and my disks are set for auto-spinup -- but that happens during BIOS initialization and adds no noticeable time over an empty controller.... So...it is only a 2.6MHz CPU (2x4core), so it's NOT because it's a fast CPU... What benefit is systemd going to give me that will be worth _any_ hassles. I don't need a ram disk to boot from. I boot directly from a system image on the harddisk. I realize that's NOT a something that would easily work for if one wanted to maintain 1 generic kernel that has all options builtin (though having an option to auto-build a kernel with the necessary drivers for boot on a given system, as a 'post boot' optimization step', for faster booting, would certainly be "lower impact" than forcing people to throw away current disk partitioning. Unless you are looking for close to 'instant' on, systems, I'm not sure how much incremental benefit systemd is going to be delivering. If you DO want such a system, booting off a SSD, would be the way to go and not wait for any spinups. You might still have to mount separate partitions for people who still want the 'walls' of separate partitions between different system-usage foci, but you wouldn't have to wait for spinups. What type of benefit is expected to be coming from systemd over what I already have -- knocking 50% off of init's startup would save me 10 seconds. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rob OpenSuSE wrote:

On 4 July 2011 08:10, Linda Walsh <suse@tlinx.org> wrote:

...

Per Jessen wrote:

...

Rob OpenSuSE wrote:

...

In old days, it would take ages for an array of disks to spin up, Staggered spin-up is still the norm.

---

I have 24 external and 8 internal RAID disks (3 are 15K SAS, the rest are 2TB SATA), ...

My init-d start takes all of 20 seconds -- that's with all disks mounted and my disks are set for auto-spinup -- but that happens during BIOS initialization and adds no noticeable time over an empty controller.... So...it is only a 2.6MHz CPU (2x4core), so it's NOT because it's a fast CPU...

What benefit is systemd going to give me that will be worth _any_ hassles.

As https://features.opensuse.org/310327 says, "systemd provides aggressive parallelization capabilities,

Which, AFAICT (can tel) buy me nothing.

uses socket and D-Bus activation for starting services,

Which ... same as above...

offers on-demand starting of daemons,

Possibly interesting.

keeps track of processes using Linux cgroups,

Current kernel auto-cgrouping implemented in 2.6.38 works great! Used to be if I ran a kernel build with "make -j", it would cause my server to get a bit sluggish, so I'd have to limit it if I didn't want other things (like editing via 'X', file-serving and http-access via squid) to be affected. Now, with the auto-cgrouping, even with a load over 800 during the 112s build (cold cache, cleaned source dir), Nothing else is bothered. So...why do I want something to mess with this?

snapshotting and restoring of the system state,

Using any file system? Or would I have to change that too?

maintains mount and automount points

Linux and automount already do that.

and implements an elaborate transactional dependency-based service control logic."

Complexity = bugs and problems. i.e. sounds bad. with no benefit.

Apart from that, it means openSUSE project share code with other distro's rather than maintaining own parrelised Sys V Init.

---- Oh. Well, that's always a good reason -- if they all switch to a BSD kernel will we as well?

Upgrading a distro release, will always bring "hassles", it's a trade off on the benefits. Big Iron deployments do not have a hope in hell, of holding back a community distro, the on-demand demon starting helps many by saving memory on startup & avoiding need to disable unused daemons, lowering maintenance & support issues.

---- Big iron? *cough*.... The base server was <2K (it's gotten additions since I bought it). It's a home server that replaced my 10-y/o dual P-III (1GHz!) workstation that was my previous server. (most expensive part is buying the disks)....

FWIW Sys V init was new at one time, and WE hated it, as it was slow & over engineered, I remember it taking minutes to change run levels, when "simply using rc.local" was so much simpler & faster and what did we need all that start/stop crapola when we could just SIGHUP the daemon or kill it ourselves.

While now it takes seconds.

Things change..

Yup... The only reason that I would find useful is the source-sharing and being more like other distro's (yeah, while I nay-say the sheep aspect, that doesn't mean it wouldn't have benefits)... Don't get me wrong -- I'm NOT saying -- ultimately, that we shouldn't go with systemd, it sounds like 'next gen' (like ng-syslog did before we abandoned it... hmmmm....wonder if there is a lesson in there)... But I don't think there needs to be a such a rush to adopt systemd, that little details, like making sure local file systems are mounted and running before 'consumer device networks' (that would likely want to access those local file systems - or are you suggesting that people's home directories ALSO be on the root partition?). I love 'change' -- but not breakneck speed where I risk my neck and ability to use my system. When I upgrade my server -- I'm 'offline' for as long as it takes to get that server backup -- it's my sole means of internet access. So having problems that require disk reformatting and repartitioning just to upgrade are not my ideal scenario... -l -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Vincent Untz wrote:

Le lundi 04 juillet 2011, à 00:10 -0700, Linda Walsh a écrit :

...

What benefit is systemd going to give me that will be worth _any_ hassles.

The systemd benefits have already been explained in several threads, that are archived. As well as a current set of integration issues.

Can we please stop discussing the same thing again and again? This makes this mailing list much less useful than it should be.

In Knode: just hit 'I' to ignore a thread that doesn't interest you. Works very well. -- Per Jessen, Zürich (16.8°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Vincent Untz wrote:

Le lundi 04 juillet 2011, à 00:10 -0700, Linda Walsh a écrit :

...

What benefit is systemd going to give me that will be worth _any_ hassles.

The systemd benefits have already been explained in several threads, that are archived. As well as a current set of integration issues.

'context' I was trying to say that while it provides many benefits, the incremental benefit over what is already in place doesn't justify a rush to put it in place without making sure that existing setups won't be destroyed/made obsolete. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, 11 Jul 2011, Brian K. White wrote:

Any init replacement for a "professional" "polished" distro like suse should _start_ with a mode in which it behaves exactly like current init so that it can be dropped into an existing system without breaking anything, and admins can set up new systems using existing working recipes without problems or unpleasant surprise factor.

Unlike another well known distro that I tried in June, openSUSE contributors have actually adjusted OpenVPN (and more) before even thinking to unleash systemd by default in a release. And thanks to the efforts of Frederic, Kay, AJ, and others it's looking increasingly better and there are months left to fix any outstanding issues.

but suse did so better than other distro's. If that's no longer true, then of what value is suse any more?"

It's still true, and a core value our distros provide! For that reason, if you have any concrete issues, we'd love to learn about them in Bugzilla. Gerald -- Dr. Gerald Pfeifer <gp@suse.com> || SUSE || Director Product Management -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thursday 30 June 2011 21:06:03 Greg KH wrote:

...

Users who want systemd can choose it during install. But it's too big a change to be the default choice. I don't want to change, until it's been proven and polished for several years.

I'm sorry to hear that, there are some distros that do provide you the choice of this, but I don't think that openSUSE will be one of them.

Why do you think so? Actually openSUSE usually provides nmore choice than Fedora/Debian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 6/30/2011 2:10 PM, Greg KH wrote:

On Thu, Jun 30, 2011 at 10:01:42PM +0400, Ilya Chernykh wrote:

...

On Thursday 30 June 2011 21:06:03 Greg KH wrote:

...

...

Users who want systemd can choose it during install. But it's too big a change to be the default choice. I don't want to change, until it's been proven and polished for several years.

I'm sorry to hear that, there are some distros that do provide you the choice of this, but I don't think that openSUSE will be one of them.

Why do you think so? Actually openSUSE usually provides nmore choice than Fedora/Debian

Than Debian? Seriously? Have you seen the different ways you can run things on there these days? With/without udev/hal/systemd/etc. are all "supported" as are other types of configurations and architectures that openSUSE and Fedora rightly don't support.

Now I personally like the way openSUSE handles this, and believe that you need to make some choices at some levels in order to provide a coherent system that works well together. Debian and Gentoo allow the users to make those choices much better than openSUSE and Fedora, and that's an explicit choice of all of these distros.

debian is not myspace, and opensuse is not facebook. I'm completely with Joe User. As one who has to maintain a bunch of boxes and has to spend a lot of time devising atomated procedures and training non-admins who never the less have to do adminly stuff because I cannot always be available, every backwards incompatible change, every change in default behavior, every thing that breaks because of little or no testing prior to making it part of the official system costs me lots of time I and my employer and my customers would rather I be spending doing other new stuff rather than just playing keep-up-with-suse just to maintain what I already had. Your passive aggressive remark is more true than I think you realize or than maybe Novell would wish. It's only inertia that has had me still using opensuse this long. I'd already invested a lot so it simply takes a lot of bad before it becomes rational to jump. But the overall nature of progress lately has gotten kind of slipshod and spotty. Things that used to work either no longer work or are removed entirely for lack of developers to maintain them. Decisions made that affect everyone for insufficient reasons and with insufficient gain in return for the pain. When I finally dig in and set up an archos or debian version of my production system, I may find that it's even harder to develop a consistent, scalable, reproduceable, maintanable, dependable system there. Maybe the grass isn't greener over there. But the point is, now I'm becoming more and more driven to find out. I didn't pick openSUSE by accident in the first place. This was very definitely the greenest grass when considering lots of different factors including projected admin environment stability across versions, based on history up to that point and speculation based on knowledge of the company and their likely plans and likely success. I knew I would some day hav lots of different boxes of lots of different ages and versions and I knew it would matter how much and in what ways those versions differed from each other. I can't have radically different education needed for each new box. I can't be the only one in my company who dares touch anything. I need to be able to tell some basic things to several of my other developers and know that it will be true on all boxes without requiring them to be so observant and knowledgeable that they can spot when it's wrong for some box, let alone figure out the new equivalent. I knew on linux this would not actually be possible to the impeccable extent that it was on SCO, but I knew if a distro cared to try, it could come pretty close without giving up the normal march of linux progress and if a distro didn't care to try then it could be utter unsupportable chaos. I didn't land here by accident and for a while at least I had no slightest interest in looking for a better platform to invest time in and to rely on. This isn't a case of yet another fickle user. But as the saying goes past performance and all that. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 6/30/2011 6:53 PM, Cristian Rodríguez wrote:

El 30/06/11 18:34, Brian K. White escribió:

...

Your passive aggressive remark is more true than I think you realize or than maybe Novell would wish.

Im not sure if you have read the news, but Novell and SUSE have parted ways. and Attachmate is a separate company too.

This of course has nothing to do with openSUSE.

Of course the perceived quality and usability of the precursor development and community beta test platform for SLES/SLED has nothing to do with the people who have to somehow sell SLES/SLED. How silly of me. If one is a long time openSUSE user and abandons it because development quality and thoroughness is not up to former standards, it's not exactly likely to be for SLE. Neither are they likely to be recommending SLE it to friends or selling it to customers. This relationship really needed to be explained or are we just failing at being pedants? -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 2011/06/30 15:54 (GMT-0700) Greg KH composed:

So what have we done that break things that were not fixed?

Daily/constantly I'm reminded of https://bugzilla.novell.com/show_bug.cgi?id=584493 on boxes running openSUSE kernels but not on openSUSE running vanilla kernels or in other distros. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Felix Miata wrote:

On 2011/06/30 15:54 (GMT-0700) Greg KH composed:

...

So what have we done that break things that were not fixed?

Daily/constantly I'm reminded of https://bugzilla.novell.com/show_bug.cgi?id=584493 on boxes running openSUSE kernels but not on openSUSE running vanilla kernels or in other distros.

Moving to grub, before it was ready... and thus dropping support for XFS for a while (not sure if it is officially supported again, yet, or not, but still seem to remember getting a message about boot problems with root on XFS in last install). and dropping support for booting from YOUR HARD DISK (instead of a RAM DISK); As a result of this, and not using the SUSE boot-ram-disk, with all it's hidden operations, I wasn't able to get output turned on the console until AFTER full boot (login prompt). With suse kernel -- got full kernel output during bootup, with a vanilla kernel booting with no-ram disk, was not able to get it to give any output -- same kernel with lilo loads fine (this was earlier in the 11.x series, don't know about now, dropped grub and haven't looked back!). Also -- a consequense of the above -- the LSM mount code is not in it's own RPM but is part of the boot-disk package making it impossible to easily upgrade. As a result, I lost the ability to do snapshots in 11.2 after some kernel update about a year ago.... Required a knew lvm lib...but that was part of the boot rpm and well enmeshed!... (Maybe it will work now on 11.4, but am a bit wary of trying it, since once opened, there was no way to close a snapshot (it would just eventually overflow and become corrupt)... Or support for linking modules into the kernel, vs. dynamically loading them -- several RC scripts would fail trying to load a module that was already loaded... not bother to check /sys/modules....) There's been TONS of issues over the years with each new update making the boot process more difficult and making everything that follows more difficult. (Like not being able to update LSM, without updating my boot-ram disk which I didn't use...)...etc... And those are just examples off the top of my head from the past few years... Linda -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 2011/07/01 19:09 (GMT-0400) Adam Tauno Williams composed:

SIMPLE RULE: Create a 256MB ext3 /boot partition. I do this on every box running any distro - and as I said - I've never had a boot issue. Then put everything else in LVM on whatever filesystem you like.

Even simpler, dispense with the journal. It's extraordinarily infrequently of any necessity on a partition so infrequently written to. Mine are simpler in a way, 200M ext2, mounted as /disks/boot once I have Grub on it, and I'm the only writer to that partition once Grub's installed initially. No installer programs or updaters will foul up bootability, only me. :-) -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 2 July 2011 02:41, Linda Walsh <suse@tlinx.org> wrote:

Adam Tauno Williams wrote:

...

XFS works well, I've never noticed it not supported.

SIMPLE RULE: Create a 256MB ext3 /boot partition.  I do this on every box running any distro - and as I said - I've never had a boot issue. Then put everything else in LVM on whatever filesystem you like.

Um...

       your idea of 'advanced' and mine aren't the same.   My advanced includes specifying the mount params on my xfs partitions  -- INCLUDING the root partition.

       If I used your setup, I'm pretty sure my system would not boot, since I'm pretty sure, IF I built in ext3 support in my kernel, at best, it would be a module, located on the XFS boot partition.

The modules in the initrd which is loaded into memory via BIOS calls like the kernel, are copies of ones required to mount '/', so the full /lib/modules & /lib are available, as well as commands in /bin & config in /etc. So long as the initrd's are built right, then '/' can be mounted via modules, supporting software RAID, LVM as well as "exotic" filesystems. There was a post on this list few years ago, explaining the problems for the YaST Perl Bootloader, GRUB and XFS, which meant it was unsupported due to it's YMMV nature in the general. lilo may have worked as it uses block lists, rather than read the filesystem format, but that fails on system like BTRFS with auto-defragmentation planned. I've also seen bugs to do with Suspend to Disk and journaled filesystems, because the journal may need replaying & GRUB doesn't have the capability; the obvious solution to put the filesytem in clean state before suspending, is problematic as they don't have way to freeze new disk transactions on a running system. GRUB can however use (for reliability possibly only as fallback) copies of the distro "/boot" files, from a partition that's usually not mounted. It just means self updating of Menu file and adding new kernel files to the /real/GRUB/boot partition. Then there's little need for "advanced" file sytems with journalling, and you get around the restrictions on new filesystems like BTRFS. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

An alternative idea to help work round the desktop developers dislike of worrying about / & /usr/{bin,lib/etc} seperation issues. On 2 July 2011 20:33, Linda Walsh <suse@tlinx.org> wrote:

Rob OpenSuSE wrote:

...

       I said: I'm booting from my Hard Disk -- Not from a RAM DISK.

There is no 'initRD'.   Thus there are no drivers available to the kernel until it mounts the disk.   Maybe it was in a different thread, but I had problems getting my own kernel to boot properly from the suse initRD. For some reason I couldn't get any console output during boot until I hit the login prompt.

So it indeed booted with an initrd but you found a bug about console output... I thought this was a general discussion about systemd and distro support for boot process, my response was not intended as specific comment on your personal choice of setup, including self building a kernel; though I advised ppl not to bother with that and use generic, from SuSE 7.1 or so, and Red Hat 6.0 days; as the fashionable optimisation at time, was IMO more trouble than it was worth for 99% of newish systems..

you can have race conditions -- AND a journaling file system only adds to those potential problems. However, as I understand it, Grub was fixed some time ago.

Now I just noticed watching a hibernate on my Tumbleweed box that the kernel, is now "freezing" applications and quiescing the disk, which is a new feature which crept under my radar. That actually works more generally, than GRUB code (16 bit?) having to deal with all the complexities of FS's like ReiserFS & BTRFS in a "live" state. Isn't it great that Linux is developing, improving and changing at a pace, rather than being STUCK for the convenice of some Enterprise SA department who love paper pushing & certification! :) Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 6/30/2011 6:56 PM, Adam Tauno Williams wrote:

On Thu, 2011-06-30 at 18:34 -0400, Brian K. White wrote:

...

As one who has to maintain a bunch of boxes and has to spend a lot of time devising atomated procedures and training non-admins who never the less have to do adminly stuff because I cannot always be available, every backwards incompatible change, every change in default behavior, every thing that breaks because of little or no testing prior to making it part of the official system costs me lots of time I and my employer and my customers would rather I be spending doing other new stuff rather than just playing keep-up-with-suse just to maintain what I already had.

(a) Turn off updates; just apply them at maintenance windows. There really is no need to "keep up" if things are working well. Test and deploy, don't deploy-as-test.

(b) As someone who primarily admins CentOS [the most boring distro ever] and Windows servers.... get over it. This will *always* be true to some extent. Systems change, you need to adapt to those changes.

How does turning off updates on a given box or all boxes adress anything I said? Updates do not cause os version upgrades, and nothing changes too radically within a given version for the life of that version. For example how does turning off updates address the fact that on a given piece of hardware, it was possible to install 10.3 successfully using only the normal installer onto a fully software raid setup, and have it create a working grub that actually booted and worked, yet on later versions the exact same setup on the exact same hardware didn't work and the only way to get the box running was to jump to another vc or ssh session and manually edit grub files and/or manually create the mdadm arrays before that. How does turning off updates address the fact that the repair-system and boot-installed-system options disappeared from the installer? Hey I know those are hard things to do. What's damning is that openSUSE used to do them and now doesn't, or tries but now fails a lot more often. Things like that were part of what made SUSE stand out in the first place. Then there is the long standing difficulty of using a serial console. Several hard coded assumptions in openSUSE are broken for a serial console but whatever who uses those? So on all my boxes I have to be careful to uninstall and taboo all the gfxboot and splashy stuff before allowing it to boot the first time. And I had fun the other day when a new box crashed during boot every time until I discovered the wonderful new KMS trying to touch my video card that doesn't even have anything connected to it. vga=normal which I already had was being ignored and after some googling I find out about the new nomodeset or i915.modeset=0 This is new, active behavior that's on-by-default and broke a box that worked fine on the previous version. Of course everyone wants their video card diddled with early in the boot process, of course it should be in there by default unless you go out of your way to disable it. And then once booted, as has been the case since I don't know when but at least 10.0, (I have older boxes, I just wasn't using serial consoles then) something somewhere in bashrc keeps going out of it's way to make a bonehead assumption about the size of my screen based on the value of $TERM and the tty device name!!! So, certain yast screens are actually broken, missing buttons and controls and displays because LINES & COLUMNS keeps getting set to 80x24 when those screens need at least that missing 25th line, let alone the fact that I'm usually on a 132x50 terminal. Not only should such assumptions never be made, they certainly shouldn't be overridden if I manually SET them. Even when I set them and readonly them, still some things are broken. Sometimes my terminals window size gets set to 80x25 by some ansi codes and I have to reset the terminal to clear that, even while LINES & COLUMNS are readonly set to 132x50. It's so stupid that I have to fight against that while I'm trying to deal with some sort of emergency that required me to use the console at all, and forget trying to explain this to any other employees. "if the array doesn't start up because of a crash or power loss, here's how you access the console ... oh yeah it always does that ahh there's not really a fix you just have to ignore that junk and try to navigate the garbled screen anyways... " Completely professional. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 7/1/2011 4:41 AM, Rob OpenSuSE wrote:

On 1 July 2011 02:06, Brian K. White<brian@aljex.com> wrote:

...

On 6/30/2011 6:56 PM, Adam Tauno Williams wrote:

...

On Thu, 2011-06-30 at 18:34 -0400, Brian K. White wrote:

...

As one who has to maintain a bunch of boxes and has to spend a lot of time devising atomated procedures and training non-admins who never the less have to do adminly stuff because I cannot always be available, every backwards incompatible change, every change in default behavior, every thing that breaks because of little or no testing prior to making it part of the official system costs me lots of time I and my employer and my customers would rather I be spending doing other new stuff rather than just playing keep-up-with-suse just to maintain what I already had.

...

How does turning off updates on a given box or all boxes adress anything I said? Updates do not cause os version upgrades, and nothing changes too radically within a given version for the life of that version.

For example how does turning off updates address the fact that on a given piece of hardware, it was possible to install 10.3 successfully using only the normal installer onto a fully software raid setup, and have it create a working grub that actually booted and worked, yet on later versions the exact same setup on the exact same hardware didn't work and the only way to get the box running was to jump to another vc or ssh session and manually edit grub files and/or manually create the mdadm arrays before that.

How does turning off updates address the fact that the repair-system and boot-installed-system options disappeared from the installer?

Hey I know those are hard things to do. What's damning is that openSUSE used to do them and now doesn't, or tries but now fails a lot more often. Things like that were part of what made SUSE stand out in the first place.

Then there is the long standing difficulty of using a serial console. Several hard coded assumptions in openSUSE are broken for a serial console but whatever who uses those? So on all my boxes I have to be careful to uninstall and taboo all the gfxboot and splashy stuff before allowing it to boot the first time.

...

vga=normal which I already had was being ignored and after some googling I find out about the new nomodeset or i915.modeset=0 This is new, active behavior that's on-by-default and broke a box that worked fine on the previous version.

So I start off having sympathy with what you said. But may be you ought to consider, things you can do to minimise the issues, apart from the obvious switching to SLED/SLES for longer term support. But 10.3 was horrible release for me initially, I had huge number of problems to sort and it was months before it became stable& super solid. My honest impression is 12.1 M2 is far more solid& useable than any of the GM releases I've tried; I think things really are getting better& more mature.

Requiring redundant features to be on install DVD, when you can use a System Rescue, or build your own Live CD/DVD is not rational.

Suggestions

* Don't track the latest release on production systems, until they're solid for you. 11.3 works well, actually 11.1& 11.2 plus Evergreen do to * Use Auto Yast to get rid of the boot gimmicks. Even lilo is still there and useable. * Use Kiwi or SuSE Studio to allow test of hardware with Live DVD before upgrades, similarly repair of systems * Actually read the Release Notes, things like nomodeset=0 are well explained * Software RAID is easy enough to configure, post install, if you plan for it. Given all the testing required to proof against single disk or controller failure, a pro sysadmin ought to cope with building software RAID themselves, it allows installing into a degenerate mirror for example * Don't work on Live Production machines, roll out a new server, then upgrade the old one after the new is "signed off"

The possibilities for well tested transitions have never been better. Plan for them by dual booting and try out "zypper dup", with a suitably configured proxy as an installation& update cache it should fly.

If you don't want improvements, or problems of early adoption use an old supported release on production and pay for it! If you use a community release in production, it's wise to test things like milestones, so you can point out overlooked downsides in new features and hopefully influence developers before it's too late (adding /usr "hooks" into udev for example).

If there weren't changes, then there'd not be a need for skilled sysadmins, so it's in our interest to embrace and enthuse about them!

Regards Rob

When I say things changed, disappeared, stopped working on the same hardware etc, I did not say and did not mean to imply that I stupidly upgraded production machines and just hoped it would all go perfect and then was in trouble when it didn't and that this was openSUSE's fault. I did no such thing ever. I absolutely can not in-place upgrade production boxes for several reasons, each of which is sufficient by itself let alone all together. I did install different versions on the same physical box but that was while it was not a production box. As for the pointers how to get around distro failings. I already know all those and rather more and can devise whatever I need on demand. The point is that I originally chose this distro because I was willing to give up some amount of customization in trade for an OS that did more things more automatically and more reliably. IE, rather than edit any config file the exact most elegantly optimal way I might want, it was more valuable in my context where I want to ensure other people besides me can do some things more or less safely when I'm not available, I was willing to accept the structure and limits imposed by yast in trade for, yast actually working really well. That falls apart if yast starts to become flaky and parts of it become untested, unsupported, and then disappear. So, sure, I know all kinds of ways to circumvent the distro supplied scripts, packaging, and admin tools, to get what I want by force. But if I have to do that, then why am I using openSUSE any more? What value is openSUSE adding to distinguish itself over Slack let alone any other distro? Hardware support? Security updates? Wideness of prepackaged software selection? Currency of prepackaged software? Solidity/quality of prepackaged software builds and packaging? I think some of those are still at least at acceptable levels but I don't think they really stand out from the others any more, at least not consistently. I'll say one thing I _really_ like OBS. There are several packages I need on every box that would be a fair amount of work for me to keep up if it weren't for OBS autobuilding on all the different versions and cpu's from one set of files and config and zypper installing and then updating them on all boxes cleanly and automatically. Could I do that with ppa? Does anyone else have anything similar that's as easy to operate? could I install my own obs and use it for some other distro? I think the answer to all those is maybe but not without a lot of work and probably never attaining the ease and slickness we have right now using the public suse supplied obs and web ui, to build rpms specifically, for suse distros specifically. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 06/30/2011 10:08 AM, Felix Miata wrote:

On 2011/06/30 16:41 (GMT) Joe User composed:

...

Users who want systemd can choose it during install. But it's too big a change to be the default choice. I don't want to change, until it's been proven and polished for several years.

I don't want it until proven and polished either.

me too. :-) Looks like we're getting it anyway. All I can say is it had better work. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

You think users are fools who must worship developers as gods.

HERESY!

Some developers are like children; they should be seen and not heard.

s/developers/users

OpenSUSE may be a "community," but many of its members are paid employees of Attachmate, and can be fired from their paying jobs.

Please file a complaint and go into the queue! NM -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Le 30/06/2011 22:01, Cristian Rodríguez a écrit :

El 30/06/11 15:01, Robert Kaiser escribió:

...

I suspect you are actually a troll.

I do not suspect that, Im pretty sure he is.

right and stopping feeding the troll is the only answer jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 06/30/2011 04:01 PM, Cristian Rodríguez wrote:

El 30/06/11 15:01, Robert Kaiser escribió:

...

I suspect you are actually a troll.

I do not suspect that, Im pretty sure he is.

Definitely a troll hiding behind a false name with nothing to add. Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org