[opensuse-kernel] variable boot device
Once upon a time, OS installed to sole HD as sda would stay sda even when PCI eSATA was both added and powered on at boot time. Not any more: host gx27b (PCI SiI3512=esata) 11.4 2.6.37 esata=sdb, / on ICH5 sda9 12.1 3.1.10 esata=sdb, / on ICH5 sda10 12.2 3.4.63 esata=sdb, / on ICH5 sda11 12.3 3.7.10 esata=sdb, / on ICH5 sda12 13.1 3.11.6 esata=sdb, / on ICH5 sda20 13.1 3.12.5 esata=sdb, / on ICH5 sda20 13.2 3.12.1 esata=NA, / on ICH5 sda21 13.2 3.12.1 esata=sda, (/ on ICH5 sdb21 non-existent; dracut emergency shell) host gx620 (PCI SiI3512=esata) 11.4 2.6.37 esata=sdb, / on ICH7 sda8 11.4 3.6.2 esata=sdb, / on ICH7 sda8 12.1 3.1.10 esata=sdb, / on ICH7 sda10 13.1 3.11.6 esata=sda, / on ICH7 sdb9 host gx745 (PCI SiI3114=esata) 11.4 2.6.37 esata=sdb, / on ICH8 sda8 11.4 3.6.2 esata=sdb, / on ICH8 sda8 12.1 3.1.10 esata=sdb, / on ICH8 sda10 13.1 3.11.6 esata=sda, / on ICH8 sdb9 Is there some kernel config option or cmdline option or anything else in latest distro releases that can ensure an internal (aka non-removable) HD attached to a motherboard SATA port gets its device name assigned prior to any (removable) USB device and prior to any (removable) (e)SATA device attached to a PCI slot device port, like it used to do automatically? It's really annoying for device names to vary according to which master boot menu selection one makes, or especially, whether an external device is powered up at boot time, and even more specially, when having an external device powered at boot time causes emergency shell instead of boot success. In the case of emergency shell example listed above on gx27b 13.2, both root= on cmdline and / mounting in fstab are using LABEL syntax, meaning, device names should be irrelevant in any event, as they apparently are for 13.1 on the other two hosts. -- "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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2014-01-12 15:14, Felix Miata wrote:
It's really annoying for device names to vary according to which master boot menu selection one makes, or especially, whether an external device is powered up at boot time, and even more specially, when having an external device powered at boot time causes emergency shell instead of boot success. In the case of emergency shell example listed above on gx27b 13.2, both root= on cmdline and / mounting in fstab are using LABEL syntax, meaning, device names should be irrelevant in any event, as they apparently are for 13.1 on the other two hosts.
That's why you must not use those device names, and instead use the alternative names in /dev/disk-by/. They were added precisely because device names such as sda are not persistent. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
On 2014-01-12 16:19 (GMT+0100) Carlos E. R. composed:
Felix Miata wrote:
It's really annoying for device names to vary according to which master boot menu selection one makes, or especially, whether an external device is powered up at boot time, and even more specially, when having an external device powered at boot time causes emergency shell instead of boot success. In the case of emergency shell example listed above on gx27b 13.2, both root= on cmdline and / mounting in fstab are using LABEL syntax, meaning, device names should be irrelevant in any event, as they apparently are for 13.1 on the other two hosts.
That's why you must not use those device names, and instead use the
Must is a strong word. They still exist, therefore they surely still have some value besides being easier to remember and type, and besides making discussion in manuals, books and help forums easy enough to follow.
alternative names in /dev/disk-by/. They were added precisely because device names such as sda are not persistent.
Those long-winded, PITA, alternative names have been around for years. For boot stanza and fstab they can be easily avoided via the ancient LABEL= syntax, though Dracut it seems may have introduced breakage for these two contexts by sticking things in the initrd that don't need to be there. My take on alternative device names creation years ago as features is that the primary reason for their existence is founded in removable storage devices. This is new misbehavior started here only in recent kernels and months. Based entirely on observations I reported in my OP, apparently prior kernels as far back as 11.4's were smart enough to allocate resources first to components built into the mainboard's disk controller(s) before allocating any to attachments like PCI cards or external widgets like USB sticks, but this feature has now been abandoned, or broken. -- "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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-01-12 19:18, Felix Miata wrote:
On 2014-01-12 16:19 (GMT+0100) Carlos E. R. composed:
alternative names in /dev/disk-by/. They were added precisely because device names such as sda are not persistent.
Those long-winded, PITA, alternative names have been around for years. For boot stanza and fstab they can be easily avoided via the ancient LABEL= syntax, though Dracut it seems may have introduced breakage for these two contexts by sticking things in the initrd that don't need to be there.
LABEL is just one of the available methods in /dev/disk-by/. Yes, I agree that using "LABEL=SomeName" is easier than using the alternative "/dev/disk-by/label/SomeName". My entire partition table uses the "LABEL=..." syntax. You can also use "UUID=..." syntax, but not "ID=...", and I do not understand why. You do not have to convince me of that. What I don't do is use that syntax in grub, because I don't know what/where it is supported. Now, what I think you are saying is that the "LABEL=..." syntax was valid in grub, and now it doesn't work - is that it? - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLS4vMACgkQtTMYHG2NR9WnxgCfR99VDDx6bdl7toYxIni0i37A MdwAoIaUEz9LUy5Pi0EkXFWChQr5FsbV =DRgx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Sun, 12 Jan 2014 19:46:11 +0100 "Carlos E. R." <carlos.e.r@opensuse.org> пишет:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-01-12 19:18, Felix Miata wrote:
On 2014-01-12 16:19 (GMT+0100) Carlos E. R. composed:
alternative names in /dev/disk-by/. They were added precisely because device names such as sda are not persistent.
Those long-winded, PITA, alternative names have been around for years. For boot stanza and fstab they can be easily avoided via the ancient LABEL= syntax, though Dracut it seems may have introduced breakage for these two contexts by sticking things in the initrd that don't need to be there.
LABEL is just one of the available methods in /dev/disk-by/.
Yes, I agree that using "LABEL=SomeName" is easier than using the alternative "/dev/disk-by/label/SomeName". My entire partition table uses the "LABEL=..." syntax. You can also use "UUID=..." syntax, but not "ID=...", and I do not understand why.
LABEL is limited to mounting file systems only. /dev/disk/... is generic and can be used in every place where block device can be used. Think e.g. of LVM device scanning.
You do not have to convince me of that.
What I don't do is use that syntax in grub, because I don't know what/where it is supported.
Of course it is not supported by grub itself. If you mean - is it supported as part of kernel parameter (e.g. root=LABEL=xxx) - it is not supported by kernel itself; you will need to have initrd which is able to interpret it.
Now, what I think you are saying is that the "LABEL=..." syntax was valid in grub, and now it doesn't work - is that it?
LABEL= syntax has absolutely nothing to do with grub. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlLS5VoACgkQR6LMutpd94wAXQCdEgW8hwqXHgQzenI/IP8Dmihi DsEAoJDiLaX8CUh26oxKrchsU5++VeWm =CICR -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-01-12 19:56, Andrey Borzenkov wrote:
В Sun, 12 Jan 2014 19:46:11 +0100 "Carlos E. R." <> пишет:
LABEL is just one of the available methods in /dev/disk-by/.
Yes, I agree that using "LABEL=SomeName" is easier than using the alternative "/dev/disk-by/label/SomeName". My entire partition table uses the "LABEL=..." syntax. You can also use "UUID=..." syntax, but not "ID=...", and I do not understand why.
LABEL is limited to mounting file systems only. /dev/disk/... is generic and can be used in every place where block device can be used. Think e.g. of LVM device scanning.
Yes, I know. When in doubt, I just use the long syntax. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLS6oYACgkQtTMYHG2NR9XJ5QCeONKuyIM1POmnC1TlpxvSmJAF Q6IAn3Bkvs7kUMhfmciUzMZJ63JdB3H4 =TJ8B -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2014-01-12 22:56 (GMT+0400) Andrey Borzenkov composed:
LABEL is limited to mounting file systems only.
As opposed to what? I'm having a hard time thinking of any place else I've ever seen it except in fstab, and following root= on a kernel cmdline.
LABEL= syntax has absolutely nothing to do with grub.
Oh? Assuming Grub is the bootloader, how is it not responsible for capturing config info included in its menu config that is needed for init to proceed, and passing it, including whatever follows root=, to whatever it is that needs it? -- "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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2014-01-12 19:46 (GMT+0100) Carlos E. R. composed:
LABEL is just one of the available methods in /dev/disk-by/.
Now, what I think you are saying is that the "LABEL=..." syntax was valid in grub, and now it doesn't work - is that it?
That I was, but it turns out my OP assumed all cmdlines in the sample had used that syntax. The one with the error hadn't, and has since been corrected. What happened there was omitted cleanup after doing some disk maintenance that involved changing some volume labels, facilitated by temporarily setting some cmdlines to device names. IOW, not broken AFAICT. -- "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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
El 12/01/14 11:14, Felix Miata escribió:
Once upon a time, OS installed to sole HD as sda would stay sda even when PCI eSATA was both added and powered on at boot time. Not any more:
Maybe, but nowadays things are slightly more complicated than that.
Is there some kernel config option or cmdline option or anything else in latest distro releases that can ensure an internal (aka non-removable) HD attached to a motherboard SATA port gets its device name assigned prior to any (removable) USB device and prior to any (removable) (e)SATA device attached to a PCI slot device port, like it used to do automatically?
You have to write your fstab referencing filesystems by UUID, remember to rebuild your initrd afterwards. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 12.01.2014 16:27, schrieb Cristian Rodríguez:
You have to write your fstab referencing filesystems by UUID, remember to rebuild your initrd afterwards.
Why is by-label no longer supported? Is this some new dracut-"feature"? I always boot by-label and find it much more convenient than using UUIDs (which might change with each mkfs and are impossible to remember). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
El 12/01/14 13:02, Stefan Seyfried escribió:
Am 12.01.2014 16:27, schrieb Cristian Rodríguez:
You have to write your fstab referencing filesystems by UUID, remember to rebuild your initrd afterwards.
Why is by-label no longer supported?
Did I said it was ? Is this some new dracut-"feature"? dracut supports by-label as well. Also you could currently use GPT and omit the /home and swap from fstab, systemd understand the GUID Partition Table format. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
В Sun, 12 Jan 2014 13:29:47 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> пишет:
dracut supports by-label as well. Also you could currently use GPT and omit the /home and swap from fstab, systemd understand the GUID Partition Table format.
So we are allowed to have just one /home? Even if we install multiple distros or versions of the same distros? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
El 12/01/14 13:36, Andrey Borzenkov escribió:
So we are allowed to have just one /home? Even if we install multiple distros or versions of the same distros?
well, in that case, just keep it in fstab as it takes precedence over everything else. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
В Sun, 12 Jan 2014 13:41:02 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> пишет:
El 12/01/14 13:36, Andrey Borzenkov escribió:
So we are allowed to have just one /home? Even if we install multiple distros or versions of the same distros?
well, in that case, just keep it in fstab as it takes precedence over everything else.
So if for some reasons I would need to comment it out (e.g. to troubleshoot booting process) systemd will helpfully find and mount some random partition without even asking me? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
El 12/01/14 13:54, Andrey Borzenkov escribió:
So if for some reasons I would need to comment it out (e.g. to troubleshoot booting process) systemd will helpfully find and mount some random partition without even asking me?
yep, if that is not wanted, mask the units generated by systemd-gpt-auto-generator or we could add a boot parameter to skip the operation. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 12.01.2014 17:29, schrieb Cristian Rodríguez:
El 12/01/14 13:02, Stefan Seyfried escribió:
Am 12.01.2014 16:27, schrieb Cristian Rodríguez:
You have to write your fstab referencing filesystems by UUID, remember to rebuild your initrd afterwards.
Why is by-label no longer supported?
Did I said it was ?
You implied it, by saying "You have to write your fstab referencing filesystems by UUID" after Felix described he is mounting by-label. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
El 12/01/14 13:56, Stefan Seyfried escribió:
Am 12.01.2014 17:29, schrieb Cristian Rodríguez:
El 12/01/14 13:02, Stefan Seyfried escribió:
Am 12.01.2014 16:27, schrieb Cristian Rodríguez:
You have to write your fstab referencing filesystems by UUID, remember to rebuild your initrd afterwards.
Why is by-label no longer supported?
Did I said it was ?
You implied it, by saying "You have to write your fstab referencing filesystems by UUID" after Felix described he is mounting by-label.
Yeah, I did express myself badly. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-01-12 17:29, Cristian Rodríguez wrote:
dracut supports by-label as well. Also you could currently use GPT and omit the /home and swap from fstab, systemd understand the GUID Partition Table format.
But BIOSES don't. UEFIS do. But millions do not have UEFI. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLS4DgACgkQtTMYHG2NR9W/GACfRplJViO31e83pUYrl/WUVGyV vL4AniKyAC9O0+XMjk4enARzc+Ml1MYW =43xt -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
El 12/01/14 15:34, Carlos E. R. escribió:
UEFIS do. But millions do not have UEFI.
Yeah, but it is unlikely that you will get anything *new* written in this regard to support old systems. It will be dead on arrival. systemd is just a consumer of the UEFI data that is provided by the kernel. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-01-12 19:54, Cristian Rodríguez wrote:
El 12/01/14 15:34, Carlos E. R. escribió:
UEFIS do. But millions do not have UEFI.
Yeah, but it is unlikely that you will get anything *new* written in this regard to support old systems. It will be dead on arrival. systemd is just a consumer of the UEFI data that is provided by the kernel.
So, are you proposing to leave those millions out there in the cold? Maybe you are rich and can replace all your computers. I am not. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLS6iMACgkQtTMYHG2NR9UWaACfTz9vN2dZk7uRauBTAatMSvKm HtYAni5DDuQKe91pXbT0JklAsZPLX9Ki =igbv -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
El 12/01/14 16:16, Carlos E. R. escribió:
So, are you proposing to leave those millions out there in the cold? Maybe you are rich and can replace all your computers. I am not.
Not at all, I am just for using and giving maintenance to the already existing tool/features for older systems that do not support X thing. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-01-12 20:31, Cristian Rodríguez wrote:
El 12/01/14 16:16, Carlos E. R. escribió:
So, are you proposing to leave those millions out there in the cold? Maybe you are rich and can replace all your computers. I am not.
Not at all, I am just for using and giving maintenance to the already existing tool/features for older systems that do not support X thing.
Ok. thanks. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLS9rgACgkQtTMYHG2NR9XzBQCfTLMUcWXiAsyAKTcZzZsNkcvX zAYAn3Dzs3re3KJb4LwgrIax9FLYKy8R =0Lfc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2014-01-12 13:29 (GMT-0300) Cristian Rodríguez composed:
...you could currently use GPT and omit the /home and swap from fstab
How can /home filesystem not need to be in fstab??? What could GPT or dracut have to do with this surprise possibility? -- "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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2014-01-12 17:02 (GMT+0100) Stefan Seyfried composed:
I always boot by-label
Done here since long before libata usurped ide drivers & stuck us with two years of difficult to access partitions above #15.
and find it much more convenient than using UUIDs
+++
(which might change with each mkfs and are impossible to remember).
Only might? Sheldon Cooper would remember. :-p -- "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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2014-01-12 12:27 (GMT-0300) Cristian Rodríguez composed:
Felix Miata composed in English:
Once upon a time, OS installed to sole HD as sda would stay sda even when PCI eSATA was both added and powered on at boot time. Not any more:
Maybe, but nowadays things are slightly more complicated than that.
Meaning since when? Since dracut replaced mkinitrd? Since after 12.3 was released? Since Grub2 became openSUSE default? Since libata became smart enough to find all partitions that ide drivers could find? Since GUID support started appearing in PC BIOS? All my systems were manufactured before any of those events took place, yet only now has this new annoyance surfaced.
Is there some kernel config option or cmdline option or anything else in latest distro releases that can ensure an internal (aka non-removable) HD attached to a motherboard SATA port gets its device name assigned prior to any (removable) USB device and prior to any (removable) (e)SATA device attached to a PCI slot device port, like it used to do automatically?
You have to write your fstab referencing filesystems by UUID,
Wrong. UUIDs are for computers and eidetics, not the other 99.99999% of humans. My fstabs (and boot menus) refer to native filesystems via LABEL= syntax, not by device name, nor any of the newer device aliases among which UUID. UUIDs are fine for losing in binary files, not fine for plain text config files humans ever care to edit or evaluate. When one boots one system to each installed openSUSE release in turn with no change other than boot menu selection, and redirects fdisk -l output to a file, one should reasonably expect diffing any two of those files would produce null output (not counting differences attributable exclusively to the fdisk change in each reported disk's descriptive data head that began in 13.1's fdisk binary - newer added a disk label type line, and added a sector count to the # of bytes line). That isn't happening here when the sata_sil driver is being availed by a storage device.
remember to rebuild your initrd afterwards.
Why? Yet another new misfeature? Once an initrd has been written for a particular installation and kernel and confirmed working as designed and/or desired, it should not need to be rewritten just because some package with a component that an initrd might contain has been updated, especially not 5 times per update run. https://bugzilla.novell.com/show_bug.cgi?id=786318 -- "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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-01-12 21:27, Felix Miata wrote:
remember to rebuild your initrd afterwards.
Why? Yet another new misfeature? Once an initrd has been written for a particular installation and kernel and confirmed working as designed and/or desired, it should not need to be rewritten just because some package with a component that an initrd might contain has been updated, especially not 5 times per update run. https://bugzilla.novell.com/show_bug.cgi?id=786318
It is not that. If you change a label or uid or id reference to a partition that needs to be used while booting, you have to rebuild initrd. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLS/KgACgkQtTMYHG2NR9U2sgCfeenqT3IeM9fg1hDJUDdBnbMt uVkAoId23SB3QO+vC7GYm2eg4y6mJldm =lGF7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2014-01-12 15:35 (GMT-0500) Carlos E. R. composed:
On 2014-01-12 21:27, Felix Miata wrote:
On 2014-01-12 12:27 (GMT-0300) Cristian Rodríguez composed:
remember to rebuild your initrd afterwards.
Why? Yet another new misfeature? Once an initrd has been written for a particular installation and kernel and confirmed working as designed and/or desired, it should not need to be rewritten just because some package with a component that an initrd might contain has been updated, especially not 5 times per update run. https://bugzilla.novell.com/show_bug.cgi?id=786318
It is not that.
What is not what?
If you change a label or uid or id reference to a partition that needs to be used while booting, you have to rebuild initrd.
Keyword: IF!!! Simply update OS and applications is not changing a label or changing a UUID or ID or reference that needs to be used while booting. WRT OP and 13.2, I thought I found a poor, apparent kludge. To /etc/dracut.conf add omit_driver+="sata_sil" then rebuild initrd(s). But, that only works if the sata_sil module is missing from the modules tree when the initrd is built, then restored until such time as another initrd is to be built. Anyone know a better way to keep a module out of a dracut initrd, or an equivalent way to prevent mkinitrd from including sata_sil in initrds for 13.1? -- "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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Felix Miata wrote:
then rebuild initrd(s)[5 times per update run. ]
Anyone know a better way to keep a module out of a dracut initrd, or an equivalent way to prevent mkinitrd from including sata_sil in initrds for 13.1?
Wouldn't it be faster to rebuild your kernel once? If you updated a driver, make would only need to compile that driver and relink once and place results in usable format on the boot disk. People said that would take too long and/or be too complicated. Um... I think the limitations of the workaround of not allowing users to build their own kernel for native boot of their HW are beginning to rise exponentially. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2014-01-12 20:08 (GMT-0800) Linda Walsh composed:
Felix Miata wrote:
Anyone know a better way to keep a module out of a dracut initrd, or an equivalent way to prevent mkinitrd from including sata_sil in initrds for 13.1?
Wouldn't it be faster to rebuild your kernel once?
Maybe if: 1-I ever build any binary of any kind for any reason and have room for devel software and have it installed (I don't, & I don't, & I don't) 2-I didn't have multiple multiboot systems with similar trouble multiplied but different hardware
If you updated a driver, make would only need to compile that driver and relink once and place results in usable format on the boot disk.
Or just flip a switch in the right place so that that an unwanted module won't be loaded without prior permission, top notch reason and/or appropriate timing.
Um... I think the limitations of the workaround of not allowing users to build their own kernel for native boot of their HW are beginning to rise exponentially.
Not just for kernel, but for other things being overhauled and/or supplanted without thorough investigation of ramifications, testing "edge cases" and uncommon hardware in particular. I routinely wonder if the average FOSS programmer works with more than one or maybe two systems, or uses any systems more than 3-6 years old, and is conscious that his small hardware sample is often wholly inadequate as test vehicle. -- "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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2014-01-12 17:02 (GMT-0500) Felix Miata composed:
WRT OP and 13.2, I thought I found a poor, apparent kludge. To
/etc/dracut.conf
add
omit_driver+="sata_sil"
then rebuild initrd(s). But, that only works if the sata_sil module is missing from the modules tree when the initrd is built, then restored until such time as another initrd is to be built.
Anyone know a better way to keep a module out of a dracut initrd, or an equivalent way to prevent mkinitrd from including sata_sil in initrds for 13.1?
I started thread "/etc/sysconfig/kernel vs. /etc/dracut.conf" to address a conflict I found between dracut.conf and /etc/sysconfig/kernel's INITRD_MODULES specifically listing sata_sil for inclusion. -- "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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sun, Jan 12, Felix Miata wrote:
Anyone know a better way to keep a module out of a dracut initrd, or an equivalent way to prevent mkinitrd from including sata_sil in initrds for 13.1?
Use /etc/sysconfig/kernel:INITRD_MODULES="-sata_sil" to disable that driver. Olaf -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 01/12/2014 09:27 PM, Felix Miata wrote:
On 2014-01-12 12:27 (GMT-0300) Cristian Rodríguez composed:
Felix Miata composed in English:
Once upon a time, OS installed to sole HD as sda would stay sda even when PCI eSATA was both added and powered on at boot time. Not any more:
Maybe, but nowadays things are slightly more complicated than that.
Meaning since when?
Since dracut replaced mkinitrd?
Yes. 'mkinitrd' was (is) trying to create a minimal initrd, with only the required drivers present in the initrd. So with that, there was a fair chance that your boot device (not root device!) was being assigned 'sda', by virtue of being the only device initialized at that point. dracut, OTOH, is following the other maxime: build a single initrd which fits all machines, and configure it on the fly. So with that _all_ devices are initialized from the initrd, causing this issue. dracut has a '--host-only' mode, which is supposed to create an mkinitrd-like initrd with only the minimal drivers in place. But this is currently still very rough, and still far too greedy when it comes to including modules. We're working on it to make it work as expected. Then this issue will go away. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Felix Miata wrote:
Once upon a time, OS installed to sole HD as sda would stay sda even when PCI eSATA was both added and powered on at boot time. Not any more:
host gx27b (PCI SiI3512=esata) 13.1 3.12.5 esata=sdb, / on ICH5 sda20 13.2 3.12.1 esata=NA, / on ICH5 sda21 13.2 3.12.1 esata=sda, (/ on ICH5 sdb21 non-existent; dracut emergency shell)
host gx620 (PCI SiI3512=esata) 13.1 3.11.6 esata=sda, / on ICH7 sdb9
host gx745 (PCI SiI3114=esata) 13.1 3.11.6 esata=sda, / on ICH8 sdb9
It's really annoying for device names to vary according to which master boot menu selection one makes, or especially, whether an external device is powered up at boot time, and even more specially, when having an external device powered at boot time causes emergency shell instead of boot success.
In the case of emergency shell example listed above on gx27b 13.2, both root= on cmdline and / mounting in fstab are using LABEL syntax, meaning, device names should be irrelevant in any event, as they apparently are for 13.1 on the other two hosts.
LABEL's are only understood by linux -- so first you have to boot a linux to read the labels -- I found that out the "hard way" when I had to boot to 'S' and there were no labels... Not only no disk labels but the stuff I thought I'd put in the boot disks wasn't available because it was booting off a ram disk. I couldn't figure out a way to put my test code into the early boot sequence to see what was happening (was trying to setup *optional* console redirection to a serial port) -- so I reverted to boot from hard disk and haven't looked back. I've mostly stopped using labels because something has to already be up to populate /dev/disk/by-*/ (i.e. the kernel needs to be booted and udev has to already have been called in the "boot" phase (i.e. /etc/boot.d/(scripts))... Only after the boot phase has done its stuff are "higher level" things like labels available. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2014-01-12 19:57 (GMT-0800) Linda Walsh composed:
LABEL's are only understood by linux -- so first you have to boot a linux to read the labels -- I found that out the "hard way" when I had to boot to 'S' and there were no labels...
This is a Linux mailing list, right? I see Windows, and various utilities and applications show me volume labels. What point are you trying to get across?
Not only no disk labels but the stuff I thought I'd put in the boot disks wasn't available because it was booting off a ram disk. I couldn't figure out a way to put my test code into the early boot sequence to see what was happening (was trying to setup *optional* console redirection to a serial port) -- so I reverted to boot from hard disk and haven't looked back.
Does any of the above paragraph have anything to do with anything previously written in this thread, the OP in particular?
I've mostly stopped using labels because something has to already be up to populate /dev/disk/by-*/ (i.e. the kernel needs to be booted and udev has to already have been called in the "boot" phase (i.e. /etc/boot.d/(scripts))... Only after the boot phase has done its stuff are "higher level" things like labels available.
If you're not using labels, what are you using, and why? -- "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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Felix Miata wrote:
On 2014-01-12 19:57 (GMT-0800) Linda Walsh composed:
LABEL's are only understood by linux -- so first you have to boot a linux to read the labels -- I found that out the "hard way" when I had to boot to 'S' and there were no labels...
This is a Linux mailing list, right? I see Windows, and various utilities and applications show me volume labels. What point are you trying to get across?
Sorry, wasn't clear. The Labels are only understood by something that understands the disk format you are booting from. In order for mount to mount things by label, most of the OS (including the udev daemon has to already be running. Strictly speaking, when you boot by using labels, you aren't *really* _booting_ by labels, since the OS has already been booted off the RAM disk so that it can read the labels. If your OS doesn't boot, you can't read the labels. But you can still mount by disk number and partition (sda1 sda2 sda3 sdb1 sdb2...etc).
-- so I reverted to boot from hard disk and haven't looked back.
Does any of the above paragraph have anything to do with anything previously written in this thread, the OP in particular?
It was suggested that booting by labels was a solution, to the OP, but first you need to find the ram-disk image and what partition it is on in order to boot the ram disk. So booting by labels requires knowing what disks (sda, sdb...) as well as the partition -- if those change dynamically, the normal boot process may not work.
I've mostly stopped using labels because something has to already be up to populate /dev/disk/by-*/ (i.e. the kernel needs to be booted and udev has to already have been called in the "boot" phase (i.e. /etc/boot.d/(scripts))... Only after the boot phase has done its stuff are "higher level" things like labels available.
If you're not using labels, what are you using, and why?
--- Using the device names -- as they are available before before the USER space comes up and can be brought up with a static snapshot of "/dev" (when udevd isn't running (or won't run)). So if you create a static "/dev/" directory on your root device filled with your system's devices needed for boot -- you can boot and mount your disks w/o udev. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (9)
-
Andrey Borzenkov -
Carlos E. R. -
Carlos E. R. -
Cristian Rodríguez -
Felix Miata -
Hannes Reinecke -
Linda Walsh -
Olaf Hering -
Stefan Seyfried