On 2012-11-15 10:26 (GMT+0100) Bernhard Voelker composed:

...

Moreover, what is there on initrd that you can't put in root?

Find out yourself:

$ mkdir /tmp/initrd $ cd /tmp/initrd $ gzip -dc - < /boot/initrd | cpio -i $ find . -ls [...]

It's a question of timing, e.g. how do you want to do an fsck of the root file system when you have it already mounted?

Isn't that why many distros put ro on cmdline, to mount / readonly until after it passes check?

And have a look into run_all.sh. -- "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

Bernhard Voelker wrote:

It's a question of timing, e.g. how do you want to do an fsck of the root file system when you have it already mounted?

And here is the problem. Only if you use a file system that Needs fsck is this important. Look at fsck.xfs. It's a shell script that determines whether or not the file system is mounted. If you want a reliable system, you use xfs. If your rootfs has mounted, you've already passed fsck. It's all about reliability and being sure your system boots... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Nov 15, 2012 at 03:35:55PM +0100, Ruediger Meier wrote:

On Thursday 15 November 2012, Andrey Borzenkov wrote:

...

On Thu, Nov 15, 2012 at 12:17 PM, Linda Walsh <suse@tlinx.org> wrote:

...

Give me ANY reason.

Personal experience.

- mount by LABEL/UUID/whatever, but not by /dev/sdX. Uncountable times I got support call after adding some additional storage after installation and staying before system that does not boot.

- support for root on layered storage. Yes, it probably can be done without initrd, but even Solaris moved to initrd at the end after all those years.

- minimal debugging environment in which I am able to poke around when root is not found instead of just cursing blindly

...

claims to need 400GB in root?! Talk about a broken model to be following!

You still need 400GB be it on two partitions or on one partition. Why exactly one is more broken than two?

For example just to have more admin-comfort from within the running system in case you need to umount it. - fsck - switching file system - shrinking file system

BTW what about having /usr read-only or mounted via NFS? Is this still possible?

No ... most libraries used by mount and nfs client services like mapping pids/gids, kerberos for v4, and so on are below /usr ... you may list all daemons and the used libaries for e.g. nfs v4 and see how many stuff you have to move to / 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 To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 15.11.2012 15:39, schrieb Dr. Werner Fink:

On Thu, Nov 15, 2012 at 03:35:55PM +0100, Ruediger Meier wrote:

...

On Thursday 15 November 2012, Andrey Borzenkov wrote:

...

On Thu, Nov 15, 2012 at 12:17 PM, Linda Walsh <suse@tlinx.org> wrote:

...

Give me ANY reason.

Personal experience.

- mount by LABEL/UUID/whatever, but not by /dev/sdX. Uncountable times I got support call after adding some additional storage after installation and staying before system that does not boot.

- support for root on layered storage. Yes, it probably can be done without initrd, but even Solaris moved to initrd at the end after all those years.

- minimal debugging environment in which I am able to poke around when root is not found instead of just cursing blindly

...

claims to need 400GB in root?! Talk about a broken model to be following!

You still need 400GB be it on two partitions or on one partition. Why exactly one is more broken than two?

For example just to have more admin-comfort from within the running system in case you need to umount it. - fsck - switching file system - shrinking file system

BTW what about having /usr read-only or mounted via NFS? Is this still possible?

No ... most libraries used by mount and nfs client services like mapping pids/gids, kerberos for v4, and so on are below /usr ... you may list all daemons and the used libaries for e.g. nfs v4 and see how many stuff you have to move to /

That rules out NFS but not ro, if I understand correctly. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Andrey Borzenkov wrote:

On Thu, Nov 15, 2012 at 12:17 PM, Linda Walsh <suse@tlinx.org> wrote:

...

Give me ANY reason. Personal experience.

- mount by LABEL/UUID/whatever, but not by /dev/sdX. Uncountable times I got support call after adding some additional storage after installation and staying before system that does not boot.

If you want reliability, you mount root by dev -- that's another reason to make it small.

- support for root on layered storage. Yes, it probably can be done without initrd, but even Solaris moved to initrd at the end after all those years.

Layered? Like RAID? My root runs on RAID5 -- works great. If you have a HW raid card that's handled outside the OS. Again -- reliability is the key.

- minimal debugging environment in which I am able to poke around when root is not found instead of just cursing blindly

I have that as well. Not much you CAN'T put on a 14G root. That's larger than the distro's DVD.

...

claims to need 400GB in root?! Talk about a broken model to be following! You still need 400GB be it on two partitions or on one partition. Why exactly one is more broken than two?

We are talking about what is necessary to boot, all the apps you want to run. At one point openSuse went with XFS as the default file system (1 release I think). It moved away from that when it wanted to use the, then broken grub manager -- which was known to be unreliable at that time. Many of the decisions above come a lack of need for reliability. My machine boots in another room -- and doesn't run a graphical console on boot. Suse is promoting the idea of virtual machines usable as appliances -- many of those don't need a "Desktop". If you want reliable, this entire push for a unified Usrbin/lib is a negative for reliability. MANY legacy scripts with fixed values for the distro's basic utils are failing in 12.2. This will be a corporate nightmare as those fail. I've seen 10 year old scripts fail in 12.2 as well as many rpms. Shells have always lived in /bash, along with many other basic functions. You are voiding compatibility with 40 years of unix scripting -- stuff that will no longer work without being modified for OSuSE. If you want reliability, Make your basic utils *statically* linked, and then load dynamically linked versions in /usr/bin, and put /usr/bin first in the path. Again -- all about reliability. How many times have we seen on this list about the current release being non-bootable? This would almost never happen if the root was static and small -- it makes testing easy. You wouldn't have users posting how to fix their systems if they could get to an operational shell prompt with basic utils. As it is now -- I see many messages of them posting where they are screwed -- The current system is incredibly *fragile*. Please note -- there has been no reason given for the need for an initrd -- EVEN differing HW is easily solvable. If they user *wants* direct boot, you compile a kernel with the modules their machine needs to boot *once*. Then you have 2 choices. You stick with rebuilding the kernel on kernel updates, OR, you load an updated kernel from a mounted partition and pivot to the new kernel. If you want the optimization step, you can run it AFTER boot, in background and update the root-kernel -- so it doesn't slow down boot. Not only is it more reliable -- it streamlines the boot process. As the boot process is now, many users boot twice -- first off the ram disk to load support for disk "labels", and *then* they can boot from a labeled root unless you already have a running OS to find the label with 'udev' -- UNLESS, you use 'lilo'. Again.. we are talking reliability over features. I boot from a labeled root -- but the root is labeled when I install the kernel to boot from. I get booting from a labeled root, off of RAID5, with a kernel tailored for my HW...that takes 20% the space of the current solution w/an initrd. Guess which loads ALOT faster when being loaded by the block-loader of the BIOS... Points in my processes favor: reliability, speed, easy to get to a working single user to fix problems should they arise. Even easy to get to login from a remote shell when there are problems if you disable "unreliability features" that have been added to prevent boot if any 'T' is not crossed, or 'i' is not dotted. If you want reliability, and speed, the choice is clear. What are the supposed benefits of an initrd again? So far, I see only reasons given due to use of other unreliable pieces of software. If reliability was a priority -- if speed of boot was a priority, these issues would never have come up. But choices have been made to provide things that can be added *after* boot. But so far, EVERYTHING, that has been given can be done without initrd -- both FASTER and with vastly improved reliability. So what is so important that you would sacrifice a high level of reliability and a large speed boost to provide the indirect step of using an initrd? Note -- for working on a root partition -- which was rare, when memory was tight, a 'miniroot' (a rescue type system) was copied into SWAP, and run from there. -- then root could be moved/resized, or whatever. Now days, equivalent functionality can be done from a RAM disk most often. There is no need for initrd, and getting rid of it in the default case would improve reliability, performance and speed of boot. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Nov 15, 2012 at 2:53 PM, Ralf Lang <lang@b1-systems.de> wrote:

And all this "move stuff to /usr/ because it's cool to be different" has been announced long before 12.2's release and probably been discussed even longer before.

Sorry, it's "move stuff to /usr" because we want to be able to have a read-only system, to be able to stop linking statically lots of things (which increases memory consumption by a great deal)... it's not just to be cool. All that has been discussed already and can be googled and found in lots of places, not only this list. In any case, in that discussion, IIRC the decision to leave symlinks in /bin was made to be backwards-compatible. With those symlinks, a script would only break if run from an initrd script, before /usr is mounted. Is that your case Linda? If not, I think you should file a bug report. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Nov 15, 2012 at 3:27 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:

Claudio,

Linda is running without a initrd at all, but with a separate / and /usr. As of 12.2 that is no longer a supported config, thus bugzilla is not the way to go.

I know that, if her problem was related to the initrd. But if scripts aren't working solely because of a missing symlink in /bin, then a bug report is the way. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Greg Freemyer wrote:

On Thu, Nov 15, 2012 at 1:14 PM, Claudio Freire <klaussfreire@gmail.com> wrote:

...

With those symlinks, a script would only break if run from an initrd script, before /usr is mounted. Is that your case Linda? If not, I think you should file a bug report.

Claudio,

Linda is running without a initrd at all, but with a separate / and /usr. As of 12.2 that is no longer a supported config, thus bugzilla is not the way to go.

She is arguing that for 12.3, that config should be supported again.

AIUI, she has offered some reasonable to me arguments, but they are based on the user self-compiling a kernel without the use of modules, so it's a relatively small install base I would guess that does that.

That's not what I would suggest. I have mentioned it in passing but could see how it might easily have been missed... Most users wouldn't know how to do this. I would see optimizing the kernel for your machine as an option that users could select in yast (or similar). It would select the modules on initrd for inclusion in a kernel -- builds it and installs it -- just like DKMS modules need to be custom built on the end-user's site for their environment. Unless a user is switching out HW on a regular basis, a given system will be fairly stable -- and they could go months after compiling that kernel with no initrd. That technology was something that was already in place at major unix vendors (Sun, SGI) 20 years ago -- if you wanted to optimize your boot time, you had the option of running a script that would install a non-portable OS -- built just for your setup that would be installed for subsequent boots. It wasn't a requirement to do it -- but it did make booting about 33% faster. Users didn't have to know anything "technical" to click on a button to run the script. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Nov 15, 2012 at 5:03 PM, Linda Walsh <suse@tlinx.org> wrote:

A safer option would have been to move all of /usr/bin into /bin and put the symlinks in /usr, then you'd have your path compatibility of everything in /usr, AND you'd have the safety of being able to use everything in /bin when /usr isn't mounted.

But you would have a huge (and active) root fs, which is exactly the opposite of what was desired. Not to mention un-shareable. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 15 November 2012, Patrick Shanahan wrote:

* Linda Walsh <suse@tlinx.org> [11-15-12 15:05]: ...

...

A safer option would have been to move all of /usr/bin into /bin and put the symlinks in /usr, then you'd have your path compatibility of everything in /usr, AND you'd have the safety of being able to use everything in /bin when /usr isn't mounted.

Then *you* should have participated in the discussion before the change was made.

Linda has participated there ... but the whole discussion was totally useless because somehow the decision was already made before. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2012-11-15 09:09 (GMT-0800) Linda Walsh composed:

At one point openSuse went with XFS as the default file system (1 release I think). It moved away from that when it wanted to use the, then broken grub manager -- which was known to be unreliable at that time.

I've installed every openSUSE release multiple times, most at least a dozen times. Until 12.2, for me who always uses EXT3 for / and if using separate /boot always EXT2 for it, the default boot manager has always been Grub. Starting with 12.2 I never use the default boot manager (Grub2). For me, Grub IIRC has been reliable, though YaST's configuration of it only almost as good. -- "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

On Thu, 15 Nov 2012 09:09:17 -0800, Linda Walsh <suse@tlinx.org> wrote:

If you want reliability, Make your basic utils *statically* linked,

a) Only works for binaries that don't use any of the name resolving functions like gethostbyname as name resolution needs the nss* libs and they are *always* loaded dynamically, even if glibc itself is linked statically. b) static binaries are a maintenance nightmare from the security POV. Instead of updating one dynamic library you need to update x statically linked binaries.

There is no need for initrd, and getting rid of it in the default case would improve reliability, performance and speed of boot.

Then use OpenFATE to suggest such a feature for a future OpenSUSE version. Declaring it here on the list is a sure way of making it go unnoticed. BTW, could you please make up your mind as to which mailing list you want to address and stop that unneeded crossposting? Philipp -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

В Thu, 15 Nov 2012 09:21:33 -0800 Linda Walsh <suse@tlinx.org> пишет:

however, if your addition of disks has changed the "sd" ordering, it won't boot from the correct disk and your initrd won't be loaded either.

Not every device seen by Linux is also seen by BIOS. And there are systems that do not use BIOS for booting but are still running Linux. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Greg Freemyer wrote:

...

however, if your addition of disks has changed the "sd" ordering, it won't boot from the correct disk and your initrd won't be loaded either. This is slightly off-topic: Linda, I admit that is a struggle because I reconfigure computer drives all the time. Each bios seems to have it's own way to break the boot process as drives,

On Thu, Nov 15, 2012 at 12:21 PM, Linda Walsh <suse@tlinx.org> wrote: thumbs, USB DVD drives are added and removed. I bought a nice Intel MB a couple weeks ago. It was the first one I have seen that had a "static" option.

It's mostly Windows that is guilty of re-ordering drives in my experience. I can add/remove drives -- the main floppy, USB drives, Add/remove sata drives.. Doesn't affect my linux device names that I boot from on a Dell system. But it's *not* automatic. If I add new HW, I go into the BIOS and make sure it's still in the boot order I want. The only time it changes is if a drive before my boot drive is take out/removed, then the bios moves the drives "down". My 'a+b+ drives are SAS-based raid arrays, which I tell the bios to mount first. But I boot off of drive C, the same as when I had 2 floppies there. I can add/remove CD's, as they aren't disks, they don't change anything, if I add a SATA disk -- still doesn't matter -- as I tell my BIOS to boot off-board (meaning in a slot, vs. soldered), cards first and I tell it the order to be the card in slot 0 vs. slot 5). Barring me taking drives (there are 2 RAID-based drives attached to the card in slot 0). Another reason I have "smallish" system drives .. I use 15K SAS drives which are smaller. To get the space I have & optimize speed, I 'short-stroke' the array, using only the first half of 3-72GB drives, with 1 being parity. Effectively I only have 72GB for all of '/', '/usr', 'var, var/cache, swap, boot. My larger storage disks are everything else -- all 2TB 7200 SATA's hooked up to a RAID SAS controller, split between "sda" and "sdb". sdb for backups is a RAID6 6 data disks. sda is my main work disk -- which is split into volumes using lvm -- seek times aren't as fast as on the root HD, but linear speeds are good -- it's configured as a RAID50 using 3 groups of 5. The 1 disk left over is a global spare. I don't even have room for /usr/share on the root drives anymore -- it grew too big -- so my /usr/share lives on /home/share, which is then mounted via bind to /usr/share. One thing that doesn't get advertised much, is that /usr/share -- specifically meant to be non-arch-specific, shared-content, is ALSO being required now in order to boot. So it's not just /usr, but /usr/share as well (and likely others will be added over time). But as an example, my /usr/share is in /home/share, that means /home needs to be mounted as well -- all of this worked fine under 12.1. Even with /usr mounted, the newest stuff in factory won't necessarily boot -- as /usr/share wasn't mounted. Now maybe that's because /home (on an lvm based device) wasn't mounted, or maybe they didn't also mount / process the 'binds' and 'rbinds', or maybe they didn't do it in the right order: 1. / (root) 2. /usr 3. /home 4. /usr/share (from /home/share). I don't know where it failed, as I had to mount /usr/ manually and call boot & init scripts after that. Note -- my boot failed because of a new, added, "screw-you" check (one that catches a compliance error but serves no useful purpose). Someone put in a superfluous and ill-considered check to make sure your root disk is read-only upon booting, because they "know"[sic], that you can't run a file system's "fsck" script on a writable disk. But that's just stupid -- for 2 reasons: 1) if fsck can't run due to a disk being writable, then it will die with an error saying it can't do the check -- so the first check is redundant. 2) if fsck CAN run with a disk being writable, then the extra check just screws you over -- for no technical reason. Again, this is an example of changes going in with no thought behind them (or, worse, with deliberate malicious intent). I'm presuming that they simply didn't use their brain and didn't think the logic through -- which given the choices -- is actually a positive assessment. I also had the mount for /dev/hugetbls fail -- because it's mount point had not been created on /dev. Why? because udev exited early -- because /usr/share/somthing wasn't available to process some other device! As near as I can tell, some very seriously screwed circular dependencies are in the making that will make bringing up a system from any sort of 'problem state', near impossible -- that is the "benefit" of moving to a separate /usr and forcing initrd. In my case, udev needed to create devices, but exited / died when it couldn't access something in /usr/share -- that wasn't there because /dev wasn't populated to allow mount of /home/share. It's bad enough when one can't mount /usr because mount is on /usr, but if you can't get udev running, and that forces /usr/share to not be mountable (which udev needs), OpenSuse has created a maintenance nightmare. The idea of spreading dependencies out across all of the disks is going to lead to more circular logic problems (just like the need to mount /usr one needs 'mount', but some rocket scientist put that in /usr/bin. Of course the idea of mounting is 'moot' anyway, since a reason given for needing initrd was to check disks if they needed it (fsck)... he pointed to xfs_repair (usually only run after xfs_check, in my experience) -- neither of which is even on initrd, let alone called as part of any boot process. So if /usr doesn't mount -- you can't check it anyway, so the idea that you need initrd to precheck the disks is also moot. Someone else suggested that you needed to decrypt disks -- but if that was true, how can you read initrd or the boot image if they are encrypted? Isn't it true that those routines need to be already built into your kernel if you want to use them? If you want an encrypted root disk, then you can preboot from a ram disk(initrd), but to decrypt it requires the decryption be built into the kernel -- if you do that, you also need the ram disks and loopback support builtin. I would be surprised if the linux kernel didn't have a way of booting with an encrypted root, w/o an initrd. Do you see how many problems just mounting /usr in initrd can be. It's known to be unreliable (I've had failures with unbootable systems in the past, and factory required a rescue disk to boot all of last week to get around initrd bugs). It's NOT just 1 bad thing .. it's several at this point and the number will continue to climb as people insist on going down this poorly thought out path. Let Red Hat commit Hari Kari alone -- it will only help those who don't follow the head lemming. If they finish their work and still have customers... and it shows any benefit -- maybe THEN consider moving in that direction, but as it stands now, you can get the same benefits without kneecapping yourself. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Greg KH wrote:

On Thu, Nov 15, 2012 at 12:17:47AM -0800, Linda Walsh wrote:

...

So far no one is able to explain why it is needed other than It's a fad or it's cool..

Because the openSUSE kernel is not monolithic, it contains modules that need to be loaded before mounting the root disk. It also needs to do other things (decryption, disk checks, etc.)

If you have those options, you are free to use an initrd, but as pointed out -- OSus. doesn't support disk checks for XFS, so it's a moot point.

Yes, if you build your own kernels, and don't put /usr/ on a different partition, you can get away without a initrd, I do it all the time.

--- Before 12.2, it was ONLY a requirement to build your own kernel. Now, you have to move /usr... AND your /usr/Share partition -- that was meant to be architecture independent, shareable data, vs. /usr that was designed for usr level application, vs. /bin+sbin that contained a smaller number of programs that were considered your trusted computing base -- making a trusted system easier to verify. Adding /usr and /usr/share -- you can through those ideas out the window.

But for the distro, as shipped, it's not going to happen, sorry.

--- And this is why opensuse isn't open. These decisions are made by behind the scenes and are not open to discussion. As for not gonna happen...maybe not, but repair packages to undo your damage can be developed and widely distributed. The idea of fixing systemd to run in a container as a subprocess of init seems prudent as it seems like it is as invasive as a virus. -- 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-18 12:06, Claudio Freire wrote:

I'm no expert on LSB, but I think you got that wrong. usr stands for Unix System Resources (not user as many assume, including myself a while back). What you're mentioning goes in /usr/local

/usr/local is the same as /usr but built locally. - -- 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/ iF0EAREIAAYFAlCoykgACgkQja8UbcUWM1wRWwD3YQwnUsq3ybd8aw/BHza3BHks ZW8cPV2bDosHBJoesAEAl86wLM+n86tgvSpRF+wUNsjZEEbFvztATxewfDNinTU= =bPTq -----END PGP SIGNATURE----- -- 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-18 13:32, Felix Miata wrote:

On 2012-11-18 12:45 (GMT+0100) Carlos E. R. composed:

...

/usr/local is the same as /usr but built locally.

You mean outside the package management system, rpm in e.g. openSUSE, Fedora & Mageia? It's where I've normally put purchased binaries unavailable via rpm packages and FOSS binaries compiled by e.g. Mozilla.org distributed as bzip* files.

Yes. Well, purchased binaries I put in /opt. - -- 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/ iF4EAREIAAYFAlCo2aQACgkQja8UbcUWM1wmQAD9GRf1ZDHZqSjV8u0MRUc4nx8J 7uU1NX+ke63fMmjZe1IA/itZPivi5Kqc36HAUraXwpDTcTvE4pIYbjqON4tHP+9V =+V0A -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Claudio Freire wrote:

I'm no expert on LSB, but I think you got that wrong. usr stands for Unix System Resources (not user as many assume, including myself a while back). What you're mentioning goes in /usr/local

Nep. /usr = short for /user... as separate from system. Not user owned, or local user added, but user applications. Even user home directories were (are?) placed under /usr (or a subdir of it). It was things you didn't need to boot, but did to do other tasks. None of the original unix commands or words were strictly acronyms with the possible exception of 'awk'...as I can't think of what word was shortened to create that name. None of those names came from LSB and none are captalized as in acronyms.. /usr/local is stuff added locally by usrs on that system. They were all created as short commands because the unix creators weren't great or fast typists and wanted short commands (seriously, I think it was Ritchie who documented that fact). A full spelled out list of commands -- they'd have wrote tl;dr. -- 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-18 19:27, Linda Walsh wrote:

...

Nep. /usr = short for /user... as separate from system.

Wrong.

Sorry, but have a quote of Dennis Ritchie one of the founders of Unix (dated from 1972) "In particular, in our own version of the system, there is a directory "/usr" which contains all user's directories, and which is stored on a relatively large, but slow moving head disk, while the othe files are on the fast but small fixed-head disk. --- So From some history of unix pages (google origin /usr /bin in unix) In the original Unix /usr housed homedirs for user accounts as well as other stuff of general interest to users.. this remains partially true today. You can find a note from Dennis Ritchie's,[above] So system stuff was traditionally kept in /bin and possibly /sbin, while "shared" user stuff may have been in /usr/bin instead. I have a few older commercial Unix flavours for x86, they also typically put user stuff in /usr. ---- There you have it -- it's not just 'me', it's embedded in the history of Unix. I put /bin and /sbin on the fastest disks in the fastest location on those disks. That's why you put your boot software there. Despite fantasies to the contrary, disk speeds -- especially seek speeds have not increased so rapidly. The root disk is where your boot and system software is normally kept -- while applications like desktop audio video..etc are kept in /usr. Not one person has come up with even 1 reason why system files need to be moved to live on /usr.

...

/usr/local is stuff added locally by usrs on that system.

No.

See, this is what I meant, by the more senior people having left. Anyone who'd been around during unix's development would know its history... It's not like you can just make things up (just like a need to move boot files to the 'user' partition -- and why? Cuz, we want to? No reason other than that? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Greg KH wrote:

On Thu, Nov 15, 2012 at 12:17:47AM -0800, Linda Walsh wrote:

...

So far no one is able to explain why it is needed other than It's a fad or it's cool..

Because the openSUSE kernel is not monolithic, it contains modules that need to be loaded before mounting the root disk. It also needs to do other things (decryption, disk checks, etc.)

Yes, if you build your own kernels, and don't put /usr/ on a different partition, you can get away without a initrd, I do it all the time.

Why must /usr be on the same partition again? I made a list of files & packages moved from / to /usr: The rpms containing the cross-linked dependcy changes. Not one of these is desktop related that I can tell -- they are all low-level utils. bridge-utils-1.5-10.1.2.x86_64 btrfsprogs-0.19-43.10.1.x86_64 btrfsprogs-0.19-47.1.2.x86_64 coreutils-8.17-2.1.x86_64 cpio-2.11-18.1.2.x86_64 crda-1.1.1-15.1.2.x86_64 dhcpcd-3.2.3-47.73.1.2.x86_64 dosfstools-3.0.10-22.1.2.x86_64 ed-1.6-2.1.2.x86_64 eject-2.1.0-162.1.2.x86_64 ethtool-3.2-3.1.2.x86_64 fbset-2.1-936.1.2.x86_64 fillup-1.42-265.1.2.x86_64 gawk-4.0.1-2.1.4.x86_64 grep-2.13-1.1.2.x86_64 hdparm-9.39-3.1.2.x86_64 ifplugd-0.28-228.1.2.x86_64 initviocons-0.5-96.1.2.x86_64 iproute2-3.4.0-2.1.2.x86_64 iputils-s20101006-16.1.2.x86_64 kexec-tools-2.0.2-14.2.4.x86_64 lsvpd-1.6.5-47.1.3.x86_64 mailx-12.5-2.1.3.x86_64 ntfs-3g-2011.4.12-3.1.2.x86_64 ntfsprogs-2011.4.12-3.1.2.x86_64 util-linux-2.21.2-4.2.3.x86_64 xfsprogs-3.1.6-9.1.2.x86_64 And the rpms with libs they reference that were moved to /usr: krb5-1.9.1-24.9.1.x86_64 libblkid1-2.21.2-4.2.3.x86_64 libgcrypt11-1.5.0-9.2.2.x86_64 libgpg-error0-1.10-7.1.3.x86_64 liblzo2-2-2.06-6.1.2.x86_64 libmount1-2.21.2-4.2.3.x86_64 libpcre1-8.31-1.3.x86_64 libsqlite3-0-3.7.12.1-2.1.2.x86_64 libstdc++46-4.6.2_20111026-1.1.4.x86_64 libvpd2-2.0.3-15.1.2.x86_64 ---- List of files: in /bin/ arch basename cat chgrp chmod chown cp cpio date dd df dmesg echo ed egrep eject false fgrep fillup findmnt gawk grep initviocons ip kill ln logger ls lsblk mail md5sum mkdir mknod mktemp more mount mv ping ping6 pwd readlink rm rmdir in /sbin/: adjtimex agetty arping blkid blockdev brctl btrfs btrfs-convert btrfs-dump-super btrfs-find-root btrfs-image btrfs-restore btrfs-select-super btrfs-zero-log btrfsck btrfstune cfdisk chcpu clockdiff crda ctrlaltdel dhcpcd dosfsck dosfslabel ethtool fbset fdisk findfs fsck fsck.btrfs fsck.cramfs fsck.minix fsck.msdos fsfreeze fstrim hdparm hwclock ifenslave ifplugd ifplugstatus in.rdisc ip kdump kexec losetup lscfg lsmcode lsvio lsvpd mkdosfs mkfs mkfs.bfs mkfs.btrfs mkfs.cramfs mkfs.minix mkfs.msdos mkfs.ntfs mkfs.xfs mkswap mount.lowntfs-3g mount.ntfs-3g nologin pivot_root raw regdbdump sfdisk swaplabel swapoff swapon switch_root tracepath tracepath6 wipefs ***xfs_repair*** and in /lib64: libblkid.so.1 libgcrypt.so.11 libgpg-error.so.0 libgssapi_krb5.so.2 libk5crypto.so.3 libkrb5.so.3 libkrb5support.so.0 liblzo2.so.2 libmount.so.1 libpcre.so.1 libsqlite3.so.0 libstdc++.so.6 libvpd_cxx.so.2 ----------------- Now a big issue made by Dr. Werner Fink was the ability to be able to run xfs_repair. Note it was moved from /sbin to /usr/sbin. This means if /usr doesn't mount because it needs xfs_repair, then it is inaccessible. It isn't on the initrd either, so root can't be checked. Reality is that it is almost never needed and booting from a rescue disk is the wisest solution. But claiming that initrd was needed to check the file system when the check util has been moved to a later-mounted file sytem?? That blows that out of the water. Claiming that initrd is needed to load modules? Needed?? Maybe during install -- but there is no reason why a dynamically built kernel with the modules needed for boot couldn't be linked after install -- just like DKMS modules are built for a specific system's environment, the kernel could be rebuilt or re-linked as well. Again -- no need for initrd.

But for the distro, as shipped, it's not going to happen, sorry.

--- That much is clear. 12.2 is out the door. That's why Patrick Shanahan said this had to be a 12.3 issue to even be discussed on the factory list.

In fact, I don't know of _any_ distro that does not provide an initrd, this isn't a new thing at all, sorry.

*providing* an initrd is not new. Requiring it is. It's not even in a format that can be mounted directly. You have to have a booted kernel running before you can extract it -- as it's a cpio image, not a disk image.

If you want to have a separate /usr partition, then you are free to support it without an initrd as well as you can, but note, that's not what openSUSE is going to do.

---- you haven't said 'why' -- other than you want to shove this down user's throats and screw people over. Is that your power trip? I've asked several times why those binaries couldn't have **remained** in root (or why the patches that move them can't be removed)... and have softlinks in /usr. I'm able to recover from a completely broken boot by mounting /usr by its device name -- there's no reason why that mount of /usr couldn't be done in the 'boot' scripts (before the "rc" scripts and before systemd is called.

If you don't like this, ... you are free to change [it] to something else

---- That's why I am pushing to have this fixed in 12.3.

Best of luck, greg k-h

Thanks, I knew I could rely on your support. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Nov 18, 2012 at 7:02 AM, Dirk Gently <dirk.gently00@gmail.com> wrote:

It's just like KDE 4.0 all over AGAIN.

If it weren't for YaST, I would of ditched this distribution controlled by the biggest bunch of arrogant asshats in the community years ago.

YaST rocks... Um.. Anyway, I guess you haven't experienced the gnome3... "phenomenon" in debian testing. At least suse was kind enough to keep kde3 until kde4 was working right. On Sat, Nov 17, 2012 at 5:06 PM, Linda Walsh <suse@tlinx.org> wrote:

Now a big issue made by Dr. Werner Fink was the ability to be able to run xfs_repair. Note it was moved from /sbin to /usr/sbin. This means if /usr doesn't mount because it needs xfs_repair, then it is inaccessible. It isn't on the initrd either, so root can't be checked. Reality is that it is almost never needed and booting from a rescue disk is the wisest solution. But claiming that initrd was needed to check the file system when the check util has been moved to a later-mounted file sytem?? That blows that out of the water.

I see your point, and I raise you a "What about including it on the initrd?" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org