[opensuse] Re: Why is initrd needed - to support moving bin files from root->/usr? That requires extra patches by Suse.
Greg KH wrote:
On Thu, Nov 15, 2012 at 12:17:47AM -0800, Linda Walsh wrote:
So far no one is able to explain why it is needed other than It's a fad or it's cool..
Because the openSUSE kernel is not monolithic, it contains modules that need to be loaded before mounting the root disk. It also needs to do other things (decryption, disk checks, etc.)
Yes, if you build your own kernels, and don't put /usr/ on a different partition, you can get away without a initrd, I do it all the time.
Why must /usr be on the same partition again? I made a list of files & packages moved from / to /usr: The rpms containing the cross-linked dependcy changes. Not one of these is desktop related that I can tell -- they are all low-level utils. bridge-utils-1.5-10.1.2.x86_64 btrfsprogs-0.19-43.10.1.x86_64 btrfsprogs-0.19-47.1.2.x86_64 coreutils-8.17-2.1.x86_64 cpio-2.11-18.1.2.x86_64 crda-1.1.1-15.1.2.x86_64 dhcpcd-3.2.3-47.73.1.2.x86_64 dosfstools-3.0.10-22.1.2.x86_64 ed-1.6-2.1.2.x86_64 eject-2.1.0-162.1.2.x86_64 ethtool-3.2-3.1.2.x86_64 fbset-2.1-936.1.2.x86_64 fillup-1.42-265.1.2.x86_64 gawk-4.0.1-2.1.4.x86_64 grep-2.13-1.1.2.x86_64 hdparm-9.39-3.1.2.x86_64 ifplugd-0.28-228.1.2.x86_64 initviocons-0.5-96.1.2.x86_64 iproute2-3.4.0-2.1.2.x86_64 iputils-s20101006-16.1.2.x86_64 kexec-tools-2.0.2-14.2.4.x86_64 lsvpd-1.6.5-47.1.3.x86_64 mailx-12.5-2.1.3.x86_64 ntfs-3g-2011.4.12-3.1.2.x86_64 ntfsprogs-2011.4.12-3.1.2.x86_64 util-linux-2.21.2-4.2.3.x86_64 xfsprogs-3.1.6-9.1.2.x86_64 And the rpms with libs they reference that were moved to /usr: krb5-1.9.1-24.9.1.x86_64 libblkid1-2.21.2-4.2.3.x86_64 libgcrypt11-1.5.0-9.2.2.x86_64 libgpg-error0-1.10-7.1.3.x86_64 liblzo2-2-2.06-6.1.2.x86_64 libmount1-2.21.2-4.2.3.x86_64 libpcre1-8.31-1.3.x86_64 libsqlite3-0-3.7.12.1-2.1.2.x86_64 libstdc++46-4.6.2_20111026-1.1.4.x86_64 libvpd2-2.0.3-15.1.2.x86_64 ---- List of files: in /bin/ arch basename cat chgrp chmod chown cp cpio date dd df dmesg echo ed egrep eject false fgrep fillup findmnt gawk grep initviocons ip kill ln logger ls lsblk mail md5sum mkdir mknod mktemp more mount mv ping ping6 pwd readlink rm rmdir in /sbin/: adjtimex agetty arping blkid blockdev brctl btrfs btrfs-convert btrfs-dump-super btrfs-find-root btrfs-image btrfs-restore btrfs-select-super btrfs-zero-log btrfsck btrfstune cfdisk chcpu clockdiff crda ctrlaltdel dhcpcd dosfsck dosfslabel ethtool fbset fdisk findfs fsck fsck.btrfs fsck.cramfs fsck.minix fsck.msdos fsfreeze fstrim hdparm hwclock ifenslave ifplugd ifplugstatus in.rdisc ip kdump kexec losetup lscfg lsmcode lsvio lsvpd mkdosfs mkfs mkfs.bfs mkfs.btrfs mkfs.cramfs mkfs.minix mkfs.msdos mkfs.ntfs mkfs.xfs mkswap mount.lowntfs-3g mount.ntfs-3g nologin pivot_root raw regdbdump sfdisk swaplabel swapoff swapon switch_root tracepath tracepath6 wipefs ***xfs_repair*** and in /lib64: libblkid.so.1 libgcrypt.so.11 libgpg-error.so.0 libgssapi_krb5.so.2 libk5crypto.so.3 libkrb5.so.3 libkrb5support.so.0 liblzo2.so.2 libmount.so.1 libpcre.so.1 libsqlite3.so.0 libstdc++.so.6 libvpd_cxx.so.2 ----------------- Now a big issue made by Dr. Werner Fink was the ability to be able to run xfs_repair. Note it was moved from /sbin to /usr/sbin. This means if /usr doesn't mount because it needs xfs_repair, then it is inaccessible. It isn't on the initrd either, so root can't be checked. Reality is that it is almost never needed and booting from a rescue disk is the wisest solution. But claiming that initrd was needed to check the file system when the check util has been moved to a later-mounted file sytem?? That blows that out of the water. Claiming that initrd is needed to load modules? Needed?? Maybe during install -- but there is no reason why a dynamically built kernel with the modules needed for boot couldn't be linked after install -- just like DKMS modules are built for a specific system's environment, the kernel could be rebuilt or re-linked as well. Again -- no need for initrd.
But for the distro, as shipped, it's not going to happen, sorry.
--- That much is clear. 12.2 is out the door. That's why Patrick Shanahan said this had to be a 12.3 issue to even be discussed on the factory list.
In fact, I don't know of _any_ distro that does not provide an initrd, this isn't a new thing at all, sorry.
*providing* an initrd is not new. Requiring it is. It's not even in a format that can be mounted directly. You have to have a booted kernel running before you can extract it -- as it's a cpio image, not a disk image.
If you want to have a separate /usr partition, then you are free to support it without an initrd as well as you can, but note, that's not what openSUSE is going to do.
---- you haven't said 'why' -- other than you want to shove this down user's throats and screw people over. Is that your power trip? I've asked several times why those binaries couldn't have **remained** in root (or why the patches that move them can't be removed)... and have softlinks in /usr. I'm able to recover from a completely broken boot by mounting /usr by its device name -- there's no reason why that mount of /usr couldn't be done in the 'boot' scripts (before the "rc" scripts and before systemd is called.
If you don't like this, ... you are free to change [it] to something else
---- That's why I am pushing to have this fixed in 12.3.
Best of luck, greg k-h
Thanks, I knew I could rely on your support. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/17/2012 3:06 PM, Linda Walsh wrote:
Greg KH wrote:
On Thu, Nov 15, 2012 at 12:17:47AM -0800, Linda Walsh wrote:
So far no one is able to explain why it is needed other than It's a fad or it's cool..
Because the openSUSE kernel is not monolithic, it contains modules that need to be loaded before mounting the root disk. It also needs to do other things (decryption, disk checks, etc.)
Yes, if you build your own kernels, and don't put /usr/ on a different partition, you can get away without a initrd, I do it all the time.
Why must /usr be on the same partition again?
I made a list of files & packages moved from / to /usr:
The rpms containing the cross-linked dependcy changes. Not one of these is desktop related that I can tell -- they are all low-level utils.
bridge-utils-1.5-10.1.2.x86_64 btrfsprogs-0.19-43.10.1.x86_64 btrfsprogs-0.19-47.1.2.x86_64 coreutils-8.17-2.1.x86_64 cpio-2.11-18.1.2.x86_64 crda-1.1.1-15.1.2.x86_64 dhcpcd-3.2.3-47.73.1.2.x86_64 dosfstools-3.0.10-22.1.2.x86_64 ed-1.6-2.1.2.x86_64 eject-2.1.0-162.1.2.x86_64 ethtool-3.2-3.1.2.x86_64 fbset-2.1-936.1.2.x86_64 fillup-1.42-265.1.2.x86_64 gawk-4.0.1-2.1.4.x86_64 grep-2.13-1.1.2.x86_64 hdparm-9.39-3.1.2.x86_64 ifplugd-0.28-228.1.2.x86_64 initviocons-0.5-96.1.2.x86_64 iproute2-3.4.0-2.1.2.x86_64 iputils-s20101006-16.1.2.x86_64 kexec-tools-2.0.2-14.2.4.x86_64 lsvpd-1.6.5-47.1.3.x86_64 mailx-12.5-2.1.3.x86_64 ntfs-3g-2011.4.12-3.1.2.x86_64 ntfsprogs-2011.4.12-3.1.2.x86_64 util-linux-2.21.2-4.2.3.x86_64 xfsprogs-3.1.6-9.1.2.x86_64
And the rpms with libs they reference that were moved to /usr:
krb5-1.9.1-24.9.1.x86_64 libblkid1-2.21.2-4.2.3.x86_64 libgcrypt11-1.5.0-9.2.2.x86_64 libgpg-error0-1.10-7.1.3.x86_64 liblzo2-2-2.06-6.1.2.x86_64 libmount1-2.21.2-4.2.3.x86_64 libpcre1-8.31-1.3.x86_64 libsqlite3-0-3.7.12.1-2.1.2.x86_64 libstdc++46-4.6.2_20111026-1.1.4.x86_64 libvpd2-2.0.3-15.1.2.x86_64
----
List of files: in /bin/
arch basename cat chgrp chmod chown cp cpio date dd df dmesg echo ed egrep eject false fgrep fillup findmnt gawk grep initviocons ip kill ln logger ls lsblk mail md5sum mkdir mknod mktemp more mount mv ping ping6 pwd readlink rm rmdir
in /sbin/: adjtimex agetty arping blkid blockdev brctl btrfs btrfs-convert btrfs-dump-super btrfs-find-root btrfs-image btrfs-restore btrfs-select-super btrfs-zero-log btrfsck btrfstune cfdisk chcpu clockdiff crda ctrlaltdel dhcpcd dosfsck dosfslabel ethtool fbset fdisk findfs fsck fsck.btrfs fsck.cramfs fsck.minix fsck.msdos fsfreeze fstrim hdparm hwclock ifenslave ifplugd ifplugstatus in.rdisc ip kdump kexec losetup lscfg lsmcode lsvio lsvpd mkdosfs mkfs mkfs.bfs mkfs.btrfs mkfs.cramfs mkfs.minix mkfs.msdos mkfs.ntfs mkfs.xfs mkswap mount.lowntfs-3g mount.ntfs-3g nologin pivot_root raw regdbdump sfdisk swaplabel swapoff swapon switch_root tracepath tracepath6 wipefs ***xfs_repair***
and in /lib64: libblkid.so.1 libgcrypt.so.11 libgpg-error.so.0 libgssapi_krb5.so.2 libk5crypto.so.3 libkrb5.so.3 libkrb5support.so.0 liblzo2.so.2 libmount.so.1 libpcre.so.1 libsqlite3.so.0 libstdc++.so.6 libvpd_cxx.so.2
-----------------
Now a big issue made by Dr. Werner Fink was the ability to be able to run xfs_repair. Note it was moved from /sbin to /usr/sbin. This means if /usr doesn't mount because it needs xfs_repair, then it is inaccessible. It isn't on the initrd either, so root can't be checked. Reality is that it is almost never needed and booting from a rescue disk is the wisest solution. But claiming that initrd was needed to check the file system when the check util has been moved to a later-mounted file sytem?? That blows that out of the water.
Claiming that initrd is needed to load modules? Needed?? Maybe during install -- but there is no reason why a dynamically built kernel with the modules needed for boot couldn't be linked after install -- just like DKMS modules are built for a specific system's environment, the kernel could be rebuilt or re-linked as well. Again -- no need for initrd.
Custom built kernels are probably a support nightmare. I don't fault them for using initrd, but I do think it sucks that they deliberately make it essentially required when it doesn't have to be. Using an initrd is a downgrade in some cases. _Requiring_ it is an even bigger downgrade in general, as it's a loss in flexibility and in some cases a loss in efficiency. I don't think xfs is a reasonable default fs for a linux distro like opensuse either. There are special linux distros that target security and reliability above all else, including at the expense of performance. I don't think suse was ever one of those. It was a general purpose OS that now targets desktops. xfs is not the best fs for desktops nor even for all servers. But opensuse isn't all linux itself, it's just opensuse. Every distribution takes pieces from the world of available code and packages them up in different ways that serve different needs. The targets opensuse serves has shifted from those suse used to serve very well that's all. It's not a crime it just sucks for us. I don't like that opensuse has veered off from the kind of distro it used to be, because I was well served by what it used to be and I am not well served by what it is now, and it means I now have to do a bunch of work. But some of these things you're arguing are not really just. They should be allowed for but I don't think they are reasonable to expect as defaults. -- bkw
But for the distro, as shipped, it's not going to happen, sorry.
That much is clear. 12.2 is out the door. That's why Patrick Shanahan said this had to be a 12.3 issue to even be discussed on the factory list.
In fact, I don't know of _any_ distro that does not provide an initrd, this isn't a new thing at all, sorry.
*providing* an initrd is not new. Requiring it is. It's not even in a format that can be mounted directly. You have to have a booted kernel running before you can extract it -- as it's a cpio image, not a disk image.
If you want to have a separate /usr partition, then you are free to support it without an initrd as well as you can, but note, that's not what openSUSE is going to do.
---- you haven't said 'why' -- other than you want to shove this down user's throats and screw people over. Is that your power trip?
I've asked several times why those binaries couldn't have **remained** in root (or why the patches that move them can't be removed)... and have softlinks in /usr.
I'm able to recover from a completely broken boot by mounting /usr by its device name -- there's no reason why that mount of /usr couldn't be done in the 'boot' scripts (before the "rc" scripts and before systemd is called.
If you don't like this, ... you are free to change [it] to something else
---- That's why I am pushing to have this fixed in 12.3.
Best of luck, greg k-h
Thanks, I knew I could rely on your support.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Brian K. White -
Linda Walsh