Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2012-11-14 00:52, Greg Freemyer wrote:

...

So the question / bugzilla is why /usr is not mounted in your case.

Indeed. The change was done on 12.1 IIRC, and I have a 12.1 machine with separate /usr partition and it works fine. I think I also tested 12.1 in that situation and worked fine.

That's not the problem -- as I've had 12.1 installed for 6 months and it has worked fine -- and none of my boot lines in lilo.conf have initrd in them (i.e. sample kern image:) image = /boot/vmlinuz-3.6.3-Isht-Van label = 363-Isht-Van append = "root=/dev/sdc1 showopts console=ttyS0,115200n8 console=tty0 elevator=cfq pcie_aspm=force pcie_ports=native" root = /dev/sdc1 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-14 01:31, Linda Walsh wrote:

I have no initrd -- and I never saw this solution proposed on this (as someone else calls it, "development discussion" list -- and they thought this wasn't a development issue?).

I did. You need initrd- If you do not want to use it, then you will need to hack your own solution. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCi6swACgkQja8UbcUWM1xjiQD/bEg7W8g6HL3kSXhZZ5h60GEr UY8dUbRWrDJtRGbygvMA/09lxcpU5r1rIrfOvLzBPyx5zBqCkxV8V7YO2TzGNu18 =ARtE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2012-11-13 19:54 (GMT-0500) Patrick Shanahan composed:

...

Linda Walsh wrote:

...

...

I have no initrd -- and I never saw this solution proposed on this (as someone else calls it, "development discussion" list -- and they thought this wasn't a development issue?).

And this is *still* factory discussion list, not 12.2 which has been released. Discussion belongs on opensuse list.

I disagree, considering this type of topic a gray area. Policy and development decision discussion on the opensuse help list, before or after a release, is useless to even try. Decision makers don't seem to spend much time participating there. Maybe it really belongs there, but that it might wouldn't likely make fruitful. Of course, it did get discussed here, so if Linda didn't already she should comb through the archives (and Bugzilla) to see whether there's any hope to gain anything by trying to discuss anywhere. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2012-11-14 01:31, Linda Walsh wrote:

...

I have no initrd -- and I never saw this solution proposed on this (as someone else calls it, "development discussion" list -- and they thought this wasn't a development issue?).

I did.

You need initrd- If you do not want to use it, then you will need to hack your own solution.

WHY should one need initrd -- just for systemd, no? the linux kernel doesn't need initrd. Why force all customers/users to use it? Just because of systemd? Why would you slow down all customers because of systemd? Why would you no longer support booting directly from a hard disk? Even windows doesn't required a preboot kernel. Yet linux does? Note -- I tried it -- it made debugging boot problems *impossible*. I can't boot single user off of an initrd and bring up my system manually -- as I have had to due more than once (most likely chances of needing it are during a suse distro upgrade (at least since 12.1).. I tried to use the native BIOS modes to display text -- but the boot disk was one-closed monolithic 'thing' that prevents easy debugging and modification of the boot process. At the time, grub wasn't able to boot off my hard disk due to it being incompat with my file system, and suse's initrd wasn't compatible with lilo -- I wouldn't get any output during boot until the login prompt. I was trying to enable 'control-s/control-q' in main boot script to be able to read some error messages as they flew by as they were not logged to disk before the system was crashing. initrd set it's own mode and ignored the files in /etc/init.rc on the root disk. I.e. it was a nightmare to work with. It was also the case at the time that many of grub's features wouldn't work without the kernel already running (like looking up disk labels), so. If it required booting a kernel to support grub -- (I don't know about now), it somehow seemed insane to load some unrelated kernel that generated warnings about missing modules during the mkinitrd phase, that took 3X time to make, just to support a boot util that didn't work natively with my fs. I don't see why there is this drive to make the boot process opaque and unmaintainable/modifiable/debuggable to users when that's the critical time when I need it to work the most. about missing modules during the mk-initrd phase (because they were modules that were built-in to the kernel) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. wrote:

...

WHY should one need initrd -- just for systemd, no?

I don't really know. And it doesn't matter, the decision was made.

The decision to not have to have /usr mounted in order to boot from the root partition was also made. It's broken. That's the part I am complaining about. If you want to require initrd for loading a generic kernel to allow it to be adaptable to a wide range of hardware -- that is entirely understandable. But to mis-use initrd to duplicate /usr/bin as a kludge to support a broken design is NOT OK.

Initrd is needed for many things,

It is NEEDED for nothing in 12.1. This need has been sprung because someone corrupted the rpm's and did BAD engineering design to make the root-boot partition dependent on another file system. That's bad design and seriously bad morals to have snuck the dependency in after it was specifically agreed on this list NOT to be done. This is incredibly 'Microsoftian' -- insomuch as their paladium design was horribly rejected and hated in reviews on all levels. So they put it in the next OS Visa, under the covers and in the guise of increased security. They solidify it more in win7 and take away the desktop in win8 -- moving toward being able to sell win8 as a DRM-safe-from-tampering solution delivery platform. Now I see some similar behaviors and motivations at oSuS, with similar requirements for a giant-blob to boot from that is not easily scrutinized or modifiable. I see the requirement that systemd be started by the boot loader rather than allowing it to be loaded by init -- as an alternate to the boot scripts -- why? Because if it is init users, could alter inittabs to put in their layers before systemd gets loaded and there goes the secure execution guarantee that would be needed to make oSuse into another secure DRM appliance OS -- safe from user tampering. I am NOT saying that is necessarily the motivation here, but it looks bad -- and smells bad. There's no reason why systemd can't be launched by the kernel and mount the disks it needs in its earliest steps, or are you saying it is not even close to being as flexibile as the initrc system? If that's the case, it needs to be launched by init after init has executed it's boot scripts. Then it will be happy. This solution was proposed and is still on the table unless there is a compelling engineering reason not to do such -- otherwise, that bad smell smells worse.

it just happens that the solution for /usr handling in a separate partition has to be done as well with initrd.

Why? Why not in /etc/boot.d/xxx?

If you have another solution... up to you. :-)

The consensus at the time was to not use systemd if it had such requirements . I was told that it no longer had those requirements. Was that also a "misdirection"? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-14 04:20, Andrey Borzenkov wrote:

В Tue, 13 Nov 2012 18:57:04 -0800

Do you want to have separate /usr? In this case providing technical arguments why separate /usr is required would be nice. If you did, I must have overlooked them.

No, that point is moot. When the issue was discussed here it was demonstrated that there were sound reasons to have /usr on a separate partition for some people or circumstances, and the solution was to put the required parts into initrd. We are not going to argue again why /usr separate is good or bad, needed or not. The point Linda makes is that there should be no need for initrd. Too late to make that point, IMHO. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCjEHsACgkQja8UbcUWM1wX8gD/dlwsG5fRdK86/gntl8NPdkle 39J/IVF3Rgyq9h37CbUA/j/VRA4WafmJkoQBOuQXxDyGz8GOpnokWHXh0JdpNX/8 =unOi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Wed, 14 Nov 2012, Carlos E. R. wrote:

On 2012-11-14 01:31, Linda Walsh wrote:

...

I have no initrd -- and I never saw this solution proposed on this (as someone else calls it, "development discussion" list -- and they thought this wasn't a development issue?).

I did.

You need initrd- If you do not want to use it, then you will need to hack your own solution.

WHY? Using initrds for binaries and libs residing in /usr/ just for the heck of it, each binary and lib duplicated in each initrd is IMO just useless. Put those binaries and libs in /bin, /sbin and /lib and *whoa* you can get rid of the initrd! Or most of it anyway. In my case, each initrd (compressed!) 4.5M big (i.e. ~11M uncompressed). And I don't even actually need the initrd. The only kernel-modules in there are cpufreq/fan/thermal stuff that could well be loaded later. BTW: that move cluttering up /usr/ is IMO just bad. I thought it was bad when KDE/Gnome/X still lived in /opt/kde, /opt/gnome and /usr/X11, but now? $ ls /usr/bin | wc -l 5150 $ ls /usr/lib64/ | wc -l 3833 This is better exactly why, again? Oh, and if you insist on the move to /usr/, why isn't /etc moved to /usr/etc and /root to /home/root? Eh??? /dev/ and /proc/ and /sys/ and /mnt and /srv/ and ... also moved to /usr? Until we get to a / where there's only a '/usr/' in /? And what then? The FS-layout with /bin, /lib[64], /sbin, /root etc. + /usr, /opt and /home has come to be there for good reasons! I'm guessing this whole thing got started by /-tools using libs that resided in /usr and not linking /bin and /sbin stuff statically anymore, the first was glib IIRC. So, glib moved to /lib. More libs were used. So some of them were moved too, some not. WHY? I don't know and Who's on first. Tell me. Anyway: I think the whole move and reasoning is, ahm, bul^Wnot quite thought through. -dnh -- We're standing there pounding a dead parrot on the counter, and the management response is to frantically swap in new counters to see if that fixes the problem. -- Peter Gutmann -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. wrote:

Because that's the solution the devs here implemented, that's why. If you want a different solution you will have to make a very sound case to convince them (and a year after!) or implement it yourself. Otherwise it is not going to change.

I was told at the time that systemd no longer had this requirement and that it could mount /usr as an initial step. That's why I didn't complain for 'a year after'.. as I trusted those who lied. Now I find out that this was a lie and they were just going to hide systemd's flaws in initd. That's NOT a solution, that was a deliberate fabrication. It could have been solved a year ago -- but they didn't want it solved, they wanted it there way and lied to get it. That's why it is how it is... you can just roll with them lying to your face to surreptitiously sneak this hack into the code, or you can realize that they'll do it again and again, and that there is nothing "Open" about Open Suse, and participation of the user community is only at the sufferance and as slaves doing the bidding of those behind the scenes, who will use the community to do their work, and when it doesn't suit them, will like to the community and implement solutions against the community behind their back -- and THEN expect there will be a large enough number of people who are apathetic who will just throw up their hands and say "what's done is done"... Yet I will say this. Even talking about this as a patch back into 12.2. A post install script can be run to determine and broken dependencies of /root on /usr. and switch them. I.e. put the real files on /root and the soft links on /usr, allowing root to boot, mount /usr, then invoke either initd or systemd as per desire. But it obvious now, that systemd can't handle this -- we were told it could, but we were lied to. So The patch will also eliminate booting directly to systemd and insert initd as that remains compatible behavior -- and it can start the "startup" program of the user's choice. I see no reason why this can't be pushed as a patch to 12.2. For 12.3, it would be better if the patch wasn't needed, but it can run automatically after any install to ensure /root doesn't depend on /usr -- specifically it will ensure that /bin and /sbin don't depend on anything off of the device (there are also deps in /etc/alternatives, but I don't believe those are used as part of boot). Each of the binaries can be scanned with 'ldd' for any libs that have been moved off of root, and the script can also move those to root. It isn't clear that links in /usr would be necessary for those, as /lib , /lib64 are in the ldpath the same as their /usr counterparts -- the only requirement is that libs necessary for boot reside in /lib[64], with no links in /usr required. links in /usr/bin & /usr/sbin will be provided back to the the root images, so applications and systemd that use hard-coded paths to /usr, will be happy. MINIMALLY, this could have been done if we had not been lied to -- and the 15-25 packages that have been modified to move their files off of /bin to /usr/bin, would not have needed to have been modded. For 12.3, they can be modded back so the patch won't be necessary -- and put links where needed from /usr/bin -> /bin. Alternatively, we can go with statically linked objects in /bin and not worry about libs. At runtime, EVERYTHING that is statically linked in /bin can be duplicated in /usr/bin with a non-static version that does what cygwin does -- and after initial boot, mounts /usr/bin on top of /bin as a duplicate mount point -- making them the same and making all future program starts use the shared library. This would also provide (in /bin) a set of programs necessary for creating an emergency boot disc. There are many solutions that could have been thought of and implemented that would have worked for everyone if conversation had not been cut short by us being lied to and told it was no longer a problem or requirement for systemd...

And I'm not saying I like it.

- -- Cheers / Saludos,

Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iF4EAREIAAYFAlCjEWUACgkQja8UbcUWM1xGqQEAln8DUcOlIWwr2Fcq5TJHX7I9 P6y4d1zxv7Jjm4zaCvYA/RYjPclpD66lyzMlFP/v7LNwHm/nTZuwsMXGvZFRYJ5+ =Q6wn -----END PGP SIGNATURE-----

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Jaeger wrote:

Linda, stop accusing people. We always said that an initrd is needed, if you didn't understand that, then it's your problem but stop calling users liars.

It was clear that initrd was needed to load *drivers* for a generic kernel. That was always clear. It was ALSO clear, that it was always an option to recompile the kernel with needed drivers for one's platform to eliminate that need. It was NEVER discussed that that using initrd and

This kind of discussion style does not bring us anywhere, let's end the thread,

---- What type of discussion style do you want, in order to proceed to fix this problem... or is your intent just to stop the fixing of the problem? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Jaeger wrote:

...

...

This kind of discussion style does not bring us anywhere, let's end the thread,

---- What type of discussion style do you want, in order to proceed to fix this problem... or is your intent just to stop the fixing of the problem?

I don't like your accusation style.

you were the one who opened with "lets end the thread", indicating no willingness to engage in any type of discussion. I responded with a question about what discussion style you wanted in in order to proceed with fixing the problem, (i.e. since you indicated your desire to end the thread was based on the style, perhaps a different style would work -- and I offered), or, I asked, was it merely your intent to end the discussion and no style would work. That wasn't an accusation -- it was a question for clarification of how to proceed that would suite you -- OR to clarify that you really didn't care to proceed in any manner, and your intent was just to shut me up. Labeling my offer 'accusatory', paints you in a bit of a bad light. It indicates you aren't willing to discuss things and this isn't OPEN anything. It was and *still is( your choice to respond in a positive way. It's a choice... which I am giving, instead of accusing. That the choice might feel accusatory if you were already closed on the subject an your only mission is to silence me OR you might have misinterpreted my honest attempt at making it a choice. I don't need to do any work to fix it, I can simply send you the spec files for 12.1 and be done with it. Case solved. Now the question becomes, would you accept such a fix? Are you open to it being fixed? So I can ask you again .. what works?

Btw. I'm not considering that openSUSE needs to support mounting of /usr with initrd.

It's your attitude that /usr must be on the same partition as root in order for it to boot -- whether it is on a ram disk or on a physical disk is immaterial. I was told systemd no longer required this. This is the third time I ask -- is this not the case?

If this is a request for you, then support it yourself. openSUSE comes with an initrd and we assume that it's there...

You are breaking 40 years of backward compatibility with absolutely no concerns. You think this is only my issue? You think a slow booting system is only my concern? There were quite a few people who spoke up against this -- and likely the only reason most of them aren't respond (maybe 1 other) is that they have either given up on SuSE as becoming MS's plaything, or given up on Suse being responsive to "the community[sic]"... which is increasingly appearing to be a joke. Nice the way you wipe out 40 years of compat with your own personal fiat - nice dictatorial, non-community response. you want a way to fix it -- go back to 12.1 where the bin-files lived in /bin, not in /usr/bin w/symlinks in /bin... How could anyone justify having a subdir that was KNOWN to be a separate partition on many peoples system be the homedir for bins and put symlinks in the root dir -- ESPECIALLY for MOUNT?!?!?! That's insane!.... I asked for any reason why it had to change from 12.1 to 12.2 -- no one wants to give one. The main effect of this is to break direct boot which seriously compromises development and security. You ignore the issues of speed of boot -- and development. Those are important to many people as well. Yet you ignore those issues. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/14/2012 4:19 PM, Linda Walsh wrote:

Andreas Jaeger wrote:

...

...

...

This kind of discussion style does not bring us anywhere, let's end the thread,

---- What type of discussion style do you want, in order to proceed to fix this problem... or is your intent just to stop the fixing of the problem?

I don't like your accusation style.

---

you were the one who opened with "lets end the thread", indicating no willingness to engage in any type of discussion.

I responded with a question about what discussion style you wanted in in order to proceed with fixing the problem, (i.e. since you indicated your desire to end the thread was based on the style, perhaps a different style would work -- and I offered), or, I asked, was it merely your intent to end the discussion and no style would work.

That wasn't an accusation -- it was a question for clarification of how to proceed that would suite you -- OR to clarify that you really didn't care to proceed in any manner, and your intent was just to shut me up.

Labeling my offer 'accusatory', paints you in a bit of a bad light. It indicates you aren't willing to discuss things and this isn't OPEN anything.

It was and *still is( your choice to respond in a positive way. It's a choice... which I am giving, instead of accusing. That the choice might feel accusatory if you were already closed on the subject an your only mission is to silence me OR you might have misinterpreted my honest attempt at making it a choice. I don't need to do any work to fix it, I can simply send you the spec files for 12.1 and be done with it. Case solved. Now the question becomes, would you accept such a fix? Are you open to it being fixed?

So I can ask you again .. what works?

...

Btw. I'm not considering that openSUSE needs to support mounting of /usr with initrd.

---

It's your attitude that /usr must be on the same partition as root in order for it to boot -- whether it is on a ram disk or on a physical disk is immaterial.

I was told systemd no longer required this. This is the third time I ask -- is this not the case?

...

If this is a request for you, then support it yourself. openSUSE comes with an initrd and we assume that it's there...

---

You are breaking 40 years of backward compatibility with absolutely no concerns. You think this is only my issue?

You think a slow booting system is only my concern?

There were quite a few people who spoke up against this -- and likely the only reason most of them aren't respond (maybe 1 other) is that they have either given up on SuSE as becoming MS's plaything, or given up on Suse being responsive to "the community[sic]"... which is increasingly appearing to be a joke.

That describes me. These changes break my real world operations and my ability to effectively admin my systems, but complaining about that only results in personal attacks and disregard. They could have developed all these new plans off to the side and gotten them to the point where they worked and provided all the same flexibility and features we already have, and included ways to avoid breaking backwards compatibility and standard unix expectations, and only moved them into the official system after the new ways were of that level of quality. I would not have minded that. Give me a systemd that doesn't break anything old, and I won't even notice that you swapped it in. Then let me discover all the new possibilities it offers at my discretion instead of forcing this breakage on me, and forcing me to have to halt all new installs at 11.4 or 12.1 while I scramble to either migrate to some other system or figure out how hard it would be to maintain sysv init all by myself on newer opensuse, or maybe switch to sles and buy (literally) a little time that way (even though I don't like sles but it's less broken than newer opensuse). You're not allowed to say you have a problem with these things as higher level engineering decisions that are just wrong in principle for many, countless, reasons. And you're not allowed to say you have a problem with these things for specific reasons either, because the answer is just "you're doing something weird that we don't support". Most of what you're saying is just common sense rational engineering and I agree completely. But I mostly stopped complaining once I realized exactly what you said. It's pointless. The kids want to play with their toys and they don't care about any scenarios they themselves don't happen to suffer, and are no good at imagining situations they haven't had themselves directly, and do not see any value in flexibility and the concept of unix as a tool box of small efficient distinct purpose low level tools that you assemble as needed into any kind of system you may need. They don't understand what a key core foundation principle that is, or how all other goodness flows from that. Unix, including linux, is supposed to be an alphabet, a tool box, and an engine, not a black box product. Apple and MS already sell black box products and they are a fine for some people. But I want better and that's why I use unix, in the form of opensuse currently. If opensuse wants to target the same kind of desktop user that Windows and OSX currently serve, that is their right. It just sucks for us because it means it's no longer an efficient system to base servers on. I don't mean efficient in cpu terms at run-time. I mean for me the admin and architect, and for my employer and customers getting good results out of me and what I can do for them. (It's not efficient for them that I have to spend time fighting against tools that used to be reliable and transparent, but now are fragile and opaque.) Since much of the rest of the linux market is doing the same thing, I too am revisiting my old choice to use linux instead of bsd back when we switched off of SCO. I'm not sure what I'll do eventually but I do not thank the opensuse developer collective for forcing me into a scramble. I already have a busy busy job. I did NOT need this. It's a ton of work to figure out if I can switch to systemd (probably I can but there are other problems besides systemd, some of which are only here because of systemd though), if I can maintain sysv init on new versions of opensuse almost all by myself, if I can work around plymouth and grub gfxboot and KMS on serial console-only boxes _reliably_, if I can switch entirely to centos, or redhat, or something even more different like gentoo or arch or debian, or if I can buy a little time by switching to SLES, or switch to freebsd... There are pros and cons to all of those and they take a lot of time and work even just to work out how feasible they are to even begin to make a choice. What I can't do is stay arrested at 11.4 or 12.1 too much longer because unlike the old days, everyone always needs to stay up on security updates even if they don't actually want any other new features. No I do not thank them for putting me in this position. And I am not highly motivated to be a helpful contributor when complaints of this nature are so disregarded, even sneered at. -- bkw

Nice the way you wipe out 40 years of compat with your own personal fiat - nice dictatorial, non-community response.

you want a way to fix it -- go back to 12.1 where the bin-files lived in /bin, not in /usr/bin w/symlinks in /bin... How could anyone justify having a subdir that was KNOWN to be a separate partition on many peoples system be the homedir for bins and put symlinks in the root dir -- ESPECIALLY for MOUNT?!?!?! That's insane!....

I asked for any reason why it had to change from 12.1 to 12.2 -- no one wants to give one. The main effect of this is to break direct boot which seriously compromises development and security.

You ignore the issues of speed of boot -- and development. Those are important to many people as well. Yet you ignore those issues.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dr. Werner Fink wrote:

Please be aware that most modern journaling file systems nowaday should be checked unmounted and with the internal system time of the kernel set to UTC (just in case if local time is used in CMOS) to have correct time stamps later on. That is such file systems may even not mounted ro before fsck has done its work. After the internal system time is in UTC and the file system (including its journal) is corrected by the file system check has been done the root file system can be mounted.

How do you want to do this without using an initrd? Please be aware that we would not do initrd stuff if not required to avoid data loose due corrupted file systems.

---- The most optimal way for deficient file systems that need fsck is likely to use an initrd if it is needed that often. The alternative is to pick an advanced journaling file system rather than a modern one that, for me, has only needed a real 'fsck', only *once* in the past 12 years of constant usage. For one -- if your root FS is small, you are less likely to corrupt it. Two -- the whole point of a journalling FS is to not need a full FSCK -- even NTFS from MS doesn't need booting from an initrd -- only RARELY does it need an offline check -- maybe once every 5 months -- and it has EVERYTHING on it's root FS (the entire OS and all programs (it's 1 partition because that's the only partition that gets completely backed up during backup). But xfs -- 1 time in the past 12 years I've needed to do an xfs_repair on a root file system. To require to spend extra time and space for something that happens once in a Jovian year, is not logical. To use "modern" journaling file systems that haven't (almost though with ext4), but haven't quite gotten up to the level of an advanced corporate filesystem, doesn't quite make sense. With each revision ext4 gets closer... they've added features at each step that get it closer to xfs, but clearly they haven't hit the bar yet because, as you say, they require root-fsck's often enough to require it be offline and to boot from a ramdisk. FWIW -- IRIX solved the problem before ram disks were common by providing something similar to an initrd/ramdisk that you'd copy to the swap partition and run from there -- a "miniroot", from which you could repair / modify root. That was in place 20 years ago. I never needed it. And in the past 12, I the one time I needed a root check, I could run it from a DVD (or now a USB key)... It's not worth requiring something that only has to be done once every 12 years. If you really want to use a file system that requires it more often, then having the option to boot from initrd is certainly something I have and still do, whole heartedly support, but to require it for all is certainly forcing the requirements of the lowest-common-denominators on everyone. It's effect is to try to eliminate any benefits from doing anything "different" -- when linux has always been about being able to configure the software to suite you. These types of changes make it EXTREMELY difficult to customize and optimize boot. One of the reasons given for this whole mess was boot performance. But given the figures of going with no-initrd and xfs, that reason seems to have been dropped. Is boot performance really a "we don't care, we're faster than 2-3-10 minute MS, so it doesn't matter?" OSse could be alot faster for EVERYONE if some basic conventions were observed, like the ability to have required HW modules statically linked and installed on your root -- and have your root FS be xfs. Then, no need for initrd. It could all be done automatically by scripts at run time -- (I wouldn't want it done at boot time if it were me -- when it is booting, I don't want to wait for a kernel compile that I can do myself in background when the system is running in a few minutes (2:22 w/>300 modules). All it takes is a willingness to want to do it rather than go the extremely round-about-way of loading a 20-40MB initrd (cf. my kernel=~5MB), which duplicates /usr/bin. You asked how it could be done, I've mentioned more than one way -- it really depends on how often your rootfs needs to be checked. If it needs to be checked every boot...I would strongly advise most people to consider changing their rootfs.

Werner

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday 16 November 2012, Dr. Werner Fink wrote:

On Thu, Nov 15, 2012 at 01:10:29PM -0800, Linda Walsh wrote:

...

The most optimal way for deficient file systems that need fsck is likely to use an initrd if it is needed that often. The alternative is to pick an advanced journaling file system rather than a modern one that, for me, has only needed a real 'fsck', only *once* in the past 12 years of constant usage.

In other words: as this had worked for you the last 12 years due luck you want that all other users may risk data loose?

The initrd lives also on a filesystem which can't be checked before mounting it (at least using grub). And moreover the initrd can be broken itself. From my practical expirience I had more often a broken initrd than a broken root file system. Also repairing a file system is IMO usually more easy than repairing a broken initrd, specially since the initrd got more and more complicated. Anyway, having the possibility of booting without initrd does not force any user to do it. But removing that possibility is one more step to reach the final goal to have a non-configurable system ... cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-16 12:24, Dr. Werner Fink wrote:

What does mean broken initrd? The only case I'm remembering is compiling and installing a kernel and then forgot to run mkinitrd.

To tell the truth, factory had a broken initrd for a week or two, needing a rescue system to repair. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCmNFgACgkQja8UbcUWM1xjVgEAlFgZRJVxtgciIu59F1cjT2Yv hLoZGulDPRH6LYDK9I4A/26MWdsV3LvEI2oL7WILFfsM2m8NIlJ8m3iOeY2/09KS =WxoY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 15.11.2012 22:10, schrieb Linda Walsh:

of loading a 20-40MB initrd (cf. my kernel=~5MB), which duplicates /usr/bin.

susi:~ # ls -l /boot/initrd* -h lrwxrwxrwx 1 root root 22 Nov 12 11:58 /boot/initrd -> initrd-3.6.3-1-default -rw-r--r-- 1 root root 11M Nov 12 11:58 /boot/initrd-3.6.3-1-default -rw-r--r-- 1 root root 11M Nov 12 11:59 /boot/initrd-3.6.3-1-desktop -rw-r--r-- 1 root root 11M Nov 12 11:59 /boot/initrd-3.7.0-rc4-4-desktop (OK OK, I'll stop feeding the troll...) -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 16 Nov 2012 19:23:54 -0800 Linda Walsh wrote:

Ahh.. resorting to childish name calling now.

Linda, it is childish they way you act. Whole a lot of long emails to tell something we all know: openSUSE is for SUSE what is Fedora for Red Hat, a fast changing test bed that is not really suitable for real stuff. Those that need stability either purchase SLES or SLED, or look how to keep alive Evergreen releases. There is nothing in between for those that want SUSE brand. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Per Jessen wrote:

Rajko wrote:

...

On Fri, 16 Nov 2012 19:23:54 -0800 Linda Walsh wrote:

...

Ahh.. resorting to childish name calling now. Linda, it is childish they way you act.

Whole a lot of long emails to tell something we all know: openSUSE is for SUSE what is Fedora for Red Hat, a fast changing test bed that is not really suitable for real stuff.

Didn't we go over this some months back? I agree that openSUSE is becoming less and less suitable for a lot of my work, but I thought it was made quite clear that openSUSE is not a testbed for anything.

Hmmm... and here I was almost thinking rajko was being ironic ... referring in a backhanded way to the downward slide of quality and stability... ;-/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, 2012-11-18 at 12:44 -0600, Rajko wrote:

On Sat, 17 Nov 2012 23:35:37 -0800 Linda Walsh wrote:

...

... referring in a backhanded way to the downward slide of quality and stability...

Not really.

It is the fact that openSUSE is upstream for SUSE enterprise products, but also, that majority of code contributors are SUSE employees, which, in effect, makes openSUSE playground for new technologies in the exactly the same way as Fedora.

Actually this puzzles me a bit. I work for a rather large organisation and have considerable number of SLES machines (SAP, oracle, ...) At last product presentation one of the product managers came from Nurnburg, at was specifically asked what plans there were considering initrd/systemd. We were told clearly and with no reservations that there were __NO__ plans whatsoever to introduce systemd into sles. So this can mean a couple of things: 1) SLES and opensuse are drifting apart. (as in: initrd only maintained for sles) 2) "Plans has changed" in the mean time and if SLES12 is going to use systemd, SuSE is going to loose customers. Considering the growing market share of "the competitors", is this not a path they are likely to take... 3) Is there a third option? hw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday, November 18, 2012 21:57:52 Hans Witvliet wrote:

On Sun, 2012-11-18 at 12:44 -0600, Rajko wrote:

...

On Sat, 17 Nov 2012 23:35:37 -0800

Linda Walsh wrote:

...

... referring in a backhanded way to the downward slide of quality and stability...

Not really.

It is the fact that openSUSE is upstream for SUSE enterprise products, but also, that majority of code contributors are SUSE employees, which, in effect, makes openSUSE playground for new technologies in the exactly the same way as Fedora.

Actually this puzzles me a bit.

I work for a rather large organisation and have considerable number of SLES machines (SAP, oracle, ...)

At last product presentation one of the product managers came from Nurnburg, at was specifically asked what plans there were considering initrd/systemd.

We were told clearly and with no reservations that there were __NO__ plans whatsoever to introduce systemd into sles.

I don't know when this was said and by whom - but it's not the current state. As was said at SUSECon this year in Orlando, we do plan to introduce systemd into SLES 12. If you have concerns with that, then let's talk off line since SLES is not on topic here.

So this can mean a couple of things: 1) SLES and opensuse are drifting apart. (as in: initrd only maintained for sles) 2) "Plans has changed" in the mean time and if SLES12 is going to use systemd, SuSE is going to loose customers. Considering the growing market share of "the competitors", is this not a path they are likely to take... 3) Is there a third option?

Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-14 17:43, Andreas Jaeger wrote:

On 11/14/2012 05:37 PM, Linda Walsh wrote:

Linda, stop accusing people. We always said that an initrd is needed, if you didn't understand that, then it's your problem but stop calling users liars.

This kind of discussion style does not bring us anywhere, let's end the thread,

I remember a thread where I asked if a separate /usr partition would be supported, and you people answered that yes, via initrd. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCj1qgACgkQja8UbcUWM1yvOAEAg5Si8Hb0sZoBgiR85I0g6uzU PyKDzG8fGcJrBOWPccgA/AiVizu8b9HxadV0AbpgJCLMpnzimQJPFCpXQ1F4ituj =RhSu -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Felix Miata wrote:

On 2012-11-14 08:37 (GMT-0800) Linda Walsh composed:

...

I was told at the time that systemd no longer had this requirement and that it could mount /usr as an initial step.

If systemd is your problem, why are you using it? Most of my 12.2 systems are on sysvinit.

So Are mine. That's why it fails -- it came up after 12.2 installed, and coudn't mount anything because someone moved mount to the non-root disk -- and it couldn't mount anything. Why would someone put 'mount' on the non-root disk? If you ask any linux admin if that is at all a sane option, of course you'd get a negative answer -- I mean, how do you mount something if mount is on a mounted disk? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Wed, 14 Nov 2012, Felix Miata wrote:

If systemd is your problem, why are you using it? Most of my 12.2 systems are on sysvinit.

It'll go away, probably. Packages won't ship initscripts anymore etc... Oh, and I'm counting on you help maintaining sysvinit. -dnh, who probably will be using sysv as long as feasible -- On-line, adj.: The idea that a human being should always be accessible to a computer. -- BSD fortune file -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Wed, 14 Nov 2012, Linda Walsh wrote:

That's why it is how it is... you can just roll with them lying to your face to surreptitiously sneak this hack into the code, or you can realize that they'll do it again and again, and that there is nothing "Open" about Open Suse, and participation of the user community is only at the sufferance and as slaves doing the bidding of those behind the scenes, who will use the community to do their work, and when it doesn't suit them, will like to the community and implement solutions against the community behind their back -- and THEN expect there will be a large enough number of people who are apathetic who will just throw up their hands and say "what's done is done"...

Bullshit! Linda, as much as I don't like a lot that is going on, that stuff is not exclusive to openSUSE. A lot comes from upstream, like kde.org, gnome.org and freedesktop.org. What you're implying is just not true. There is a lot of stuff I dislike in openSUSE recently (e.g. the move to /usr), but, sadly, that stuff is everywhere else too. The move to /usr, systemd/upstart, udisks, udev, upower, the whole *(Console|Policy|Package|whatnot)Kit* kerfuffle, ... so far, I got away with only using udev (which still bugs me), but mind you, I had to "break" some deps getting there ... You get that even in gentoo (though you can overlay your own ebuild there, so you can get what upstream provides). -dnh, keeping track of the *BSD alternatives -- What boots up must come down. -- Paul Tomblin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Wed, 14 Nov 2012, Linda Walsh wrote:

David Haller wrote:

...

Linda, as much as I don't like a lot that is going on, that stuff is not exclusive to openSUSE. A lot comes from upstream, like kde.org, gnome.org and freedesktop.org. Really? The full list of files and rpms that changed on my system are below.

freedesktop.org defines standards and develops stuff. E.g. avahi, dbus, fontconfig, pkg-config, plymouth, pm-utils, policykit, portland, shared-mime-info, startup-notification, xdg-utils, Xft, Xorg all come from/via freedesktop.org. See http://www.freedesktop.org/wiki/Software Try building / installing any _GUI_ software without using stuff from freedesktop.org and/or Gnome/KDE.

What in the desktop rpms require themselves to be brought up BEFORE disks are mounted?

That fancy bootsplash stuff does.

Is your intention to make openSUSE a desktop only OS?

Last I've used a "desktop" was KDE 1.1.2. I use WindowMaker. I do not use any bootsplash, *DM. Nor any indexing (tracker, zeitgeist, akonadi, whatever), besides locate, mktexlsr/kpsewhich and my own-scripts. The fanciest I use is gkrellm and that's mostly because it can display a lot of info on little space (even the mixer plugin works ;) -dnh -- Optimist: There is a light at the end of the tunnel. Pessimist: ... it is an oncoming train. Cynic: ... and it is late. -- D. C. Staples -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Sat, 17 Nov 2012, Linda Walsh wrote:

David Haller wrote:

...

On Wed, 14 Nov 2012, Linda Walsh wrote:

...

David Haller wrote:

...

Linda, as much as I don't like a lot that is going on, that stuff is not exclusive to openSUSE. A lot comes from upstream, like kde.org, gnome.org and freedesktop.org. Really? The full list of files and rpms that changed on my system are below.

freedesktop.org defines standards and develops stuff. E.g. avahi, dbus, fontconfig, pkg-config, plymouth, pm-utils, policykit, portland, shared-mime-info, startup-notification, xdg-utils, Xft, Xorg all come from/via freedesktop.org. See http://www.freedesktop.org/wiki/Software But my point was that none of the binaries that were moved from "/" to /usr, were desktop related .. i.e. -- none of the files that were moved are on the list you just gave.

That means it is "gratuitous" package moving from upstream.

Linda, you need to re-read this sub-thread more carefully. I'm actually arguing your case! So far, I've read (not from you certainly) "we can move this from /{bin,lib,lib64,sbin} to /usr/ because we require an initrd anyway." A bogus argument if you ask me. I want to be able to boot with a self-rolled kernel without any initrd and with a seperate /usr partition. Even if I don't use that right now.

Gkrellm is pretty nifty, though I don't like the fact that it can't resize a tad larger, so I use xosview.

You can resize gkrellm, just not via WM-methods, but via configuration. Which is quite appropriate for what gkrellm was designed for. Ask me via PM if you need help.

So far, I see no reason why the I listed can't remain in / and be linked from /usr. Then none of this would be an issue.

I see no reason for even linking for more links from /usr to /. If more links would be needed, it'd just be another description for "I broke it". -dnh -- "Don't put off 'till tomorrow, responsibilities. They'll just come back to haunt you. (Ignore them totally)" -- TISM -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote

For everybody that is unhappy - just go to OpenBSD! NO systemd, NO journalctl, GOOD OL inetd, and BEST of all - it's FREE of evil initrds!

Switching kernels is a much larger jump than even switching distro's. I have no clue whether all my HW would even work on BSD -- it might, but that's a much larger step than necessary. Below that is switching distro's which is another unknown, as you might be taking in a larger number of new problems that you didn't know about -- i.e. preferring to jump into the unknown vs. dealing with the devil you know. Third -- why does everyone assume that one should leave when one doesn't like some 5% of something. Isn't it alot more productive to work to change the 5%? I mean if everyone who didn't like 5% of the US's government policies, got up and left, the land would be vacant. Those in charge would like us to believe they are omnipotent and their decisions are final and users have no input into the situation -- but if that was true -- why would they care if we left or not? In fact, if they were secure, they'd want us to stay to build user-base numbers. The fact that several suggest the discontented 'leave' rather than work to change the status quo, only indicates that those who have made this decision don't really want to hear about different views because it raises for public airing the lame decisions made with little review, that they want to pass for 'design decisions'. What appears to be so is that more senior engineers have left the openSuSE project -- while some may be left, it appears to be dominated by those who don't have as much experience and are willing to make radical changes. I would say it is only incumbent upon those who have concerns and cares for compatibility and would like to see it ALL work -- (NOT an "either/or" proposition where they create losers, but a flexible solution that allows openSuse to remain a general purpose distribution that works for non-engineering-flavored end-users, as well as developers, and as a corporate desktop solution. There seem to be an increasingly small number of senior engineers in the openSuse community willing to speak out against rush toward latest features and damn the compatibility. More often than not, I'm willing to let things go if I can work around it -- but the problem with this change is it breaks compat with much software that is out there -- the paths alone are a nightmare. So maybe if I keep asking 'why' it's necessary to move all the files that were moved from /bin, /sbin-> /usr/{s,}bin eventually someone will either figure out a good reason, OR figure out that it doesn't have to be broken unnecessarily -- and that they just didn't know how to make it work. I don't pay attention to this list on a daily basis, but when I was told that the software was being improved and no longer required /usr (and apparently /usr/share -- lets be clear -- /usr/share is a separate partition for me as well) to be mounted at boot. Now I find out changes are going in anyway and I want to know why it has to be be on /usr. I can't see anything other than bad design in this -- and that doesn't bode well for all the engineering and investment that has already gone into it. But I'm more likely to try to change my current situation than throw it all away and starting with a complete unknown.... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

It is NOT about attracting users; that is at best a side effect. It is about creating a system that we like ourselves. And to do that, people work on specific areas they are interested in. sysvinit has not seen a lot of this interest, and non-initrd has even less so far.

That's because it worked. Why put in work on something that works? You want to see a change-set making it possible not to use initrd, -- I submit 12.1 sources.

...

So maybe if I keep asking 'why' it's necessary to move all the files that were moved from /bin, /sbin-> /usr/{s,}bin

So that they become shareable, but you do not seem to want to understand that just yet.

----- Um... My /bin, /sbin/ /lib64 are all shared. I don't have a problem doing that. Why does anyone else? You want it in 1 share?, use linux mount with bind and remount them all on /rt and re-export that. You want them merged, use the mergefs and export that. There are already ways to do what you want without moving anything and creating incompats. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org