On 06/19/2011 11:46 AM, Bruno Friedmann wrote:

On 06/19/2011 05:38 PM, Roman Bysh wrote:

...

Hello all,

I recently installed systemd-18-1.2.4 and systemd-sysvinit-18-1.2.4 on Tumbleweed. However, during the reboot the system stalled.

My system setup always has /usr in a separate partition. Is this the reason for the system stalling during the reboot?

I could not recover. Is there a way to recover from this?

Cheers!

Roman

yeap if you have followed the systemd thread separate /usr is not the best way to get it working actually. last time I fail with systemd I've booted with 1 at the end of the line, remove systemd then add sysv-init from local rpm But didn't know all the details, sorry

I wish I hadn't missed that thread. I didn’t know about adding the number "1" at the end of the kernel options line in Grub workaround. Good to know :-) However, it's a good thing to remember when I'm on forums.opensuse.org. Coming from SysV, I'm sure we're not the only ones using a separate /usr partition. And, I'm wondering if it's a limitation, or temporary bug ;-) Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 06/19/2011 01:23 PM, Jos Poortvliet wrote:

On Sunday 19 June 2011 18:23:08 Roman Bysh wrote:

...

On 06/19/2011 11:46 AM, Bruno Friedmann wrote:

...

On 06/19/2011 05:38 PM, Roman Bysh wrote:

...

Hello all,

I recently installed systemd-18-1.2.4 and systemd-sysvinit-18-1.2.4 on Tumbleweed. However, during the reboot the system stalled.

My system setup always has /usr in a separate partition. Is this the reason for the system stalling during the reboot?

I could not recover. Is there a way to recover from this?

Cheers!

Roman

yeap if you have followed the systemd thread separate /usr is not the best way to get it working actually. last time I fail with systemd I've booted with 1 at the end of the line, remove systemd then add sysv-init from local rpm But didn't know all the details, sorry

I wish I hadn't missed that thread. I didn’t know about adding the number "1" at the end of the kernel options line in Grub workaround. Good to know :-)

However, it's a good thing to remember when I'm on forums.opensuse.org.

Coming from SysV, I'm sure we're not the only ones using a separate /usr partition.

And, I'm wondering if it's a limitation, or temporary bug ;-)

systemd does not support a separate /usr partition. This was a decision of the devs - according to them there are lots of weird corner cases with /usr on a separate partition and you shouldn't want it.

See: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

...

Roman

In response to the devs reminding me of my 80's partition config: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken> And let's clarify a few things: 1. It isn't systemd's fault. systemd works fine with /usr on a separate file system. 2. systemd is merely the messenger. Don't shoot the messenger. 3. There's no news in all of this. The message you saw is just a statement of fact, describing the status quo. Things have been this way since a while. 4. The message is merely a warning. You can choose to ignore it. 5. Don't blame us, don't abuse us, it's not our fault, and if you complain to us we'll just ignore you. http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken> I will backup my folders on /home partition to my usb drive and repartition without a separate /usr partition. Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Roman Bysh wrote:

In response to the devs reminding me of my 80's partition config:

http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken>

And let's clarify a few things:

1. It isn't systemd's fault. systemd works fine with /usr on a separate file system.

Quote from the page you mention: .... the reason systemd is broken, apparently: Quite a number of programs these days hook themselves into the early boot process at various stages. A popular way to do this is for example via udev rules. The binaries called from these rules are sometimes located on /usr/bin, or link against libraries in /usr/lib, or use data files from /usr/share. If these rules fail udev will proceed with the next one, however later on applications will then not properly detect these udev devices or features of these devices. Here's a short, very in-comprehensive list of software we are aware of that currently is not able to provide the full set of functionality when /usr is split off: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, the locale logic of most programs and a lot of other stuff. ---- Here's the problem...He's mentioning 'user space' programs, ALL should have a ***pre-req**/dependency, on "localfs" -- which would include mounting all of the local hard disks. THEN you proceed to bring up the next dependency --- which...at some point -- what if people have /usr on a network? usually network is brought up, then network disks, THEN you can really start with programs... AT least this is the way its been done for decades...and now the systemd author says...well to get greater speed, we can't be waiting for all those dependencies... so lets just require that /usr already be mounted so we can run everything at once rather than in a 'makefile' like fashion.... It really sounds like the design of systemd is fundamentally flawed -- he wants a completely different starting environment before he brings up services... It really sounds like systemd is NOT meant to be a boot manager, but a **service** manager (Like MS's service's control panel). But it needs all the basic functions up and running so it can start it's services that all depend on basic items being there (like /usr, udev, network disks...etc...)... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sun, Jun 19, 2011 at 2:16 PM, Kay Sievers wrote:

On Sun, 2011-06-19 at 19:23 +0200, Jos Poortvliet wrote:

...

On Sunday 19 June 2011 18:23:08 Roman Bysh wrote:

...

On 06/19/2011 11:46 AM, Bruno Friedmann wrote:

...

On 06/19/2011 05:38 PM, Roman Bysh wrote:

...

Hello all,

I recently installed systemd-18-1.2.4 and systemd-sysvinit-18-1.2.4 on Tumbleweed. However, during the reboot the system stalled.

My system setup always has /usr in a separate partition. Is this the reason for the system stalling during the reboot?

I could not recover. Is there a way to recover from this?

Cheers!

Roman

yeap if you have followed the systemd thread separate /usr is not the best way to get it working actually. last time I fail with systemd I've booted with 1 at the end of the line, remove systemd then add sysv-init from local rpm But didn't know all the details, sorry

I wish I hadn't missed that thread. I didn’t know about adding the number "1" at the end of the kernel options line in Grub workaround. Good to know :-)

However, it's a good thing to remember when I'm on forums.opensuse.org.

Coming from SysV, I'm sure we're not the only ones using a separate /usr partition.

And, I'm wondering if it's a limitation, or temporary bug ;-)

systemd does not support a separate /usr partition. This was a decision of the devs - according to them there are lots of weird corner cases with /usr on a separate partition and you shouldn't want it.

See: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Systemd itself does not need anything in /usr, and does not miss any support for it by itself. But a lot stuff around systemd like D-Bus, and udev rules can't work reliably with a separate /usr.

With systemd the service dependencies get a lot more strict, and stuff that failed in that area in the past and didn't cause any major problems, causes problems now.

Some udev rules never really worked with a separate /usr, it was just that people who did that usually had no dependencies on devices like 3G modems, complexer NetworkManager setup, sound, ...

Separate /usr partitions will just need to be mounted from inside the initramfs in the future.

Kay

Kay, I don't see a discusion of separate /usr on: http://en.opensuse.org/SDB:Systemd http://en.opensuse.org/openSUSE:Systemd_status Is there a openSUSE commitment to support that. And if so, what will the limitations be. It would nice to get that info onto one of the above pages. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 19 June 2011 15:16, Markus Slopianka wrote:

...

Systemd itself does not need anything in /usr, and does not miss any support for it by itself. But a lot stuff around systemd like D-Bus, and udev rules can't work reliably with a separate /usr.

Correct me if I'm wrong but doesn't YaST suggest a separate /usr partition when installing openSUSE on an empty drive?

Yes, I would consider that a bug. If /usr is a no-go then that option would need to be removed. No one has gotten around to removing this yet as the systemd-as-default-init announcement was recent.

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

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

On 19 June 2011 17:44, Hans Witvliet wrote: On Sun, 2011-06-19 at 15:41 -0400, Steven Sroka wrote:

...

...

On 19 June 2011 15:16, Markus Slopianka wrote:

...

Systemd itself does not need anything in /usr, and does not miss any support for it by itself. But a lot stuff around systemd like D-Bus, and udev rules can't work reliably with a separate /usr.

Correct me if I'm wrong but doesn't YaST suggest a separate /usr partition when installing openSUSE on an empty drive?

Yes, I would consider that a bug. If /usr is a no-go then that option would need to be removed.

No, you ar mistaken cause and concequence There is nothing wrong with yast

It should remain possible to have /usr on a separate partition.

My apologies.

hw

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

El 19/06/11 14:16, Kay Sievers escribió:

Some udev rules never really worked with a separate /usr, it was just that people who did that usually had no dependencies on devices like 3G modems, complexer NetworkManager setup, sound, ...

Separate /usr partitions will just need to be mounted from inside the initramfs in the future.

Or maybe restore sanity completely and simply do not support it anymore, I vote for this approach :) Will also put a stop on insane BRP checks that bug about libraries not being on /%{lib}. The axe cuts two annoying problems at the same time. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sun, Jun 19, 2011 at 1:23 PM, Jos Poortvliet wrote:

On Sunday 19 June 2011 18:23:08 Roman Bysh wrote:

...

On 06/19/2011 11:46 AM, Bruno Friedmann wrote:

...

On 06/19/2011 05:38 PM, Roman Bysh wrote:

...

Hello all,

I recently installed systemd-18-1.2.4 and systemd-sysvinit-18-1.2.4 on Tumbleweed. However, during the reboot the system stalled.

My system setup always has /usr in a separate partition. Is this the reason for the system stalling during the reboot?

I could not recover. Is there a way to recover from this?

Cheers!

Roman

yeap if you have followed the systemd thread separate /usr is not the best way to get it working actually. last time I fail with systemd I've booted with 1 at the end of the line, remove systemd then add sysv-init from local rpm But didn't know all the details, sorry

I wish I hadn't missed that thread. I didn’t know about adding the number "1" at the end of the kernel options line in Grub workaround. Good to know :-)

However, it's a good thing to remember when I'm on forums.opensuse.org.

Coming from SysV, I'm sure we're not the only ones using a separate /usr partition.

And, I'm wondering if it's a limitation, or temporary bug ;-)

systemd does not support a separate /usr partition. This was a decision of the devs - according to them there are lots of weird corner cases with /usr on a separate partition and you shouldn't want it.

See: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Jos, openSUSE may or may not support a separate /usr which systemd rolls from what I understand. It depends if it is decided to move enough logic in initrd to allow /usr to be mounted early in the boot process. I for one believe openSUSE should support it as much as feasible. There are too many machines out there with them being separate. I know I have at least 4 servers I setup about 10 years ago (8.1 days) which I've just been upgrading. They all have separate /usr. Having 12.1 break on those machines would be a real concern for me as a opensuse user. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Monday 20 June 2011 06:49:30 Linda Walsh wrote:

Greg Freemyer wrote:

...

openSUSE may or may not support a separate /usr which systemd rolls from what I understand.

It depends if it is decided to move enough logic in initrd to allow /usr to be mounted early in the boot process.

I for one believe openSUSE should support it as much as feasible. There are too many machines out there with them being separate.

I know I have at least 4 servers I setup about 10 years ago (8.1 days) which I've just been upgrading. They all have separate /usr.

Having 12.1 break on those machines would be a real concern for me as a opensuse user.

Greg

----- (am in agreeance*! *-that is a word!) Why it it that every time someone decides to go with some new wizzy software thing, they have no problems throwing out current features that MANY people use and rely on?...

Please inform yourself before ranting. If you would have read the link I gave (or the other mails in this thread) you would know nothing you just said makes any sense. Hint: systemd is NOT the problem, the rest of the linux tools doesn't support it properly. Read before you rant please.

There is a reason windows was as successful as it was...it maintained some level of compatibility up through XP....with Win7, they broke it to introduce DRM...which I still detest them for and Win7 still has worse perf and more probs than I ever had with XP.

But I have separate boot and root and usr.... The only time I have problems with my setup is during SUSE upgrades, which I fear greatly....

I still haven't fully recovered from an upgrade to 11.4 though most things work fine and am glad I did it...but the initial upgrade... After I I had upgraded the packages, it jumped into the installer a second time with some small subset of packages -- what I didn't catch was it was doing some minimal install into the 'dead' area at the end of my disk (an area I leave unused on my boot disks due to speed) and then booted from there.

Thank god for rescue disks...

Also why can't /usr be mounted early on? I was always taught you put your static boot progs in /lib /sbin and /bin, then /usr was where the "runtime" was that was accessed when the system was booted.

Just like the jump to throw out xfs because grub was broken, or throw out lilo because it didn't had problems -- rather than fix the problems, grub has caused me more problems than I want to think about....

I tried it twice willingly, and about 4-5 times unwillingly during various upgrades....I DO still use it on some of my test systems, but it's too unreliable and slow for my main system.

Except for a few months when I couldn't upgrade my kernel due to the lilo size constraint, I've never had problems with it. I DID have problems with grub and XFS....but not with lilo and XFS....

It really bothers me to have so much done on the ram disk -- it makes it impossible to debug boot problems and completely mangles the normal unix boot process of init starting things...

OTOH, Win7...sorta went the same way--- They allocate a 100MB partition just for their System boot partition....all hidden and inaccessible to the user...just so they can control the boot... (and control the OS/HW layer, to provide DRM)... Is that where OSuse is going?

On Monday 20 June 2011 10:23:45 Jos Poortvliet wrote:

Please inform yourself before ranting. If you would have read the link I gave (or the other mails in this thread) you would know nothing you just said makes any sense. Hint: systemd is NOT the problem, the rest of the linux tools doesn't support it properly. Read before you rant please.

Well considering the rst of the Linux tools have been around for a hell of a lot longer than systemd then that makes it systemd at fault for not supporting the tools for the job there aint no backwards logic of out that fact systemd is the new kid on the block so therefore it needs to support the tools and not expect the tools to change to suit it . where's the difficulty in that ? .. Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.8-0.2-desktop KDE Development Platform: 4.6.00 (4.6.0) 14:45 up 3 days 8:09, 4 users, load average: 0.03, 0.03, 0.04 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

El 20/06/11 16:01, Carl-Daniel Hailfinger escribió:

wound = broken /usr dependencies

Insane requirements is the wound.

band-aid = old sysvinit

No :) sysvinit just fails silently. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am Dienstag, 21. Juni 2011 schrieb Carl-Daniel Hailfinger:

Am 20.06.2011 22:23 schrieb Cristian Rodríguez:

...

El 20/06/11 16:01, Carl-Daniel Hailfinger escribió

...

wound = broken /usr dependencies

Insane requirements is the wound.

...

band-aid = old sysvinit

No :) sysvinit just fails silently.

Examples from the 11.4 default package selection please. :-)

Test your own installation: grep -r /usr /lib/udev/ Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-06-19 19:23, Jos Poortvliet wrote:

systemd does not support a separate /usr partition. This was a decision of the devs - according to them there are lots of weird corner cases with /usr on a separate partition and you shouldn't want it.

This is awful. :-/ - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3+aZIACgkQtTMYHG2NR9WMkwCdHD8LEp5nl7XDE1W2CTyoEN3M QRYAn3ueyeWVA+gt02UVhjY6Xpk9iPnk =CWZV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sunday 19 June 2011 23:30:55 Robert Xu wrote:

On Sun, Jun 19, 2011 at 17:26, Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2011-06-19 19:23, Jos Poortvliet wrote:

...

systemd does not support a separate /usr partition. This was a decision of the devs - according to them there are lots of weird corner cases with /usr on a separate partition and you shouldn't want it.

This is awful. :-/

- -- Cheers / Saludos,

Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk3+aZIACgkQtTMYHG2NR9WMkwCdHD8LEp5nl7XDE1W2CTyoEN3M QRYAn3ueyeWVA+gt02UVhjY6Xpk9iPnk =CWZV -----END PGP SIGNATURE-----

So... is it possible to mount /usr at initrd time?

Of course. Actually, systemd has no problem with /usr being on a separate partition as you could have read in the link I gave, it is UDEV and a billion other tools you need at boot which don't work. systemd is just honest about it where sysv fails silently.

Le lundi 20 juin 2011 à 13:38 +0200, Susanne Oberhauser a écrit :

So can we please focus an solving the problems that break a separate r/o /usr, instead of bashing on distinguished, experienced engineers that help us keep openSUSE the premier choice for *all* Linux uses, not just tabloid PCs?

Yes ! I'd like people to fill bug reports on issue they find (and remember to mark them blocking bnc#696902 , when using /usr as a separate partition and systemd, so we try to have a good overview of the real issues and then we try to fix the issues one by one. -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 06/20/2011 01:38 PM, Susanne Oberhauser wrote:

Jos Poortvliet writes:

...

systemd does not support a separate /usr partition. This was a decision of the devs - according to them there are lots of weird corner cases with /usr on a separate partition and you shouldn't want it.

See: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

If I'm reading that right, it *does* support a separate /usr, it's just some other players in the boot process don't any more.

Wrt 'nobody needs a separate /usr', This guy is just uninformed, that's not bad and probably not his fault. Possibly like most of us he started using Linux on his desktop and he's never seen more complex setups?

Let me pick a few examples (from non-netbook worlds), examples that I've chosen because A) such uses are feeding almost every large Linux distribution and because B) these uses are key in what sets SUSE apart.

First, having a separate, read-only mountable /usr partition allows diskless high performance computing clusters and data centers to share a networked /usr.

If you have >2000 blades in your data centre, then you don't want to have someone replace a failed hard disk in one of them every single day. Which for 2000 machines is what you get: just one hard disk failure a day, if you're lucky.

So you want the blades diskless. And then on your storage system (where 1GB is a tad more expensive than at home) you have no interest to replicate the very identical /usr 2000 times for each of them. You want /usr shared.

Another use is massive parallell virtualisations, which share /usr as ramdisk in the very same physical RAM on one machine. 2000 Linux machines on 32CPUs, /usr on a ram disk that per guest just needs 500k. IBM did that on mainframe linux years ago, with several thousand snappy guests on a single machine. That's how some some web hosters provide "your own dedicated Linux web server": One mainframe with several thousand virtualized Linux guests is *much* cheaper than a compute centre with several thousand physical 'dedicated machines'.

Now I hear someone shout "corner cases!", and "server problem, not my problem!".

Well.

SUSE is the distribution with the most consistent "same environment from the appliance via desktop to the mainframe" story, since 1999. We could do that because of the build server, which built the same Linux on sparc, aplpha, ppc, mips (!), x86. x86_64 and itanic.

This philosophy of the very same Linux on any size hardware allows the young talented Linux netbook users of today to become professional Linux engineers later. It also allows companies to just scale up the hardware and find the same environment and the same tools. It allows to develop things on a netbook or laptop and then benefit from them on the 16-node server.

It's a Good Thing.

And: Everybody, high performance clusters, web farm hosters, desktop / netbook users wants a fast boot, the real objective of this discussion.

And last not least I'm pretty sure that the problems systemd reveals (as per your link above) can be fixed.

For /usr to be network mountable (diskless HPC cluster), you need to set up network before you mount /usr. Whther / is an initrd for that purpose doesn't matter.

I like the idea of cleaning up the udev rules and stuff that break a separate, read-only mountable /usr.

To me it always was cool to have the same professional and versatile Linux on my laptop that I also used on the mainframe.

So can we please focus an solving the problems that break a separate r/o /usr, instead of bashing on distinguished, experienced engineers that help us keep openSUSE the premier choice for *all* Linux uses, not just tabloid PCs?

S.

I've not wanted to add to this lengthy thread, but the above is exactly the world where openSUSE and SLES both are very competitive and it works much as Suzanne has described. http://www.top500.org/stats/list/35/os Peter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

El 20/06/11 14:03, Carlos E. R. escribió:

On 2011-06-20 13:38, Susanne Oberhauser wrote:

...

...

So can we please focus an solving the problems that break a separate r/o /usr, instead of bashing on distinguished, experienced engineers that help us keep openSUSE the premier choice for *all* Linux uses, not just tabloid PCs?

Thank you!

Been there, done that, pretty painful, reason why I do not buy this rationale and find it quite frankly insane. BTW the systemd developers are correct in their analysis in every single point. Here is a simple test, make an spec file to package a trivial program: " #include <iostream> using namespace std; int main() { cout << "Hello World!" << endl; } " Imagine this simple C++ program is critical during boot, compile with g++ .. then %{__install} it on /bin or /sbin as required so /usr can live in remote and see if the build system allows you do so. It doesnt!!, it aborts installation with "libraries are in /usr.." message. Now extrapolate this to a non trivial C++ program, or even C ones, that use lots of libraries, it implies wasting lots and lots of time, fixing packages to move libraries around, fixing the regressions that get introduced by those changes ..repeat, ad nauseum.. ALl this work has to be done just to cover this corner, stone age use case. Sorry, not seeing the benefit here -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-06-20 20:51, Cristian Rodríguez wrote:

Been there, done that, pretty painful, reason why I do not buy this rationale and find it quite frankly insane. BTW the systemd developers are correct in their analysis in every single point.

Here is a simple test, make an spec file to package a trivial program:

Regardless of how difficult you think it is, doesn't make you right. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3/vLMACgkQtTMYHG2NR9VZcwCfTN+cj3gqgDOjYiIqjEqsxFeK 9/kAn1On27Scpdq3Nzr3hgN78sD4I/3S =5OEN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, Jun 20, 2011 at 5:51 PM, Cristian Rodríguez wrote:

El 20/06/11 17:33, Carlos E. R. escribió:

...

Regardless of how difficult you think it is, doesn't make you right.

I'm not claming and right, What I am arguing here is that the amount of work needed is better invested in other, sane tasks.

From the systemd page:

"..the common basic set of OS components of modern Linux machines is not, and has not been in quite some time. And it is unlikely that this is going to be fixed any time soon, or even ever."

Pretty much sums it up.

 Now I will claim , "Im right" :-) and encourage people not to waste their precious development time on this thing.

Christian (and others), Specifically related to upgrading servers to 12.1 and future openSUSE versions, what are you arguing for as relates to existing installs that have a separate /usr? (I suspect I have several of those in the stone-age category, so I really do care about the answer.) (In the below, assume server means "init 3" and sound is a non-issue.) Please answer for each of these situations: 1) Basic Server setups (stone-age?) that work fine with sysvinit. (For instance on my basic servers, I could not get mount by guid to work right, so they are still /dev/sda1 style in fstab. Possibly my issue is a broken udev. I don't know, but as long as I keep they old hardcoded /dev/sda style device names I've been able to upgrade to 11.3. I do have LVM in use for data partitions, but not for / or /usr. I also have 3ware raid1 in use. 3 sets actually. OS drive pair. data drive pair, backup drive pair.) 2) Complex Server setups which currently have issues with sysvinit, but the admin may not even know it. (That may be me and why I have to use /dev/sda style names in fstab.) 3) Complex Server setups which cause the admin problems, but for which he has not yet bitten the bullet and re-done his configuration. I assume there are also desktop issues, but I'm personally much more concerned with the server upgrade path. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, Jun 20, 2011 at 7:05 PM, Cristian Rodríguez wrote:

El 20/06/11 18:30, Greg Freemyer escribió:

...

Specifically related to upgrading servers to 12.1 and future openSUSE versions, what are you arguing for as relates to existing installs that have a separate /usr?  (I suspect I have several of those in the stone-age category, so I really do care about the answer.)

On Upgrade, I would expect sysvinit users to remain so, with no change, and systemd for clean, new installations.

If true, that has a huge impact on this whole thread (group of threads). I know I've been assuming a more or less forced migration even for existing installs that want to upgrade to 12.1. The kick-off email for this said "switching boot manager is not a trivial task and issues will be found." Can one of the sysvinit / systemd maintainers say what their proposed plan is for upgrades? for new installs? Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, Jun 20, 2011 at 07:42:16PM -0400, Greg Freemyer wrote:

On Mon, Jun 20, 2011 at 7:05 PM, Cristian Rodríguez wrote:

...

El 20/06/11 18:30, Greg Freemyer escribió:

...

Specifically related to upgrading servers to 12.1 and future openSUSE versions, what are you arguing for as relates to existing installs that have a separate /usr?  (I suspect I have several of those in the stone-age category, so I really do care about the answer.)

On Upgrade, I would expect sysvinit users to remain so, with no change, and systemd for clean, new installations.

If true, that has a huge impact on this whole thread (group of threads). I know I've been assuming a more or less forced migration even for existing installs that want to upgrade to 12.1.

The kick-off email for this said "switching boot manager is not a trivial task and issues will be found."

Can one of the sysvinit / systemd maintainers say what their proposed plan is for upgrades? for new installs?

As maintainer of sysvinit (here and also upstream) the only thing I can say the major problem is IMHO not sysvinit nor systemd. That is if we analyse the systemd warning about /usr we will detect udevd or better the udev rules which uses tools for hardware detection located below /usr, see alsa for an example, here you'll find firmware to load below /usr/share/alsa/firmware/ also the alsactl is located at /usr/sbin/, for a short check just do grep '"/usr' /{lib,etc}/udev/rules.d/* now make clear that those rules will be expanded at boot time before a potential /usr partition is mounted. One solution could be that udevd just check for the mount points and collect all rules depending on e.g. /usr as an own mount point to be executed *after* /usr is mounted. An other solution could be that the udev rules will be tagged by dependency rules in the same scheme as the boot and runlevel scripts. The udevd have to wait for this rules on those scripts to become fulfilled. Without this then with both systemd and sysvinit can not avoid the trouble due expanded rules depending on /usr tools and data. The only difference is that systemd is warning about a separate /usr partition. If the udevd or udev rules will not be fixed an upgrade of a system with a separate /usr will require initramfs support for more than the root files system, this includes that sulogin and at last but not least the root password will become part of the initrd to avoid an unsecure emergency shell prompt. For a new installation I personally prefer that /usr is located on the same partition as / but /var, /tmp, and /boot are sparate partitions. The last choice /boot depends on the boot loader and the CMOS support for large disks, if grub would be able to support large disks/SSDs and the my prefered file system type then /boot could be part of / ) Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

El 21/06/11 00:16, Linda Walsh escribió:

Cristian Rodríguez wrote:

During the boot, binaries should come from /sbin, /bin and *should* use static linkage,

No, again, that causes more problems than it solves, here is the tip of the iceberg http://www.akkadia.org/drepper/no_static_linking.html And there are no static libraries in openSUSE, most have been removed.

It's questionable the benefit of using something with as large a memory foot print as C++ at boot time...but that has only been historically true --

SO you want to put an arbitrary limit on what language is used for this applications just to satisfy a corner-case ? :-S -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 06/20/2011 02:03 PM, Carlos E. R. wrote:

On 2011-06-20 13:38, Susanne Oberhauser wrote:

...

...

So can we please focus an solving the problems that break a separate r/o /usr, instead of bashing on distinguished, experienced engineers that help us keep openSUSE the premier choice for *all* Linux uses, not just tabloid PCs?

Thank you!

+1 Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org