[opensuse-factory] When was it decided /usr had to be on root? -- thought it was decided that wouldn't be done?
I stared upgrading to 12.2 -- and all was going fine until I rebooted. Then complete failure -- had to use rescue disk. Why? Because it's expected that /usr/{s,}bin will be on the root partition (or the same partition as /{s,}bin). 77 files are cross-linked in /sbin, including: swapon, xfs_repair, pivot_root/switch_root fbset fsck findfs (used by mount to find labels or UUID's on disks) losetup --- /bin: arch -> /usr/bin/arch basename -> /usr/bin/basename cat -> /usr/bin/cat chgrp -> /usr/bin/chgrp chmod -> /usr/bin/chmod chown -> /usr/bin/chown cp -> /usr/bin/cp cpio -> /usr/bin/cpio date -> /usr/bin/date dd -> /usr/bin/dd df -> /usr/bin/df dmesg -> /usr/bin/dmesg echo -> /usr/bin/echo ed -> /usr/bin/ed egrep -> /usr/bin/egrep eject -> /usr/bin/eject false -> /usr/bin/false fgrep -> /usr/bin/fgrep fillup -> /usr/bin/fillup findmnt -> /usr/bin/findmnt gawk -> /usr/bin/gawk grep -> /usr/bin/grep initviocons -> /usr/bin/initviocons ip -> /usr/sbin/ip ipg -> /usr/bin/ipg kill -> /usr/bin/kill ln -> /usr/bin/ln logger -> /usr/bin/logger ls -> /usr/bin/ls lsblk -> /usr/bin/lsblk mail -> /usr/bin/mailx md5sum -> /usr/bin/md5sum mkdir -> /usr/bin/mkdir mknod -> /usr/bin/mknod mktemp -> /usr/bin/mktemp more -> /usr/bin/more ****mount -> /usr/bin/mount**** mv -> /usr/bin/mv ping -> /usr/bin/ping ping6 -> /usr/bin/ping6 pwd -> /usr/bin/pwd readlink -> /usr/bin/readlink rm -> /usr/bin/rm rmdir -> /usr/bin/rmdir --------------- Needless to most of the startup scripts fail due to all the basic utils missing, but the worse -- /bin/mount requires /usr be mounted in order to run mount. Last I understood, this WASN'T going to be done (out of the systemd "discussion"...). So how do I boot now w/o a rescue disk? How is it that this made it past anyone else who cared as I know I wasn't the only one. Historically, "/bin" was supposed to contain statically linked binaries -- though at worst, have their libs in /lib which was also expected to reside on the root fs. /usr was where all the "larger" programs were -- ones that required lots of linkages, but the basic system was expected to be able to come up in single user without /usr being mounted. There was a reason why that choice was made and many people pushed for it -- one of those reasons -- being able to boot when /usr wasn't mounted -- also, historically, /usr, being larger, took longer to "fsck", um... so what happened? Worse, BTW, it's not so simple as to simply copy those binaries to /bin -- as many of them now have 1 or more linkages on /usr/lib:
ldd /usr/bin/mount linux-vdso.so.1 (0x00007fffc5fff000) libmount.so.1 => /usr/lib64/libmount.so.1 (0x00007fa8d143d000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fa8d121f000) libc.so.6 => /lib64/libc.so.6 (0x00007fa8d0e78000) >>> libblkid.so.1 => /usr/lib64/libblkid.so.1 (0x00007fa8d0c50000) <<< libdl.so.2 => /lib64/libdl.so.2 (0x00007fa8d0a4c000) /lib64/ld-linux-x86-64.so.2 (0x00007fa8d1669000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fa8d0847000)
--- i.e. "mount" can't function because *1* of it's library files has been moved to /usr. why??? Why did it have to move? Could someone explain to me why I shouldn't feel betrayed and lied to? Can this be fixed ASAP -- better, use time travel and make it not happen in the first place. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Linda Walsh wrote:
upgrading to 12.2, ... rebooted...complete failure -- had to use rescue disk. 77 files are cross-linked in /sbin, including: ... /bin: ...
FWIW, packages affected/broken: Broken packages on /usr: coreutils-8.17-2.1.x86_64 cpio-2.11-18.1.2.x86_64 ed-1.6-2.1.2.x86_64 eject-2.1.0-162.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 initviocons-0.5-96.1.2.x86_64 iproute2-3.4.0-2.1.2.x86_64 iputils-s20101006-16.1.2.x86_64 mailx-12.5-2.1.3.x86_64 util-linux-2.21.2-4.2.3.x86_64 Broken packages on /usr/sbin: bridge-utils-1.5-10.1.2.x86_64 btrfsprogs-0.19-47.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 ethtool-3.2-3.1.2.x86_64 fbset-2.1-936.1.2.x86_64 hdparm-9.39-3.1.2.x86_64 ifplugd-0.28-228.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 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 ------- (Note, util-linux has files in both places, so shows up twice). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Linda Walsh <suse@tlinx.org> [11-13-12 18:21]:
I stared upgrading to 12.2 -- and all was going fine until I rebooted. Then complete failure -- had to use rescue disk.
...
Could someone explain to me why I shouldn't feel betrayed and lied to?
Can this be fixed ASAP -- better, use time travel and make it not happen in the first place.
You have asked an "opensuse" question of the opensuse-factory list where development is discussed. Please ask your question on the proper list, opensuse. List-Subscribe: <mailto:opensuse+subscribe@opensuse.org> -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Patrick Shanahan wrote:
* Linda Walsh <suse@tlinx.org> [11-13-12 18:21]:
I stared upgrading to 12.2 -- and all was going fine until I rebooted. Then complete failure -- had to use rescue disk.
You have asked an "opensuse" question of the opensuse-factory list where development is discussed. Please ask your question on the proper list, opensuse.
Um, since when is package development not a development issue? This isn't a usability issue, this is a development choice that breaks being able to boot from a root partition that then mounts everything else. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Nov 13, 2012 at 6:20 PM, Linda Walsh <suse@tlinx.org> wrote:
I stared upgrading to 12.2 -- and all was going fine until I rebooted. Then complete failure -- had to use rescue disk.
Why? Because it's expected that /usr/{s,}bin will be on the root partition (or the same partition as /{s,}bin)
Linda, For clarity that is NOT expected. What is expected is that either /usr/{s,}bin is on root OR that /usr will be mounted by initrd prior to the normal boot scripts etc. kicking in. Here's one of the first blog posts about it. I believe this was before a decision was made. Note that this was over a year before 12.2 was released: http://lizards.opensuse.org/2011/08/03/mounting-usr-in-the-initrd/ So the question / bugzilla is why /usr is not mounted in your case. Greg -- 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 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. - -- 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/ iF4EAREIAAYFAlCi4WkACgkQja8UbcUWM1zSaQD/VfREYdOlEEFvQAUr5oTgeus0 3wLvTCF99yxQRU7fIPgA/iTsLT6XFeZEqtfLchSXBU1mTqkIF0sZOcI6tqiJiTIf =Uk0F -----END PGP SIGNATURE----- -- 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 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
Greg Freemyer wrote:
On Tue, Nov 13, 2012 at 6:20 PM, Linda Walsh <suse@tlinx.org> wrote:
I stared upgrading to 12.2 -- and all was going fine until I rebooted. Then complete failure -- had to use rescue disk.
Why? Because it's expected that /usr/{s,}bin will be on the root partition (or the same partition as /{s,}bin)
Linda,
For clarity that is NOT expected.
What is expected is that either /usr/{s,}bin is on root
OR that /usr will be mounted by initrd prior to the normal boot scripts etc. kicking in.
Here's one of the first blog posts about it. I believe this was before a decision was made. Note that this was over a year before 12.2 was released:
http://lizards.opensuse.org/2011/08/03/mounting-usr-in-the-initrd/
So the question / bugzilla is why /usr is not mounted in your case.
Greg
One of the issues that was raised in the discussion was that some people boot from their root partition which then mounts everything else. 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?). If everything "fits" on an initrd, they why not leave it on root? For that matter, if the user has no initrd, why not convert initrd's "bin files", into an rpm that would go into /bin (or additional dirs on a rootfs). More importantly -- WHY move the files to /usr/bin anyway? Was this JUST to ensure /usr/bin HAD to be mounted before system startup -- JUST for systemd? I asked this before -- and never got an answer. Microsoft uses a systemd control process to launch all of it's services and load drivers. Why would I want to move to such an opaque process that when it breaks (which too often), is impossible to crack open and debug/fix on line or in reasonable time? It can't be performance -- I have heard that mentioned as a reason -- but Windows takes over twice as long or more to get to a user-prompt (or desktop) as linux does. I.e. the current startup in linux with init-scripts is easily 2x the systemd-model's speed. When the init scripts boot up and do not run long-delaying scripts (that windows often runs in background and still is slower! ;-)), we are talking about 40-50 seconds for boot of a server with ~50TB of storage, running bind/sendmail/samba/IMAP, squid, ssh, spamd, and many more. But that's all a side issue. Why did the files have to be moved -- I have had several rpm-build's fail because the specs had hard-coded paths for the utils when the links either weren't there yet, or were maybe using moved-programs that links had not been provided for (dunno.. copied all of the linked files from /usr/bin back to bin and the libblck to get back to a working system -- a hack, I admit, but I was more interested in getting back to working at the time than anything else. I can't see why soft links were not placed in /usr/bin and pointed to in /bin, -- that would have been completely safe and backwards compat -- /usr/bin files could only be referenced after root was loaded -- making it safe. While having /bin point to /usr means when /usr doesn't load or fsck -- you can't come up in single user -- it also breaks booting from the hard disk -- neither of which is very reliable. Is there a reason why they can't live on /bin and have the links on /usr? -- 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
* Carlos E. R. <robin.listas@telefonica.net> [11-13-12 19:52]:
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.
And this is *still* factory discussion list, not 12.2 which has been released. Discussion belongs on opensuse list. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- 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
Felix Miata wrote:
On 2012-11-13 19:54 (GMT-0500) Patrick Shanahan composed: 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.
I remember the discussion in the timeframe of saying it was necessary for systemd -- and out of that discussion, it was said that it wouldn't be necessary to have /usr mounted to boot. This is not the case, as it is. -- The devs stuck in a shim-layer to ensure it was done -- and did it in a way to make sure backwards compatibility was NOT maintained. I ask again -- Why weren't soft-links put on /usr/bin pointing to the parent. Putting softlinks on a child directory, pointing to something on a parent file system is very bad form. If you need it to appear in two places, you put the soft link in the deeper dir or mounted file system pointing back to the parent. The agreement to not make booting root dependent on /usr being mounted. This was not done. I can no longer boot my root. Claiming that I have to a shim layer enable the old boot process to work where I load a file that is over 4X the size of my kernel misses the point of having loadable modules that only load on demand. I.e. ALL modules are loaded, and discards then loaded on demand. This is why I said the initrd boot process was much slower than native boot. To reboot my system using a hot kernel takes less than 30 seconds. Again, wasn't one of the main reasons for going with systemd, 'speed'? But you know, fixing it for 12.2 is unreasonable -- I'm convinced by: **** Patrick Shanahan wrote: ****
And this is *still* factory discussion list, not 12.2 which has been released. Discussion belongs on opensuse list.
This is something that needs to be fixed in 12.3. Thank-you, Patrick for clarify what was needed.I knew discussion on 'opensuse' wasn't the place to discuss a development issue, and 12.2 is "out the door".. not gonna be fixed for it. Trying to be *reasonable* here, and realizing it's an ice-cube's chance in hell of it being fixed in 12.2, I am being practical and agreeing with you -- this needs to be fixed in 12.3, where I can be one of the first to test the rpms ;-) -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-14 02:15, Linda Walsh wrote:
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. Initrd is needed for many things, it just happens that the solution for /usr handling in a separate partition has to be done as well with initrd. If you have another solution... up to you. :-) - -- 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/ iF4EAREIAAYFAlCi+3cACgkQja8UbcUWM1xqKgD/SHBIbaCtwjRlI84RRlPIQPU7 2Uk9K0aG8Zgn5CrDuy4A/jzbLVFSJ99DFHLUGqal0o3B65NJro43vn3oOiOdOZbM =0LDX -----END PGP SIGNATURE----- -- 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
В Tue, 13 Nov 2012 18:57:04 -0800 Linda Walsh <suse@tlinx.org> пишет:
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.
I'm afraid I still miss your point(s). 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. Or you complaint that compatibility links between /usr and /bin,/sbin,/lib,/lib64 are missing? Thank you -andrey -- 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
On Wed, Nov 14, 2012 at 7:31 AM, Carlos E. R. <carlos.e.r@opensuse.org> wrote:
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.
If there is no separate /usr filesystem there is no need for initrd (for this reason at least). So unfortunately we are back at square one. -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-14 02:39, David Haller wrote:
You need initrd- If you do not want to use it, then you will need to hack your own solution.
WHY?
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. 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
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
On 11/14/2012 05:37 PM, Linda Walsh wrote:
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.
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, 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
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
On 11/14/2012 06:09 PM, Linda Walsh wrote:
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.
Linda, you really missed some of the discussion - which is not a problem if you engage in a friendly and constructive kind. When we discussed separate /usr, it was clear that this was only supported via initrd, see for example this blog post: http://lizards.opensuse.org/2011/08/03/mounting-usr-in-the-initrd/
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?
I don't like your accusation style. Btw. I'm not considering that openSUSE needs to support mounting of /usr with initrd. If this is a request for you, then support it yourself. openSUSE comes with an initrd and we assume that it's there... 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
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 10:19 PM, Linda Walsh wrote:
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.
Don't twist my words, I'm responding your initial mails that spoke about lies... 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
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
On Wed, Nov 14, 2012 at 09:09:05AM -0800, Linda Walsh wrote:
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,
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. 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
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 Thu, Nov 15, 2012 at 01:10:29PM -0800, Linda Walsh wrote:
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.
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?
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.
Even xfs used with journaling enabled should not be checked/repaired if mounted even if mounted only ro. From xfs_repair(8): ... Regardless, the filesystem to be repaired must be unmounted, other- wise, the resulting filesystem may be inconsistent or corrupt. ... from xfs_check(8): ... The filesystem should normally be unmounted or read-only during the execution of xfs_check. Oth- erwise, spurious problems are reported. ...
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.
For any professional use it is a inalienable requirement to minimize the risk of data loose.
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)...
Same problem similar but slower solution. IMHO a ramdisk is much faster as to misuse the swap paritition which may already contain the system image saved for Hibernate or Suspend-To-Disk.
It's not worth requiring something that only has to be done once every 12 years.
This is *your* personal opinion and you may consider that paying customers may have other essential requirements.
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.
We're talking about less than 3 seconds used for initrd which could be safed by using the unsafe method you prefer.
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 -- "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
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
On Fri, Nov 16, 2012 at 11:53:56AM +0100, Ruediger Meier wrote:
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.
/suse/werner> mount | grep /boot /dev/sdb1 on /boot type ext2 (rw,acl,user_xattr)
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 ...
What does mean broken initrd? The only case I'm remembering is compiling and installing a kernel and then forgot to run mkinitrd. But I'm also remembering on some power outages which had lead to a fsck/repair of the root file system. 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
-----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
Dr. Werner Fink 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?
Luck has nothing to do with it. It was my cross-circuiting to B...er, Ask the xfs people about reliability stats. Real corporations have a very low failure rate with XFS -- as they run with UPS's and stable kernels. Unexpected crashes and and power interruptions are things that XFS doesn't deal well with, but if one has a stable kernel and power supply, there is no luck involved. If you don't have those, then I'll grant it isn't as reliable, and prebooting from an initrd might be a better choice -- if the init rd has utils to recover from problems (unlike OpenSuse's)...
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.
Even xfs used with journaling enabled should not be checked/repaired if mounted even if mounted only ro. From xfs_repair(8) --
---- This is perfect. Those utils are not only not used or called during boot -- but they aren't even on the initrd. They never have been because there is no need for them. What you do have is a shell script: ****IS**** the point. Those are NOT fsck.xfs. Those are *exceptional measures*. Suse doesn't call xfs_repair or xfs_check on each boot, because XFS doesn't need it and it isn't recommended. Suse calls a lame fsck that's a *SHELL* script that checks to see if the device is mounted. You can't quote manpage info for something other than xfs.fsck -- and for that there is no requirement it be mounted R/O, -- just that it be mounted AT ALL, since that is the only test in the script: /tmp/initrd/usr/sbin# more fsck.xfs #!/bin/sh -f # Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved. ... while getopts ":aApy" c ... if [ ! -e $DEV ]; then echo "$0: $DEV does not exist" exit 8 fi ... exit 0 ------------- There is nothing the above does for anyone if it is run from root and checking root. Even if it is run from initrd, it doesn't do anything useful. The system won't boot, and you won't be able to repair it because the initrd doesn't contain a rescue disk -- that's a separate item.
To require to spend extra time and space for something that happens once in a Jovian year, is not logical. For any professional use it is a inalienable requirement to minimize the risk of data loose.
Right... so UPS/ stable kernel and XFS... But OSuse's initrd doesn't have any tools to check an xfs root file system -- because it isn't needed. That's the official view of 20-years of industry experience with XFS -- NOT my experience.. Your entire point is moot, as SuSE's initrd has no tools to repair the file system. That's when you bring out a rescue DVD or USB-key -- initrd has nothing for that. But to require stupid pointless actions from people people who know enough to run reliable file systems that don't need fsck on boot, is dumbing down the distro for the lowest common denominator -- when OSuse should be educating those users. Most users wouldn't need fsck if they new the reliability of xfs and it was the default root fs.
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)...
Same problem similar but slower solution. IMHO a ramdisk is much faster as to misuse the swap paritition which may already contain the system image saved for Hibernate or Suspend-To-Disk.
Um... that was a solution they used 15-25 years ago with IRIX. I don't have an IRIX system -- no doubt it would be different today, but they used that 15 years ago, when multi-gig ramdisks were not possible. Today, I boot from a DVD. Which uses a ram disk to repair something that leaves the root file system inaccessible or destroys utils like 'mount' that live in /bin (at least on initrd...)..
It's not worth requiring something that only has to be done once every 12 years.
This is *your* personal opinion and you may consider that paying customers may have other essential requirements.
No it is not a personal opinion. It is an engineering opinion based on facts. The information you quoted to support your argument had nothing to do with "fsck".. XFS has no FSCK to run from initrd other than a shell script that tests if the disk is Mounted. For the root file system, that's a ridiculous thing to check for.
We're talking about less than 3 seconds used for initrd which could be safed by using the unsafe method you prefer.
Let's look at that safety and whether or not binaries must live in /usr/bin and /usr/sbin in order to boot... Looking at OSs's initrd, there is *nothing* in /usr/bin. In /bin, the initrd has: /tmp/initrd# ls bin awk@ chmod* date* ipconfig* ln* mkdir* mv* sed* sleep* uname* bash* chroot* dmesg* ipconfig.sh* logger@ mknod* rm* sh@ true* usleep* cat* cp* grep@ linuxrc* ls* mount* run-init* showconsole* umount* warpclock* --- In /usr/sbin: /tmp/initrd/usr/sbin# ll total 44 -rwxr-xr-x 1 38776 Jul 16 03:02 fsck* -rwxr-xr-x 1 450 Jul 16 03:44 fsck.xfs* /tmp/initrd/usr/sbin# more fsck fsck* fsck.xfs* -------------- (notice there is no call to anything that requires a file system be unmounted). ---and in /sbin Ishtar:tmp/initrd/sbin# ls biosdevname* blogd* fsck.xfs@ ifup* killall5* pidof@ resume* udevadm* blkid@ fsck@ halt* insmod* modprobe* reboot@ showconsole* udevd* ---- so Your initrd, DOESN'T have binaries in /usr -- but it boots just fine. If anything it is the libs in /usr/lib64: Ishtar:tmp/initrd# du lib64 7164 lib64 Ishtar:tmp/initrd# du usr/lib64 12620 usr/lib64 But compared to anything, moving that 12M from usr/lib64 to lib64... -- OSs's entire initrd could be on the hard disk and it would boot fine -- OSs' initrd doesn't need binaries in /usr and only uses a small number of libs in lib64 that could just as easily live in /lib64. So if the initrd OS's is using doesn't need any binary in /usr, why require it of customers? The major case one would need to boot from an initrd would be if they used a sub-optimal file system for root. That is a choice, but given a choice between something that will "just work", and something that needs checking -- for reliability, what would you choose? OSs' initrd is useless for checking a rootfs if the rootfs doesn't have an fsck! as is the case w/xfs). OSs' doesn't include any advanced disk check/repaire utils on the initrd -- so there can be no way to use the initrd to repair a root file system if it was corrupt. -- 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
Stefan Seyfried wrote:
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...)
Ahh.. resorting to childish name calling now. Despite that, I'll agree. I misread some figures: # lh /boot/initrd* -rw-rw-r-- 1 13M Nov 14 09:05 /boot/initrd-3.2.0-Isht-Van -rw-rw-r-- 1 13M Nov 14 09:05 /boot/initrd-3.2.21-Ish-Van -rw-rw-r-- 1 13M Nov 14 09:06 /boot/initrd-3.2.21-Isht-Van -- 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 <suse@tlinx.org> 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
Rajko wrote:
On Fri, 16 Nov 2012 19:23:54 -0800 Linda Walsh <suse@tlinx.org> 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. -- Per Jessen, Zürich (5.5°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- 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 <suse@tlinx.org> 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 Sat, 17 Nov 2012 23:35:37 -0800 Linda Walsh <suse@tlinx.org> 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. If a developer base structure and size would be different, then all could be handled with lesser annoyances and I'm sure no one would be happier then SUSE.
... to the downward slide of quality and stability...
In general larger developer base will help openSUSE not to depend on upstream whims, allow more user friendly patches to live if necessary forever, making openSUSE implementation better. Being better is good anywhere. -- Regards, Rajko. -- 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 <suse@tlinx.org> 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 2012-11-18 21:57, Hans Witvliet wrote:
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: 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...
The competition, in case you mean RedHat by that, is likely going to use systemd as well. -- 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 <suse@tlinx.org> 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
Le dimanche 18 novembre 2012, à 12:44 -0600, Rajko a écrit :
On Sat, 17 Nov 2012 23:35:37 -0800 Linda Walsh <suse@tlinx.org> 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.
I wouldn't call openSUSE a playground, though. Some SUSE employees are contributing to openSUSE with the goal of having some feature land in SUSE enterprise products, but they have to do it following our (openSUSE's) quality standards. We don't have to accept crappy stuff. Now, the definition of "crappy" might be different for people in the community, though ;-) (Just for the record: a good part of SUSE employees contributing to openSUSE do so simply because they use it)
If a developer base structure and size would be different, then all could be handled with lesser annoyances and I'm sure no one would be happier then SUSE.
Indeed :-) Vincent -- Les gens heureux ne sont pas pressés. -- 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
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. -- "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
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
On 2012-11-14 12:13 (GMT-0500) Linda Walsh composed:
coudn't mount anything because someone moved mount to the non-root disk -- and it couldn't mount anything.
You roll your own kernel to avoid need for initrd. Why not roll your real mount binary into /bin? -- "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
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
On 2012-11-14 20:58 (GMT+100) David Haller composed:
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.
I highly doubt it. That's been planned for release-next, whatever it gets called. 12.2 has been released, so it can't be leaving 12.2.
Oh, and I'm counting on you help maintaining sysvinit.
Then you could be in for trouble. I'm not a software maintainer, and most likely won't ever be. The farther I go, the behinder I get. -- "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
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
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. Not _1_ is from kde/gnome or freedesktop -- these are all base-level utils. ALL of the ones you mention start after the system comes up -- and well after /usr is mounted -- NONE of them would have any requirements to be loaded BEFORE the disks are mounted... Please explain your statement, as the list of files and rpms below doesn't support it. What in the desktop rpms require themselves to be brought up BEFORE disks are mounted? That's the key. You are saying a graphical desktop should boot BEFORE any disks but root are mounted. Not only is that not currently the case, but WHY would they need such? AND PLEASE NOTE -- I come up in runstate 3 -- I don't use a local desktop -- I use a remote desktop -- so none of that applies anyway. My linux machine won't take a real graphics card -- EVEN MS is telling their developers NOT to develop WIN8 apps needing a Graphical UI -- because the trend in the industry is moving toward headless and virtual's that don't have a GUI running locally. Is your intention to make openSUSE a desktop only OS? 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: /bin/arch /bin/basename /bin/cat /bin/chgrp /bin/chmod /bin/chown /bin/cp /bin/cpio /bin/date /bin/dd /bin/df /bin/dmesg /bin/echo /bin/ed /bin/egrep /bin/eject /bin/false /bin/fgrep /bin/fillup /bin/findmnt /bin/gawk /bin/grep /bin/initviocons /bin/ip /bin/kill /bin/ln /bin/logger /bin/ls /bin/lsblk /bin/mail /bin/md5sum /bin/mkdir /bin/mknod /bin/mktemp /bin/more /bin/mount /bin/mv /bin/ping /bin/ping6 /bin/pwd /bin/readlink /bin/rm /bin/rmdir /sbin/adjtimex /sbin/agetty /sbin/arping /sbin/blkid /sbin/blockdev /sbin/brctl /sbin/btrfs /sbin/btrfs-convert /sbin/btrfs-dump-super /sbin/btrfs-find-root /sbin/btrfs-image /sbin/btrfs-restore /sbin/btrfs-select-super /sbin/btrfs-zero-log /sbin/btrfsck /sbin/btrfstune /sbin/cfdisk /sbin/chcpu /sbin/clockdiff /sbin/crda /sbin/ctrlaltdel /sbin/dhcpcd /sbin/dosfsck /sbin/dosfslabel /sbin/ethtool /sbin/fbset /sbin/fdisk /sbin/findfs /sbin/fsck /sbin/fsck.btrfs /sbin/fsck.cramfs /sbin/fsck.minix /sbin/fsck.msdos /sbin/fsfreeze /sbin/fstrim /sbin/hdparm /sbin/hwclock /sbin/ifenslave /sbin/ifplugd /sbin/ifplugstatus /sbin/in.rdisc /sbin/ip /sbin/kdump /sbin/kexec /sbin/losetup /sbin/lscfg /sbin/lsmcode /sbin/lsvio /sbin/lsvpd /sbin/mkdosfs /sbin/mkfs /sbin/mkfs.bfs /sbin/mkfs.btrfs /sbin/mkfs.cramfs /sbin/mkfs.minix /sbin/mkfs.msdos /sbin/mkfs.ntfs /sbin/mkfs.xfs /sbin/mkswap /sbin/mount.lowntfs-3g /sbin/mount.ntfs-3g /sbin/nologin /sbin/pivot_root /sbin/raw /sbin/regdbdump /sbin/sfdisk /sbin/swaplabel /sbin/swapoff /sbin/swapon /sbin/switch_root /sbin/tracepath /sbin/tracepath6 /sbin/wipefs /sbin/xfs_repair /usr/lib64/libblkid.so.1 /usr/lib64/libgcrypt.so.11 /usr/lib64/libgpg-error.so.0 /usr/lib64/libgssapi_krb5.so.2 /usr/lib64/libk5crypto.so.3 /usr/lib64/libkrb5.so.3 /usr/lib64/libkrb5support.so.0 /usr/lib64/liblzo2.so.2 /usr/lib64/libmount.so.1 /usr/lib64/libpcre.so.1 /usr/lib64/libsqlite3.so.0 /usr/lib64/libstdc++.so.6 /usr/lib64/libvpd_cxx.so.2 -- 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
David Haller wrote:
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
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. In the packages I looked at, SuSE had to **ADD** patches to change upstream defaults -- to move them from "/" (bin,sbin) to /usr. One of SuSE's claims on their justification page for doing this was that by doing this, they could remove patches -- so far, I have seen no removals -- only added patches to support this scheme.
Try building / installing any _GUI_ software without using stuff from freedesktop.org and/or Gnome/KDE.
--- I believe you -- but the packages I listed aren't ones provided by freedesktop.org.
What in the desktop rpms require themselves to be brought up BEFORE disks are mounted?
That fancy bootsplash stuff does.
---- I don't use that.
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 ;)
---- I have a split system. I run a Windows machine as my desktop and it uses the linux machine for everything else. Gkrellm is pretty nifty, though I don't like the fact that it can't resize a tad larger, so I use xosview. Also -- it's not just /usr that is being used on boot -- but /usr/share. That's ANOTHER partition. 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. -- 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
On Wednesday 2012-11-14 17:37, Linda Walsh wrote:
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.
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! It is also free in the sense that you can do literally anything with it! (No GPL!) Your move will also help thousands of BSD users by making GNOME revise its distribution of developer manpower! Switch now, or be doomed in a monoculture forever! Terms and conditions apply. systemd and pulseaudio are either recognized projects or projects of Lennart Poettering in Fedora and/or other distributions. GNOME is a registered trademark of The GNOME Foundation. All other names are the brainchild of their respective creators. All rights are served. -- 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
On Sunday 2012-11-18 05:43, Linda Walsh wrote:
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!
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 have not seen a whole lot of work done on non-initrd support yet.
Those in charge would like us to believe they are omnipotent and their decisions are final
All decisions are final until a better one comes along. Even the legal systems of real-world countries offer possibilities to re-open cases, same in the distro business.
In fact, if they were secure [sic], they'd want us to stay to build user-base numbers.
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.
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. -- 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
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2012-11-14 02:39, David Haller wrote:
You need initrd- If you do not want to use it, then you will need to hack your own solution. WHY?
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.
And I'm not saying I like it.
Are you saying if I submit a patch moving them back, then because I would be a dev, it would be accepted, and it would then be fixed? I.e. No one has explained why the base binaries (bin/cp, for example), cannot reside in "/bin", and, if needed /usr/bin has a symlink /bin. This would have been a much easier solution to implement than moving all of the files in the first place. I would like to know why that won't work? I listed the files affected...in what packages 26 packages -- ALL low-level console packages in bin+/sbin and 10 in /usr/lib64 that were referenced by those binaries. That would be fairly trivial to move back. Looking at some of the packages (coreutils/util-linux) -- it would be a matter of deleting patches suse put in to go AGAINST upstream defaults (contrary to what someone said earlier on this list). Also, the patch for making mount use liblkid is dated on Jun 2012 -- not a year ago. The one in core utils was dated in Feb2012.. about 6-7 months ago. I am seeing the engineering quality and decisions decline in this distro -- like the senior people have left and decisions are being made by those without alot of industry experience (<20 years)... Just a feel, but if Suse keeps going this route, it will be near dead in about 3-5 years. I note it's declined from the #2 to the #5 spot over the past few years, and down to #6 in the past 30 days since 12.2 was released -- usually a time when usage pops up due to a new version being tried out. I even see the comment for core utils - to move them all to /usr/bin reason give: some UsrMerge project. That points various places via google... None of which answer the base quetion.. If you want to merge /usr/bin and /bin, Why did you go for the incompatible route of using a different subpath? Why wasn't /usr/bin,lib/...} -> merged to /bin /lib, /usr... ? If / and /usr are separate file systems, then putting things in / and having links in /usr won't hurt boot, but doing the opposite does. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (18)
-
Andreas Jaeger -
Andrey Borzenkov -
Brian K. White -
Carlos E. R. -
Carlos E. R. -
David Haller -
Dr. Werner Fink -
Felix Miata -
Greg Freemyer -
Hans Witvliet -
Jan Engelhardt -
Linda Walsh -
Patrick Shanahan -
Per Jessen -
Rajko -
Ruediger Meier -
Stefan Seyfried -
Vincent Untz