[opensuse-factory] Tumbleweed systemd does not allow my computer to boot with /usr on a separate partition
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 06/19/2011 05:38 PM, Roman Bysh wrote:
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 -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 06/19/2011 11:46 AM, Bruno Friedmann wrote:
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 Sunday 19 June 2011 18:23:08 Roman Bysh 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. See: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Roman
On 06/19/2011 01:23 PM, Jos Poortvliet wrote:
In response to the devs reminding me of my 80's partition config: <snip 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. <snip 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:
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, 2011-06-19 at 19:23 +0200, Jos Poortvliet 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. 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 -- 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 <kay.sievers@suse.de> wrote:
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
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
On Sun, 2011-06-19 at 15:41 -0400, Steven Sroka wrote:
No, you ar mistaken cause and concequence There is nothing wrong with yast It should remain possible to have /usr on a separate partition. hw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Sonntag 19 Juni 2011, 21:16:21 schrieb Markus Slopianka:
I just checked myself. I loaded a 11.4 ISO into VirtualBox. YaST only suggests partitions for /, /home, and swap. -- 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ó:
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
Le dimanche 19 juin 2011 à 20:16 +0200, Kay Sievers a écrit :
I've added a reference for that to http://en.opensuse.org/openSUSE:Systemd_status#List_of_open_items_for_system... and tagged it with "ENTERPRISE" keyword (might not be the best keyword ;) Could we try to teach mkinitrd / initramfs about /usr right now ? Or maybe we could add some additional systemd targets to serialize boot a bit when /usr is a separate partition (as an temporary/alternative plan). -- Frederic Crozat <fcrozat@suse.com> SUSE -- 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 <jos@opensuse.org> wrote:
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
Greg Freemyer wrote:
(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?... 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? -- 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:
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.
Jos Poortvliet wrote:
Hint...the design of systemd IS the problem... This is basic logic: If A requires B, AND, B requires C, then A requires C if it really is the case that nothing that systemd 'needs' to boot the system requires that /usr be on the root partition...then I'll agree with you, but according to the rest of this thread, that's not the case. I don't see why the situation can't be fixed or worked around -- it's just software, I will speak up against throwing out what has been considered "best practices" in the software industry in regards to partitioning for the past 20-30 years just to upgrade to some latest software tool. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Monday 20 June 2011 10:23:45 Jos Poortvliet wrote:
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
Am 20.06.2011 11:23 schrieb Jos Poortvliet:
I'm happy that the Linux kernel has a different philosophy. If you want to add $FEATURE to the kernel and it _exposes_ bugs elsewhere in the kernel which cause userspace breakage, _you_ are expected to fix those bugs to get $FEATURE merged. If someone has a wound covered with a band-aid, removing the band-aid is not the problem, the wound is the problem. Still, only very few people will rip off the band-aid before the wound has healed. wound = broken /usr dependencies band-aid = old sysvinit Regards, Carl-Daniel -- 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 20.06.2011 22:23 schrieb Cristian Rodríguez:
Examples from the 11.4 default package selection please. :-) Regards, Carl-Daniel -- 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:
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
On Tue, Jun 21, 2011 at 12:54:10AM +0200, Carl-Daniel Hailfinger wrote:
sysvinit is not suitable nor accountable for ignoring dependcy rules of the boot and runlvel scripts. Those rules are well defined but if those dependcies will be ignored by e.g. udev rules and packagers and/or upstream developers of low level tools this will cause troubles. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-06-19 19:23, Jos Poortvliet wrote:
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 Sun, Jun 19, 2011 at 17:26, Carlos E. R. <carlos.e.r@opensuse.org> wrote:
So... is it possible to mount /usr at initrd time? -- Robert Xu + Linux is awesome; don't doubt what it can do + rxu(at)lincomlinux(dotttttt)org -- 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:
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.
Jos Poortvliet <jos@opensuse.org> writes:
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. -- Susanne Oberhauser SUSE LINUX Products GmbH +49-911-74053-574 Maxfeldstraße 5 Processes and Infrastructure 90409 Nürnberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le lundi 20 juin 2011 à 13:38 +0200, Susanne Oberhauser a écrit :
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 <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 20/06/11 07:38, Susanne Oberhauser escribió:
Now I hear someone shout "corner cases!", and "server problem, not my problem!".
I suspect you have never done the actual work that supporting this scenario requires don't you ? -- 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:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-06-20 13:38, Susanne Oberhauser wrote: ...
Thank you! - -- 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/i2EACgkQtTMYHG2NR9WlHwCglikpazNHT3BuT15a5nXC/WG5 +aEAoJT9zX3/pK2NYBzcS+sy1ItETMjt =IDkr -----END PGP SIGNATURE----- -- 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ó:
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
On 6/20/2011 2:51 PM, Cristian Rodríguez wrote:
I think it's utterly stupid for anyone to ever download a kitten picture too but I know it's not my place to actually break the ability to for my convenience. More realistic example, I haven't personally had any use for swap in a decade and haven't even configured any on any system in almost that long. But you'll not see me attempting to decide for everyone else that swap is a dead concept from the stone age and we should actually rip it right out of the kernel because anyone who thinks they need it is actually wrong. -- bkw -- 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:
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
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. -- 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 <crrodriguez@opensuse.org> wrote:
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
El 20/06/11 18:30, Greg Freemyer escribió:
On Upgrade, I would expect sysvinit users to remain so, with no change, and systemd for clean, new installations. The "disk space argument" (of which I disagree with btw), problems with many VMs, mentioned in other threads can be solved once btrfs gets filesystem deduplication working. The "memory usage" problem can be fixed using KSM (Kernel Samepage Merging) -- 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 <crrodriguez@opensuse.org> wrote:
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
El 20/06/11 19:42, Greg Freemyer escribió:
If true, that has a huge impact on this whole thread (group of threads).
As usual, I’m voicing my opinion on this topic, not announcing "truth" ;) I guess the fact I have been there, hands-on this particular problem off the high-horse of theory and PM, entitles me to a voice ;-) I know I've been assuming a more or less forced migration
even for existing installs that want to upgrade to 12.1.
An immediate, forced migration at this stage does not sound right me, but since there is no way in hell I will devote anymore time in this "/usr problem" (for the reasons described in http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken) I will have to accept what maintainers and/or people doing the actual work decide. -- 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:
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
Cristian Rodríguez wrote:
--- Not a stone age case. People still use it today which you should obviously see by the amount of discourse and people SAYING they use it.
Sorry, not seeing the benefit here
--- First you have to have an idea for what makes a good boot design. During the boot, binaries should come from /sbin, /bin and *should* use static linkage, though /lib and /lib64 are also usually on a root disk, so conceivably, boot libs could be there. 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 -- but that's why c++ progs are almost always dynamically linked.... -- 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.
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 6/21/2011 9:33 AM, Cristian Rodríguez wrote:
Both of those responses (no static bins, no language limit) are less than well thought out. This is booting and early startup. The nice theoretical full featured environment with access to lots of nice modular libraries and lots of ram to load them in and to run feature rich fat c++ compiler output in are provided BY the OS, and don't exist before then and so can't be used for the purpose of getting the OS up and running in the first place. Booting itself is a corner case. Some boxes only do it once every 3 years. It still needs to work as reliably as any other part of the system. I think people are tossing around the phrase too lightly and too inconsiderately. Everything you don't do is not a "corner case" and some of those "corner cases" actually pay for much of what we all enjoy for free or cheap. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, Mine stalled, too, for about 8 minutes and then continued on it's merry way. This may or may not be similar to yours... It was the fsck running in the background. I found this bug on redhat's bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=679492 Again, this could be totally unrelated to your issue. Cheers, Max On Mon, Jun 20, 2011 at 3:38 AM, Roman Bysh <rbtc1@rogers.com> wrote:
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 06/19/2011 05:38 PM, Roman Bysh wrote:
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 -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 06/19/2011 11:46 AM, Bruno Friedmann wrote:
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 Sunday 19 June 2011 18:23:08 Roman Bysh 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. See: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Roman
On 06/19/2011 01:23 PM, Jos Poortvliet wrote:
In response to the devs reminding me of my 80's partition config: <snip 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. <snip 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:
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
participants (21)
-
Brian K. White -
Bruno Friedmann -
Carl-Daniel Hailfinger -
Carlos E. R. -
Cristian Rodríguez -
Dr. Werner Fink -
Frederic Crozat -
Greg Freemyer -
Hans Witvliet -
Jos Poortvliet -
Kay Sievers -
Linda Walsh -
M. B. Shah -
Markus Slopianka -
Peter Linnell -
Peter Nikolic -
Robert Xu -
Roman Bysh -
Stephan Kulow -
Steven Sroka -
Susanne Oberhauser