Moving /bin, /sbin, and /lib to /usr (was Re: [opensuse-factory]) sles?
* Kay Sievers <kay.sievers@suse.de> [2010-08-06 16:00]:
On Fri, 2010-08-06 at 15:27 +0200, Guido Berhoerster wrote:
* Kay Sievers <kay.sievers@suse.de> [2010-08-06 13:36]:
On Fri, 2010-08-06 at 09:42 +0200, Stefan Seyfried wrote:
On Fri, 06 Aug 2010 03:03:22 +0200 Kay Sievers <kay.sievers@suse.de> wrote:
I think that /usr on nfs, or even on a different disk should just get a reality check, and be finally dropped.
Having /usr, /var, /opt and /tmp on different partitions / disks is basically a standard setup for lots of real-world corporate installations.
The people who break such standard setups (or even think about breaking them) all the time should just get a reality check...
/usr not on the rootfs is broken since ages for anything that isn't a simple server. It does not make any sense to do that, and that's why nobody really cares.
Many things plugging into udev/hotplug break if /usr is not available at early boot. I stopped asking people to fix such things.
Unfortunately an all too common attitude in Linuxland. Anyway, can we then just be honest and officially abandon the now arbitrary /bin /sbin -- /usr/bin /usr/sbin separation by moving stuff and symlinking /bin and /sbin to /usr? It's nothing uncommon, Solaris/OpenSolaris, HP-UX, and AIX for example all don't have a separate /bin any more. It would certainly ease the pain with linking libraries which are in /usr.
Anything like this sounds good to me. It's just a pretty useless exercise with this artificial split. I would understand to have 'the desktop' split out into /usr, but everything else is just crazy. An it
That was sort of the case when X apps were still installed into /usr/{X11R6,X11,openwin} and SuSE's bad habit to install distributed packages under /opt, but those times are gone for better or worse.
seems entirely random what we do here today. The 'maybe needed at boot' thing just does not mean anything today.
Well how do we get this going, should I open a ticket on openfate to discuss this further and see if there's any objections? It shouldn't be too much work, most of the stuff is from Base:System packages. The symlinks should guarantee backwards compatibility, anything I'm missing here?
The real fix is a properly working read-only /, for people who use /usr on a separate filesystem, anyway.
Does it require anything else beside having /var and /tmp on separate partitions? -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Aug 06, 2010 at 05:38:01PM +0200, Guido Berhoerster wrote:
* Kay Sievers <kay.sievers@suse.de> [2010-08-06 16:00]:
The real fix is a properly working read-only /, for people who use /usr on a separate filesystem, anyway.
Does it require anything else beside having /var and /tmp on separate partitions?
DHCP writes /etc/resolv.conf, mount writes /etc/mtab, LVM writes /etc/lvm and so on. Regards, Arvin -- Arvin Schnell, <aschnell@suse.de> Senior Software Engineer, Research & Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 06 August 2010 11:38:01 Guido Berhoerster wrote:
Kay Sievers <kay.sievers@suse.de> wrote:
I think that /usr on nfs, or even on a different disk should just get a reality check, and be finally dropped.
Please consider this; From the Filesystem Hierarchy Standard (FHS): The Directory Structure /usr /usr has nothing to do with users, but is the acronym for UNIX system resources. The data in /usr is static, read-only data that can be shared among various hosts compliant with the Filesystem Hierarchy Standard (FHS). This directory contains all application programs and establishes a secondary hierarchy in the file system. KDE4 and GNOME are also located here. /usr holds a number of sub-directories, such as /usr/bin, /usr/sbin, /usr/local, and /usr/share/doc. But, if it can't go to a separate partition, it can no longer be shared either.
Having /usr, /var, /opt and /tmp on different partitions / disks is basically a standard setup for lots of real-world corporate installations.
Real World includes more than your laptop or minimal desktop machine. It also includes multi-machine LAN/WAN program and file server installations and if we remove/alter the way openSUSE mangles the way the Directory Structure which is designed to handle big and small installations alike, then what we are saying is that openSUSE is a 'me too', desktop only platform with very limited expansion capabilities and likely not suited in a potential commercial environment.
The people who break such standard setups (or even think about breaking them) all the time should just get a reality check...
Some people have trouble focusing on anything further than the end of their own nose. Linux needs the standards to be adhered to and not arbitrarily changed because it is convenient for lazy programming practices to be effected.
/usr not on the
rootfs is broken since ages for anything that isn't a
simple server. It does not make any sense to do that, and that's why nobody really cares.
If one doesn't see that OS is more than a desktop, then they probably won't. If they can see that a robust OS, compatible with standards that allow for easy UPsizing to large, multi-system installations in a commercial, money producing environment, then they will care. Devs that take the lazy way out hurt their own chances for recognition because the product they produce will by design, have a limited userbase that can't be easily expanded or profited from.
Many things plugging into udev/hotplug break if /usr is not available at early boot. I stopped asking people to fix such things.
Unfortunately an all too common attitude in Linuxland. Anyway, can we then just be honest and officially abandon the now arbitrary /bin /sbin -- /usr/bin /usr/sbin separation by moving stuff and symlinking /bin and /sbin to /usr?
Anything
exercise with
Alas, often true, but when you totally depend on volunteer developers, unpaid, then you get what you pay for, stuff *they* are interested in with the quality *they* feel liking imposing on themselves. Thankfully, many devs do a great job and consider it fun to produce a quality product, but unfortunately, "many" is all too few considered what is "required" to ensure consistency of quality. << WARNING> > like this sounds good to me. It's just a pretty useless this artificial split. I would understand to have 'the
desktop' split out into /usr, but everything else is just crazy. An it
Really think before you say things like that. Maybe alright for a 'tinyNIX' on a laptop, but not for a quality OS.
seems entirely random what we do here today.
The 'maybe needed at boot'
thing just does not mean anything today.
No, it is needed, but not necessarily "there". All that is needed is anything required for the system to boot up to the point where all required file systems and partitions are mounted and programs/data available. That normally would include system libraries, drivers, and any programs or scripts required to finish the boot operations. Everything (like DE's and Desktop Managers, etc) can be put on the moon if a link is/can be established after the boot is complete. Failure to establish those links wouldn't stop the boot, only affect what was unavailable, just like any other disk/resource failure after the boot is complete.
Well how do we
to discuss this further and see if there's any objections? It shouldn't be too much work, most of
get this going, should I open a ticket on openfate the stuff is from
Base:System packages. The symlinks should guarantee backwards compatibility, anything I'm missing here?
Please don't do it for that reason, do it to get the broken non-compliant issues fixed to bring OS back into the most flexible, compliant, expandable, useful, productive, fun platform available. Richard -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 06/08/10 12:28, Richard Creighton escribió:
Linux needs the standards to be adhered to and not arbitrarily changed because it is convenient for lazy programming practices to be effected.
yeah, but the standards must make sense technically, otherwise is just Mumbo-jumbo. a notory example of such Mumbo-Jumbo is the LSB. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 06 August 2010 12:53:58 Cristian Rodríguez wrote:
El 06/08/10 12:28, Richard Creighton escribió:
Linux needs the standards to be
adhered to and not arbitrarily changed because it is convenient for lazy programming practices to be effected.
yeah, but the standards must make sense technically, otherwise is just Mumbo-jumbo. a notory example of such Mumbo-Jumbo is the LSB.
I think the standards set for /usr (in this case) are technically sensable unless you want to limit oS to desktop/laptop installations and have no VMs or a LAN with diskless workstations or small drives where space is a premium (eg, many older machines) where storing redundant copies of /usr on each machine is very wasteful. On VM's, the extra disk space for each VM to have a complete copy of all the /usr (Unis System Resources) files (which contain most, if not all, of the installed non-system applications like KDE, Gnome, OpenOffice, many graphics editors...etc, etc., can be huge. Allowing /usr to be remote, eg, on another partition or even on another machine, allows much savings in disk space which even today translates into money saved. Some Mumbo-Jumbo actually has value even if you don't need it yourself at the moment, you may, even likely will need it in the future. Richard -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 08/06/2010 11:28 AM, Richard Creighton wrote:
Please consider this; From the Filesystem Hierarchy Standard (FHS):
The Directory Structure
/usr
/usr has nothing to do with users,
Think system users have no connection to /usr. Well try "echo $PATH" as a user then try it as root. Note /sbin as root but not as a user -- 73 de Donn Washburn 307 Savoy Street Email:" n5xwb@comcast.net " Sugar Land, TX 77478 LL# 1.281.242.3256 Ham Callsign N5XWB HAMs : " n5xwb@arrl.net " VoIP via Gizmo: bmw_87kbike / via Skype: n5xwbg BMW MOA #: 4146 - Ambassador " http://counter.li.org " #279316 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 08/06/2010 11:28 AM, Richard Creighton wrote:
Please consider this; From the Filesystem Hierarchy Standard (FHS):
The Directory Structure
/usr
/usr has nothing to do with users,
Think system users have no connection to /usr. Well try "echo $PATH" as a user
On Friday 06 August 2010 13:31:27 Donn Washburn wrote: then try it as root. Note /sbin as root but not as a user I didn't say USERS don't need /usr, quite the contrary, for virtually all non-system applications, the programs are in /usr. What the problem is that *during BOOT*, the users don't need /usr, only the system and only for items directly related to the boot process. Once booted, one assumes that other devices are initialized, partitions mounted, nfs or smb or cifs or other networked drives will be mounted and the files and programs contained therin would be available to users and root alike....just not while booting. If anything in /usr IS needed during boot, then it is in the wrong place, eg, it should be in /sbin or /lib or /boot which *are* in the root device and available during the boot cycle. Richard -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 08/06/2010 12:31 PM, Donn Washburn wrote:
Think system users have no connection to /usr. Well try "echo $PATH" as a user then try it as root. Note /sbin as root but not as a user
That depends on the distro. Some include /sbin and /usr/sbin in the normal, unprivileged user's path. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Richard Creighton <ricreig@gmail.com> [2010-08-06 18:27]:
Please don't do it for that reason, do it to get the broken non-compliant issues fixed to bring OS back into the most flexible, compliant, expandable, useful, productive, fun platform available.
I certainly agree that it would be nice to have if it actually worked. But who'll do the fixing, apparently nobody has cared enough about it enough to fix it. It'd be nice to have a list of stuff which is actually broken. Is it only udev scripts? Bootscripts? Keeping it in its current state is also somewhat dishonest. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 06/08/10 14:11, Guido Berhoerster escribió:
It'd be nice to have a list of stuff which is actually broken. Is it only udev scripts? Bootscripts?
a) The idea b) the requirements :-D Seriously, the best thing to do is to stop beating a dead horse.. it isnt going to work, See Kay's messages. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 06 Aug 2010 14:23:12 -0400 Cristian Rodríguez <crrodriguez@suse.de> wrote:
it isnt going to work, See Kay's messages.
It works very well on servers etc., on everything that does not need (or even want) a fully dynamic and asynchronous boot. No wonder the first thing people try to disable as much as possible on servers is udev & friends... It is only the crazy desktop people where it is not going to work. Exactly those people that don't bring any money into the business... -- Stefan Seyfried "Theory and practice sometimes clash. And when that happens, theory loses. Every single time." -- Linus Torvalds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Aug 06, 2010 at 09:48:18PM +0200, Stefan Seyfried wrote:
On Fri, 06 Aug 2010 14:23:12 -0400 Cristian Rodríguez <crrodriguez@suse.de> wrote:
it isnt going to work, See Kay's messages.
It works very well on servers etc., on everything that does not need (or even want) a fully dynamic and asynchronous boot.
Um, servers want a dynamic and async boot, do they somehow not require very large uptimes which require a quick boot cycle?
No wonder the first thing people try to disable as much as possible on servers is udev & friends...
Really? Have you tried to disable udev on a recent system these days? For what good reason? If you really want to run a system without udev, use Debian, I think they are just about the only distro that even lets you try that.
It is only the crazy desktop people where it is not going to work. Exactly those people that don't bring any money into the business...
Um, our preload group is profitable, and growing. And note, one of the first users of udev was very large systems with hundreds and thousands of disk drives, way back in SLE9. good luck, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 6 Aug 2010 13:12:59 -0700 Greg KH <gregkh@suse.de> wrote:
On Fri, Aug 06, 2010 at 09:48:18PM +0200, Stefan Seyfried wrote:
It works very well on servers etc., on everything that does not need (or even want) a fully dynamic and asynchronous boot.
Um, servers want a dynamic and async boot, do they somehow not require very large uptimes which require a quick boot cycle?
Greg, as you certainly know, servers usually take minute(s) from "reboot -f" until the VGA screen (or whatever equivalent) comes on again[1]. Then some more minutes until the memory is found, drives are initialized etc. On such a machine, the 20 seconds you can gain from grub to desktop are not relevant. And oh - there is no desktop anyway. AFAICT most of the "fastboot" efforts are centered around "start X as early as possible" which is totally irrelevant for any serious server machine. All the commercial software installed on those machines usually has some "sleep xxx" inside their init scripts anyway ;-) Those machine simply do not get rebooted. Period.
No wonder the first thing people try to disable as much as possible on servers is udev & friends...
Really? Have you tried to disable udev on a recent system these days? For what good reason?
Not me. I just see what's being done here at the customer (which is probably one of the worlds largest 5 SLES deployments). Of course udev is not disabled, but everyone tries to make sure udev and HAL are not interfering with the system after initial bootup.
It is only the crazy desktop people where it is not going to work. Exactly those people that don't bring any money into the business...
Um, our preload group is profitable, and growing.
I'm glad to hear that (really. It shows that not everything we did was a waste of time and that there is finally some gain from all the pain ;). But I'm still sure that getting rid of all the server subscriptions would be not a wise move for Novell/SUSE ;-)
And note, one of the first users of udev was very large systems with hundreds and thousands of disk drives, way back in SLE9.
But in SLES9 /usr on separate partition was still a supported setup (I know, because I did run the testcases for this setup ;) I can totally understand why Kay wants to get rid of all those "legacy features". It's just that I think it won't work out well at the customers I'm visiting. Maybe having a "not-so-dynamic" boot mode for servers, which can live with /usr being on a separate partition and a "fully dynamic mode" for desktops might be an option. Crazy requirements like "/usr on NFS which is mounted via 3G" would simply be rejected, so that in "server mode" we could say * everything that is needed to mount filesystems must be in / * only old ifconfig method is supported, no NetworkManager Then dbus and all that stuff would be out of question, making /usr not so important anymore. Just braindumping here of course... :) [1] e.g. SUN Fire X4170 or HP ProLiant BL460c G6 machines. Timed with a stopwatch. 1 Minute between "echo b > /proc/sysrq-trigger" and VGA BIOS message. SUN with 24GB RAM, HP with 144GB RAM. Both machines are definitely not crap. -- Stefan Seyfried "Theory and practice sometimes clash. And when that happens, theory loses. Every single time." -- Linus Torvalds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, 7 Aug 2010, Stefan Seyfried wrote:
I can totally understand why Kay wants to get rid of all those "legacy features". It's just that I think it won't work out well at the customers I'm visiting.
In my experience Kay is a lot quicker to dismiss something as "legacy" than (SLE) customers or (openSUSE) users. Don't worry, for the former we have people keeping an eye on the real customer requirements, but I certainly advise to be somewhat careful on openSUSE as well. Gerald -- Dr. Gerald Pfeifer <gp@novell.com> Director Product Management, SUSE Linux Enterprise, openSUSE, Appliances -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Gerald Pfeifer <gp@novell.com> [2010-08-07 18:31]:
On Sat, 7 Aug 2010, Stefan Seyfried wrote:
I can totally understand why Kay wants to get rid of all those "legacy features". It's just that I think it won't work out well at the customers I'm visiting.
In my experience Kay is a lot quicker to dismiss something as "legacy" than (SLE) customers or (openSUSE) users. Don't worry, for the former we have people keeping an eye on the real customer requirements, but I certainly advise to be somewhat careful on openSUSE as well.
If this is business-critical to Novell why doesn't anybody ensure that NFS-mounted /usr keeps working? -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, 9 Aug 2010, Guido Berhoerster wrote:
In my experience Kay is a lot quicker to dismiss something as "legacy" than (SLE) customers or (openSUSE) users. Don't worry, for the former we have people keeping an eye on the real customer requirements, but I certainly advise to be somewhat careful on openSUSE as well. If this is business-critical to Novell why doesn't anybody ensure that NFS-mounted /usr keeps working?
It is a fully supported scenario for SUSE Linux Enterprise Server 11 (and the releases before) and very likely will be a fully supported scenario for SUSE Linux Enterprise Server 12. It is not a top priority for Novell to see in openSUSE 11.4 and "ensure" is too strong a word from that perspective though it would be sad to see it being broken. Let's keep in mind: when it comes to openSUSE, Novell is just one stakeholder, even if one contributing a ton. Gerald -- Dr. Gerald Pfeifer <gp@novell.com> Director Product Management, SUSE Linux Enterprise, openSUSE, Appliances -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello all, On 2010-08-09 T 14:16 +0200 Gerald Pfeifer wrote:
On Mon, 9 Aug 2010, Guido Berhoerster wrote:
In my experience Kay is a lot quicker to dismiss something as "legacy" than (SLE) customers or (openSUSE) users. Don't worry, for the former we have people keeping an eye on the real customer requirements, but I certainly advise to be somewhat careful on openSUSE as well. If this is business-critical to Novell why doesn't anybody ensure that NFS-mounted /usr keeps working?
It is a fully supported scenario for SUSE Linux Enterprise Server 11 (and the releases before) and very likely will be a fully supported scenario for SUSE Linux Enterprise Server 12.
Indeed, I confirmed that it has been a supported feature in all SUSE Linux Enterprise and SUSE Linux/openSUSE releases at least since we officially supported the FHS (Filesystem Hierarchy Standard). Carlos E. R. also mentioned this on Friday. http://www.pathname.com/fhs/pub/fhs-2.3.html#THEFILESYSTEM says: ----------------------------< snip >---------------------------- Rationale Shareable files can be stored on one host and used on several others. Typically, however, not all files in the filesystem hierarchy are shareable and so each system has local storage containing at least its unshareable files. It is convenient if all the files a system requires that are stored on a foreign host can be made available by mounting one or a few directories from the foreign host. [...] Here is an example of a FHS-compliant system. (Other FHS-compliant layouts are possible.) ┌────────┬───────────────┬───────────┐ │ │ shareable │unshareable│ ├────────┼───────────────┼───────────┤ │static │/usr │/etc │ ├────────┼───────────────┼───────────┤ │ │/opt │/boot │ ├────────┼───────────────┼───────────┤ │variable│/var/mail │/var/run │ ├────────┼───────────────┼───────────┤ │ │/var/spool/news│/var/lock │ └────────┴───────────────┴───────────┘ ----------------------------< snap >---------------------------- Q1: Is FHS compliance an important part of openSUSE as a Linux distribution?
It is not a top priority for Novell to see in openSUSE 11.4 and "ensure" is too strong a word from that perspective though it would be sad to see it being broken. Let's keep in mind: when it comes to openSUSE, Novell is just one stakeholder, even if one contributing a ton.
I fully agree. I think though, we should do a next step, and analyze if the requirements are also in the interest of openSUSE beyond Novell. Here what had been mentioned already in this thread: - Thin Clients - Virtual machines - all (other) use cases with "read only root" Q2: Are those use cases valid for openSUSE? If we agree to a "Yes" on both questions, then keeping "/usr" a shareable and static filesystem will remain a requirement for openSUSE -- and packages should be adopted accordingly. so long - MgE -- Matthias G. Eckermann Senior Product Manager - SUSE® Linux Enterprise - Server Product Line SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Greg KH wrote:
On Fri, Aug 06, 2010 at 09:48:18PM +0200, Stefan Seyfried wrote:
On Fri, 06 Aug 2010 14:23:12 -0400 Cristian Rodríguez <crrodriguez@suse.de> wrote:
it isnt going to work, See Kay's messages.
It works very well on servers etc., on everything that does not need (or even want) a fully dynamic and asynchronous boot.
Um, servers want a dynamic and async boot, do they somehow not require very large uptimes which require a quick boot cycle?
IMO, server bootup time is immaterial - servers are meant to run and run and run, booting them is an exception. Even so, when I reboot a server maybe once a year, I don't mind if bootup takes e.g. 5 minutes. 0.001% downtime per year is about 5 minutes, but 0.01% is a more reasonable expectation for a single server. Regardless, a change such as this is one of those that belong to a major release, not a dot-release. It would also seem to be somewhat dependent on which strategy we decide to pursue. /Per Jessen, Zurich -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, 7 Aug 2010, Per Jessen wrote:
IMO, server bootup time is immaterial - servers are meant to run and run and run, booting them is an exception. Even so, when I reboot a server maybe once a year, I don't mind if bootup takes e.g. 5 minutes.
Actually, when bootup with a couple of hundred CPUs or thousands of LUNs has been taking 10s of minutes, customer did care. Which is why we fixed it for them. ;-) But, indeed, while a few seconds more or less can be very visible on your netbook/notebook or desktop, for most servers it's less critical unless it becomes too much. Gerald -- Dr. Gerald Pfeifer <gp@novell.com> Director Product Management, SUSE Linux Enterprise, openSUSE, Appliances -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Guido Berhoerster <gber@opensuse.org> [2010-08-06 20:07]:
* Richard Creighton <ricreig@gmail.com> [2010-08-06 18:27]:
Please don't do it for that reason, do it to get the broken non-compliant issues fixed to bring OS back into the most flexible, compliant, expandable, useful, productive, fun platform available.
I certainly agree that it would be nice to have if it actually worked. But who'll do the fixing, apparently nobody has cared enough about it enough to fix it. It'd be nice to have a list of stuff which is actually broken. Is it only udev scripts? Bootscripts? Keeping it in its current state is also somewhat dishonest.
To answer myself, I did some testing on a minimal server install with the following results: * SuSEfirewall2_init: needs iptables which is installed in /usr, but could be called again from nfs after /usr is mounted * dbus: service files in /usr/share/dbus-1/ seems to be discovered when /usr is available? * vboxadd: needs sources and compiler, could be moved to run after nfs * haldaemon: requires /usr, but will die anyway * cifs: wants en_US locale, why, could be moved to run after nfs? Regarding udev I grepped /lib/udev/rules.d and reviewed the scripts in /lib/udev, /etc/udev/rules.d and didn't find anything which requires /usr to be mounted. So what part of udev has dependencies on utilities/libs in /usr? I also noted that essential shell utilities such as cut, head, id, yes, paste, printf, sort, tail, touch from coreutils get installed in /usr/bin rather than /bin. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (12)
-
Arvin Schnell -
Cristian Rodríguez -
Cristian Rodríguez -
Donn Washburn -
Gerald Pfeifer -
Greg KH -
Guido Berhoerster -
Larry Finger -
Matthias G. Eckermann -
Per Jessen -
Richard Creighton -
Stefan Seyfried