[opensuse-factory] /boot partition is too small when you selected "Create LVM Based Proposal"in "Suggested Partitioning" on installer .
Hi all . When I selected "Create LVM Based Proposal" in "Suggested Partitioning" on installer, Installer suggested "Create boot volume /dev/sda1 (156.88 MB)" . But it is too small for for updating the kernel . The present state is as follows. Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 154691 108188 38516 74% /boot rpm -qa 'kernel-desktop' kernel-desktop-3.7.10-1.16.1.x86_64 kernel-desktop-3.7.10-1.11.1.x86_64 Disk storage capacity runs short in update of the next kernel . In the past, disk storage capacity actually ran short by update of the kernel . I think that the /boot partition should be more than 256 M byte required. (ex: 1 G byte) I wrote https://bugzilla.novell.com/show_bug.cgi?id=826981 . I want you to tell your opinions . -- 1xx <ItSANgo@gmail.com> <https://twitter.com/ItSANgo> <http://d.hatena.ne.jp/Itisango/> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Jun 27, 2013 at 03:55:15PM +0900, 1xx wrote:
Hi all .
When I selected "Create LVM Based Proposal" in "Suggested Partitioning" on installer, Installer suggested "Create boot volume /dev/sda1 (156.88 MB)" . But it is too small for for updating the kernel .
The present state is as follows.
Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 154691 108188 38516 74% /boot
I think that the /boot partition should be more than 256 M byte required. (ex: 1 G byte)
When you use virtual machines with small disks, e.g. 8GB, you don't want such a big /boot partition.
I want you to tell your opinions .
The initrd is terrible big, around 32MB. That should be fixed. Regards, Arvin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2013-06-27 11:14, Arvin Schnell wrote:
I want you to tell your opinions .
The initrd is terrible big, around 32MB. That should be fixed.
Definitely. 10-15 years ago we had fat initrds that included a handful of disk drivers. Today, mkinitrd is smart to look at the root device and figure out the _single one_ driver needed. Except not quite... it adds DHs, which are just bloat to me: Kernel Modules: hwmon thermal_sys thermal processor fan scsi_dh scsi_dh_hp_sw scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_transport_sas mptbase mptscsih mptsas usb-common usbcore ohci-hcd uhci-hcd ehci-hcd xhci-hcd hid usbhid hid-logitech-dj hid-generic same goes for hwmon. Besides some potential Apple hardware, is there anything that needs hardware monitoring in the initrd stage? "fan" is not even loaded after boot is complete! And hid-logitech-dj, well, it suffices to say that we do not ship gpm in the initrd. $ lsmod [...] processor 45014 0 thermal_sys 26593 1 processor hwmon 12967 1 thermal_sys [...] scsi_dh_alua 13065 0 scsi_dh_rdac 13351 0 scsi_dh_emc 13162 0 scsi_dh_hp_sw 12894 0 [...] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27.06.2013 12:54, Jan Engelhardt wrote:
On Thursday 2013-06-27 11:14, Arvin Schnell wrote:
I want you to tell your opinions .
The initrd is terrible big, around 32MB. That should be fixed.
Definitely. 10-15 years ago we had fat initrds that included a handful of disk drivers. Today, mkinitrd is smart to look at the root device and figure out the _single one_ driver needed. Except not quite... it adds DHs, which are just bloat to me:
Of course the things you consider bloat here are worth one MB or less. The real bloat is the bootsplash graphics. In the old days the initrd has one graphic to load and the animation started only when the early boot process took over. Nowadays plymouth needs to be in the intird and this adds *really* a lot. Plus we add splashy, which is even less needed. Someone will have to maintain this some day ;( Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le jeudi 27 juin 2013 à 12:59 +0200, Stephan Kulow a écrit :
On 27.06.2013 12:54, Jan Engelhardt wrote:
On Thursday 2013-06-27 11:14, Arvin Schnell wrote:
I want you to tell your opinions .
The initrd is terrible big, around 32MB. That should be fixed.
Definitely. 10-15 years ago we had fat initrds that included a handful of disk drivers. Today, mkinitrd is smart to look at the root device and figure out the _single one_ driver needed. Except not quite... it adds DHs, which are just bloat to me:
Of course the things you consider bloat here are worth one MB or less. The real bloat is the bootsplash graphics. In the old days the initrd has one graphic to load and the animation started only when the early boot process took over. Nowadays plymouth needs to be in the intird and this adds *really* a lot. Plus we add splashy, which is even less needed.
Someone will have to maintain this some day ;(
Before "maintaining", we need to clean this "mess". We should switch to dracut (which is maintained and allow smaller initrd), see if we can reduce plymouth footprint (it is mostly caused by the text support for passphrase) and get right of splashy (it is pulled by suspend, which is strange, I implemented plymouth support in suspend a lot time ago..). -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu 27 Jun 2013 07:30:23 AM EDT, Frederic Crozat wrote:
Le jeudi 27 juin 2013 à 12:59 +0200, Stephan Kulow a écrit :
On 27.06.2013 12:54, Jan Engelhardt wrote:
On Thursday 2013-06-27 11:14, Arvin Schnell wrote:
I want you to tell your opinions .
The initrd is terrible big, around 32MB. That should be fixed.
Definitely. 10-15 years ago we had fat initrds that included a handful of disk drivers. Today, mkinitrd is smart to look at the root device and figure out the _single one_ driver needed. Except not quite... it adds DHs, which are just bloat to me:
Of course the things you consider bloat here are worth one MB or less. The real bloat is the bootsplash graphics. In the old days the initrd has one graphic to load and the animation started only when the early boot process took over. Nowadays plymouth needs to be in the intird and this adds *really* a lot. Plus we add splashy, which is even less needed.
Someone will have to maintain this some day ;(
Before "maintaining", we need to clean this "mess". We should switch to dracut (which is maintained and allow smaller initrd), see if we can reduce plymouth footprint (it is mostly caused by the text support for passphrase) and get right of splashy (it is pulled by suspend, which is strange, I implemented plymouth support in suspend a lot time ago..).
+1 -- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.06.2013 13:30, schrieb Frederic Crozat:
Someone will have to maintain this some day ;(
Before "maintaining", we need to clean this "mess". We should switch to dracut (which is maintained and allow smaller initrd), see if we can
You should know that switching to dracut *is* maintaining. It's not done by pure will power. Greetings, Stephan -- 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: SHA1 On Thursday, 2013-06-27 at 13:30 +0200, Frederic Crozat wrote:
Le jeudi 27 juin 2013 à 12:59 +0200, Stephan Kulow a écrit :
On 27.06.2013 12:54, Jan Engelhardt wrote:
On Thursday 2013-06-27 11:14, Arvin Schnell wrote:
I want you to tell your opinions .
Yes, the size of boot should be increased, up to half a gigabyte at least. Or more, to last more years. 150 megs is ridiculous nowdays.
Of course the things you consider bloat here are worth one MB or less. The real bloat is the bootsplash graphics. In the old days the initrd has one graphic to load and the animation started only when the early boot process took over. Nowadays plymouth needs to be in the intird and this adds *really* a lot. Plus we add splashy, which is even less needed.
Someone will have to maintain this some day ;(
Before "maintaining", we need to clean this "mess". We should switch to dracut (which is maintained and allow smaller initrd), see if we can reduce plymouth footprint (it is mostly caused by the text support for passphrase) and get right of splashy (it is pulled by suspend, which is strange, I implemented plymouth support in suspend a lot time ago..).
I use a separate /boot partition, sized 200MB a few years back. I intentionally remove plymouth from my systems to reduce initrd size. And yes, I need the boot process to ask for my encription password. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHMjqcACgkQtTMYHG2NR9XW6ACdGwNQR6BHwPviw3L8EHfKLJQI AfEAnRMiwEG2e67yI6R8rRU9t+Z0mwVc =S5ZB -----END PGP SIGNATURE-----
On Thursday 27 June 2013 13.30:23 Frederic Crozat wrote:
Le jeudi 27 juin 2013 à 12:59 +0200, Stephan Kulow a écrit :
On 27.06.2013 12:54, Jan Engelhardt wrote:
On Thursday 2013-06-27 11:14, Arvin Schnell wrote:
I want you to tell your opinions .
The initrd is terrible big, around 32MB. That should be fixed.
Definitely. 10-15 years ago we had fat initrds that included a handful of disk drivers. Today, mkinitrd is smart to look at the root device and figure out the _single one_ driver needed. Except not quite... it adds DHs, which are just bloat
to me: Of course the things you consider bloat here are worth one MB or less. The real bloat is the bootsplash graphics. In the old days the initrd has one graphic to load and the animation started only when the early boot process took over. Nowadays plymouth needs to be in the intird and this adds *really* a lot. Plus we add splashy, which is even less needed.
Someone will have to maintain this some day ;(
Before "maintaining", we need to clean this "mess". We should switch to dracut (which is maintained and allow smaller initrd), see if we can reduce plymouth footprint (it is mostly caused by the text support for passphrase) and get right of splashy (it is pulled by suspend, which is strange, I implemented plymouth support in suspend a lot time ago..).
+1 about splashy. For the plymouth and the heavy branding there's one solution (don't know if good for cpu) would be to have svg support in plymouth. another thing could be to find a way to able all the damned ratio screen with one branding which could work on any of them We will save Megabytes -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Jun 27, 2013 at 10:15 PM, Bruno Friedmann <bruno@ioda-net.ch> wrote:
On Thursday 27 June 2013 13.30:23 Frederic Crozat wrote:
Le jeudi 27 juin 2013 à 12:59 +0200, Stephan Kulow a écrit :
On 27.06.2013 12:54, Jan Engelhardt wrote:
On Thursday 2013-06-27 11:14, Arvin Schnell wrote:
I want you to tell your opinions .
The initrd is terrible big, around 32MB. That should be fixed.
Definitely. 10-15 years ago we had fat initrds that included a handful of disk drivers. Today, mkinitrd is smart to look at the root device and figure out the _single one_ driver needed. Except not quite... it adds DHs, which are just bloat
to me: Of course the things you consider bloat here are worth one MB or less. The real bloat is the bootsplash graphics. In the old days the initrd has one graphic to load and the animation started only when the early boot process took over. Nowadays plymouth needs to be in the intird and this adds *really* a lot. Plus we add splashy, which is even less needed.
Someone will have to maintain this some day ;(
Before "maintaining", we need to clean this "mess". We should switch to dracut (which is maintained and allow smaller initrd), see if we can reduce plymouth footprint (it is mostly caused by the text support for passphrase) and get right of splashy (it is pulled by suspend, which is strange, I implemented plymouth support in suspend a lot time ago..).
+1 about splashy.
For the plymouth and the heavy branding there's one solution (don't know if good for cpu) would be to have svg support in plymouth.
another thing could be to find a way to able all the damned ratio screen with one branding which could work on any of them
We will save Megabytes
FWIW, I've expanded my 32MB initrd and looked for the top 10 largest files $ find -type f | xargs stat --format='%s %n' | sort -rn 17958164 ./usr/lib64/libicudata.so.49.1 2739154 ./usr/share/plymouth/themes/openSUSE/blank-background-1610-optim.png 2687851 ./usr/share/plymouth/themes/openSUSE/blank-background-1610.png 2480422 ./usr/share/plymouth/themes/openSUSE/blank-background-169.png 2265833 ./usr/share/plymouth/themes/openSUSE/blank-background-43.png 1992089 ./lib64/libc-2.17.so 1898072 ./lib64/libcrypto.so.1.0.0 1543112 ./usr/lib64/libicuuc.so.49.1 1473277 ./usr/share/plymouth/themes/openSUSE/blank-background-54.png 1463456 ./usr/lib64/libxml2.so.2.9.0 The expanded size is $ du -sb . 69325147 . So indeed the branding takes up a lot of space, but I'm suprised to see libicu49 take take the lion's share. Robert -- http://robert.muntea.nu/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2013-06-27 22:13, Robert Munteanu wrote:
FWIW, I've expanded my 32MB initrd and looked for the top 10 largest files
$ find -type f | xargs stat --format='%s %n' | sort -rn 17958164 ./usr/lib64/libicudata.so.49.1 2739154 ./usr/share/plymouth/themes/openSUSE/blank-background-1610-optim.png
So indeed the branding takes up a lot of space, but I'm suprised to see libicu49 take take the lion's share.
And PNGs - visually nice, but large. SUSE had used JPEG in past times, which was some compromise between edge quality and size. Maybe it's WebP time now? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Thu, 27 Jun 2013 23:13:57 +0300 Robert Munteanu <robert.munteanu@gmail.com> пишет:
FWIW, I've expanded my 32MB initrd and looked for the top 10 largest files
$ find -type f | xargs stat --format='%s %n' | sort -rn
17958164 ./usr/lib64/libicudata.so.49.1 2739154 ./usr/share/plymouth/themes/openSUSE/blank-background-1610-optim.png 2687851 ./usr/share/plymouth/themes/openSUSE/blank-background-1610.png 2480422 ./usr/share/plymouth/themes/openSUSE/blank-background-169.png 2265833 ./usr/share/plymouth/themes/openSUSE/blank-background-43.png 1992089 ./lib64/libc-2.17.so 1898072 ./lib64/libcrypto.so.1.0.0 1543112 ./usr/lib64/libicuuc.so.49.1 1473277 ./usr/share/plymouth/themes/openSUSE/blank-background-54.png 1463456 ./usr/lib64/libxml2.so.2.9.0
The expanded size is
$ du -sb .
69325147 .
So indeed the branding takes up a lot of space, but I'm suprised to see libicu49 take take the lion's share.
bor@opensuse:~> rpm -qf /usr/lib64/libicudata.so.49.1 libicu49-49.1-6.1.1.x86_64 bor@opensuse:~> LC_ALL=C rpm -q --whatrequires libicu49-49.1-6.1.1.x86_64 no package requires libicu49-49.1-6.1.1.x86_64 So, why it is picked at all? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 28 Jun 2013 04:37, Andrey Borzenkov <arvidjaar@...> wrote:
В Thu, 27 Jun 2013 23:13:57 +0300 Robert Munteanu <robert.munteanu@gmail.com> пишет:
FWIW, I've expanded my 32MB initrd and looked for the top 10 largest files [snip] So indeed the branding takes up a lot of space, but I'm suprised to see libicu49 take take the lion's share.
bor@opensuse:~> rpm -qf /usr/lib64/libicudata.so.49.1 libicu49-49.1-6.1.1.x86_64 bor@opensuse:~> LC_ALL=C rpm -q --whatrequires libicu49-49.1-6.1.1.x86_64 no package requires libicu49-49.1-6.1.1.x86_64
not really, try "LC_ALL=C rpm -e --test libicu49" on OSS 12.3 the list is long: libicudata.so.49: libreoffice libicui18n.so.49: libjavascriptcoregtk-3_0 libjavascriptcoregtk-1_0 libtracker-common-0_14 libreoffice libreoffice-writer libwebkitgtk-3_0 libwebkitgtk-1_0 libicuio.so.49: gptfdisk libicule.so.49: libharfbuzz0 libreoffice libicuuc.so.49: libjavascriptcoregtk-3_0 libjavascriptcoregtk-1_0 libharfbuzz0 libtracker-common-0_14 libwebkitgtk-3_0 libwebkitgtk-1_0 libreoffice libreoffice-writer gptfdisk But, just WHAT program / lib pulls libicudata.so.49 into initrd (cant't lay the blame atm.)? For sure a 18mb pullin into a (decomressed) 64mb initrd is a shame and should be avoided. Imho the "grip below the belt" by "suspend" to require "splashy" should be easier to (ab)solve. After that we could drop "splashy", and fast, add a backport of this patch to 12.3 and bring a little relieve to them, too. On comression: be carefull about selecting algoritms, and do a comparision on DECOMPRESSION times with a single cpu core in use. Conclusion: Please, a little attention to the unix axiom "small is beautyfull" is needed, esp. during boot / initrd. Thanks to all who help in this. - Yamaban.
On Fri, Jun 28, 2013 at 11:54 AM, Yamaban <foerster@lisas.de> wrote:
On Fri, 28 Jun 2013 04:37, Andrey Borzenkov <arvidjaar@...> wrote:
В Thu, 27 Jun 2013 23:13:57 +0300 Robert Munteanu <robert.munteanu@gmail.com> пишет:
FWIW, I've expanded my 32MB initrd and looked for the top 10 largest files
[snip]
So indeed the branding takes up a lot of space, but I'm suprised to see libicu49 take take the lion's share.
bor@opensuse:~> rpm -qf /usr/lib64/libicudata.so.49.1 libicu49-49.1-6.1.1.x86_64 bor@opensuse:~> LC_ALL=C rpm -q --whatrequires libicu49-49.1-6.1.1.x86_64 no package requires libicu49-49.1-6.1.1.x86_64
not really, try "LC_ALL=C rpm -e --test libicu49"
Ah, OK, I was spoiled by urpmi which looks in all requires ...
But, just WHAT program / lib pulls libicudata.so.49 into initrd (cant't lay the blame atm.)?
It is pulled in through libpancocairo.so which in turn is pulled in by /usr/lib/plymouth/label.so -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2013-06-28 12:05, Andrey Borzenkov wrote:
FWIW, I've expanded my 32MB initrd and looked for the top 10 largest files So indeed the branding takes up a lot of space, but I'm suprised to see libicu49 take take the lion's share.
bor@opensuse:~> rpm -qf /usr/lib64/libicudata.so.49.1 libicu49-49.1-6.1.1.x86_64 bor@opensuse:~> LC_ALL=C rpm -q --whatrequires libicu49-49.1-6.1.1.x86_64 no package requires libicu49-49.1-6.1.1.x86_64
But, just WHAT program / lib pulls libicudata.so.49 into initrd (cant't lay the blame atm.)?
It is pulled in through libpancocairo.so which in turn is pulled in by /usr/lib/plymouth/label.so
I can offer a solution whereby libicudata.so is replaced by a stub and the actual data is provided in a separate (noarch) file. Not sure what happens though if the data file is not actually present when a program runs... any testers? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jun 28, 2013 at 2:47 PM, Jan Engelhardt <jengelh@inai.de> wrote:
On Friday 2013-06-28 12:05, Andrey Borzenkov wrote:
FWIW, I've expanded my 32MB initrd and looked for the top 10 largest files So indeed the branding takes up a lot of space, but I'm suprised to see libicu49 take take the lion's share.
bor@opensuse:~> rpm -qf /usr/lib64/libicudata.so.49.1 libicu49-49.1-6.1.1.x86_64 bor@opensuse:~> LC_ALL=C rpm -q --whatrequires libicu49-49.1-6.1.1.x86_64 no package requires libicu49-49.1-6.1.1.x86_64
But, just WHAT program / lib pulls libicudata.so.49 into initrd (cant't lay the blame atm.)?
It is pulled in through libpancocairo.so which in turn is pulled in by
libpangocairo.so of course
/usr/lib/plymouth/label.so
I can offer a solution whereby libicudata.so is replaced by a stub and the actual data is provided in a separate (noarch) file. Not sure what happens though if the data file is not actually present when a program runs... any testers?
How does it affect i18n? We do want to be able to display in native language, assuming we want plymouth in initrd at all. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28.06.2013 13:06, Andrey Borzenkov wrote:
How does it affect i18n? We do want to be able to display in native language, assuming we want plymouth in initrd at all.
I wonder if you can't prerender whatever text you have to display. And only take the wallpaper that fits the resolution expected. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-06-28 14:05 (GMT+0400) Andrey Borzenkov composed:
Yamaban wrote:
not really, try "LC_ALL=C rpm -e --test libicu49"
Ah, OK, I was spoiled by urpmi which looks in all requires ...
But, just WHAT program / lib pulls libicudata.so.49 into initrd (cant't lay the blame atm.)?
It is pulled in through libpancocairo.so which in turn is pulled in by /usr/lib/plymouth/label.so
Yi yi yi yi yi yi yi. Maybe unlike some other top 10 distros, openSUSE can _keep_ Plymouth optional. KISS and configurability were great while they lasted. Meanwhile, Gentoo seems more appealing than ever. -- "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
Frederic Crozat wrote:
Le jeudi 27 juin 2013 à 12:59 +0200, Stephan Kulow a écrit :
On 27.06.2013 12:54, Jan Engelhardt wrote:
On Thursday 2013-06-27 11:14, Arvin Schnell wrote:
I want you to tell your opinions .
The initrd is terrible big, around 32MB. That should be fixed.
Definitely. 10-15 years ago we had fat initrds that included a handful of disk drivers. Today, mkinitrd is smart to look at the root device and figure out the _single one_ driver needed. Except not quite... it adds DHs, which are just bloat to me:
Of course the things you consider bloat here are worth one MB or less. The real bloat is the bootsplash graphics. In the old days the initrd has one graphic to load and the animation started only when the early boot process took over. Nowadays plymouth needs to be in the intird and this adds *really* a lot. Plus we add splashy, which is even less needed.
Someone will have to maintain this some day ;(
Before "maintaining", we need to clean this "mess". We should switch to dracut (which is maintained and allow smaller initrd), see if we can reduce plymouth footprint (it is mostly caused by the text support for passphrase) and get right of splashy (it is pulled by suspend, which is strange, I implemented plymouth support in suspend a lot time ago..).
Even if dracut manages to save a few bytes because it has the more magic shell code that won't make a difference as long as plymouth just adds 20+MB extra to display a padlock icon with some text. Maybe we should forget about plymouth in initrd as it's supposed to be done quickly anyways. Who cares how colorful that encrypted root password prompt is. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le vendredi 28 juin 2013 à 09:19 +0200, Ludwig Nussel a écrit :
Frederic Crozat wrote:
Le jeudi 27 juin 2013 à 12:59 +0200, Stephan Kulow a écrit :
On 27.06.2013 12:54, Jan Engelhardt wrote:
On Thursday 2013-06-27 11:14, Arvin Schnell wrote:
I want you to tell your opinions .
The initrd is terrible big, around 32MB. That should be fixed.
Definitely. 10-15 years ago we had fat initrds that included a handful of disk drivers. Today, mkinitrd is smart to look at the root device and figure out the _single one_ driver needed. Except not quite... it adds DHs, which are just bloat to me:
Of course the things you consider bloat here are worth one MB or less. The real bloat is the bootsplash graphics. In the old days the initrd has one graphic to load and the animation started only when the early boot process took over. Nowadays plymouth needs to be in the intird and this adds *really* a lot. Plus we add splashy, which is even less needed.
Someone will have to maintain this some day ;(
Before "maintaining", we need to clean this "mess". We should switch to dracut (which is maintained and allow smaller initrd), see if we can reduce plymouth footprint (it is mostly caused by the text support for passphrase) and get right of splashy (it is pulled by suspend, which is strange, I implemented plymouth support in suspend a lot time ago..).
Even if dracut manages to save a few bytes because it has the more magic shell code that won't make a difference as long as plymouth just adds 20+MB extra to display a padlock icon with some text. Maybe we should forget about plymouth in initrd as it's supposed to be done quickly anyways. Who cares how colorful that encrypted root password prompt is.
Plymouth itself doesn't add 20MB to initrd, it is the label.so plugin and its dependencies which do that (upstream doesn't display text for passphrase prompt, just a padlock icon. We should probably pre-render the text for the passphrase prompt into a transparent png file when generating initrd, and display this png file as a sprite (just like the padlock icon is being display ATM) in initrd. This way, text plugin and its deps wouldn't land in initrd. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Plymouth itself doesn't add 20MB to initrd, it is the label.so plugin and its dependencies which do that (upstream doesn't display text for passphrase prompt, just a padlock icon.
We should probably pre-render the text for the passphrase prompt into a transparent png file when generating initrd, and display this png file as a sprite (just like the padlock icon is being display ATM) in initrd. This way, text plugin and its deps wouldn't land in initrd.
Okay this sounds like a way to go. Would not be that hard to add a layer of text (which is always in english) and render it as png8 -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jun 28, 2013 at 1:41 PM, Bruno Friedmann <bruno@ioda-net.ch> wrote:
Plymouth itself doesn't add 20MB to initrd, it is the label.so plugin and its dependencies which do that (upstream doesn't display text for passphrase prompt, just a padlock icon.
We should probably pre-render the text for the passphrase prompt into a transparent png file when generating initrd, and display this png file as a sprite (just like the padlock icon is being display ATM) in initrd. This way, text plugin and its deps wouldn't land in initrd.
Okay this sounds like a way to go. Would not be that hard to add a layer of text (which is always in english) and render it as png8
Why always english? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 28 June 2013 14.04:12 Claudio Freire wrote:
On Fri, Jun 28, 2013 at 1:41 PM, Bruno Friedmann <bruno@ioda-net.ch> wrote:
Plymouth itself doesn't add 20MB to initrd, it is the label.so plugin and its dependencies which do that (upstream doesn't display text for passphrase prompt, just a padlock icon.
We should probably pre-render the text for the passphrase prompt into a transparent png file when generating initrd, and display this png file as a sprite (just like the padlock icon is being display ATM) in initrd. This way, text plugin and its deps wouldn't land in initrd.
Okay this sounds like a way to go. Would not be that hard to add a layer of text (which is always in english) and render it as png8
Why always english?
Was never translated, and most luks only support qwerty keyboard layout ! pls : only reply to ml. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----Original Message----- From: Bruno Friedmann <bruno@ioda-net.ch> To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] /boot partition is too small when you selected "Create LVM Based Proposal"in "Suggested Partitioning" on installer . Date: Sat, 29 Jun 2013 11:04:42 +0200 On Friday 28 June 2013 14.04:12 Claudio Freire wrote:
On Fri, Jun 28, 2013 at 1:41 PM, Bruno Friedmann <bruno@ioda-net.ch> wrote:
Plymouth itself doesn't add 20MB to initrd, it is the label.so plugin and its dependencies which do that (upstream doesn't display text for passphrase prompt, just a padlock icon.
We should probably pre-render the text for the passphrase prompt into a transparent png file when generating initrd, and display this png file as a sprite (just like the padlock icon is being display ATM) in initrd. This way, text plugin and its deps wouldn't land in initrd.
Okay this sounds like a way to go. Would not be that hard to add a layer of text (which is always in english) and render it as png8
Why always english?
Was never translated, and most luks only support qwerty keyboard layout ! -----Original Message----- Yeah, bumbed my head there as well. 1) at a web site asking users to come-up with a strong pwd (letters + numbers + symbols) 2) use that for creating an luks image 3) let them used that at home ... Our help desk never knew that there are so many different keyboards ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 27 June 2013 12.54:08 Jan Engelhardt wrote:
And hid-logitech-dj, well, it suffices to say that we do not ship gpm in the initrd.
But needed with wireless keyboard, always usefull to open a luks encrypted partition without needed to find a wired cable usb one. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Donnerstag, 27. Juni 2013 schrieb Bruno Friedmann:
On Thursday 27 June 2013 12.54:08 Jan Engelhardt wrote:
And hid-logitech-dj, well, it suffices to say that we do not ship gpm in the initrd.
But needed with wireless keyboard, always usefull to open a luks encrypted partition without needed to find a wired cable usb one.
Looks like you need to adjust your level of paranoia ;-) I have a wireless keyboard connected to my laptop, but I always use the laptop's keyboard to enter passwords. I _never_ enter a password on the wireless keyboard. That would be like crying out "my password is y68gJNDSWLD3n" ;-) Regards, Christian Boltz -- Natürlich kann ich Traktor fahren. Ich bin der geborene Traktorfahrer. Es dürfte dir schwer fallen, jemanden zu finden, der annähernd so perfekt Traktor fährt wie ich. Ja, ich _bin_ geradezu ein Traktor. Wieviele Räder hat so ein Traktor eigentlich? [Ratti] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 29 June 2013 00.26:58 Christian Boltz wrote:
Hello,
Am Donnerstag, 27. Juni 2013 schrieb Bruno Friedmann:
On Thursday 27 June 2013 12.54:08 Jan Engelhardt wrote:
And hid-logitech-dj, well, it suffices to say that we do not ship gpm in the initrd.
But needed with wireless keyboard, always usefull to open a luks encrypted partition without needed to find a wired cable usb one.
Looks like you need to adjust your level of paranoia ;-)
I have a wireless keyboard connected to my laptop, but I always use the laptop's keyboard to enter passwords.
I _never_ enter a password on the wireless keyboard. That would be like crying out "my password is y68gJNDSWLD3n" ;-)
Regards,
Christian Boltz
In fact you already do it, each keystroke on the internal keyboard has a unique sound .... ;-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 30 Jun 2013 10:20:10 +0200 Bruno Friedmann <bruno@ioda-net.ch> wrote:
In fact you already do it, each keystroke on the internal keyboard has a unique sound .... ;-)
Which doesn't go as far as wireless signals :) -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2013-07-04 20:34, Rajko wrote:
On Sun, 30 Jun 2013 10:20:10 +0200 Bruno Friedmann <bruno@ioda-net.ch> wrote:
In fact you already do it, each keystroke on the internal keyboard has a unique sound .... ;-)
Which doesn't go as far as wireless signals :)
There is a fix for that regression! Manufacturers of keyboards have placed additional steel plates into certain KB models (e.g. Cherry G80-3000). Audiophiles love it because they "just sound better" or because it has got gold contacts for improved digital transmission [sic] - but of course, everybody sane knows the steel plating and ensuing sound amplification is meant for your local "security" agency doing surveillance on you. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 04.07.2013 21:08, schrieb Jan Engelhardt:
Manufacturers of keyboards have placed additional steel plates into certain KB models (e.g. Cherry G80-3000). Audiophiles love it because they "just sound better" or because it has got gold contacts for improved digital transmission [sic] - but of course, everybody sane knows the steel plating and ensuing sound amplification is meant for your local "security" agency doing surveillance on you.
Of course. Didn't you know that I keep my large collection of vintage Cherry G80 and IBM Model M keyboards only to help the NSA "protect" me? :-) ...and now back to on-topic posts... -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Jun 27, 2013 at 12:14 PM, Arvin Schnell <aschnell@suse.de> wrote:
I want you to tell your opinions .
The initrd is terrible big, around 32MB. That should be fixed.
Agreed. Please note that there was a discussion on opensuse-factory regarding slow boot times due to a large initrd [1] so there's value in trimming it down. Robert [1]: http://lists.opensuse.org/opensuse-factory/2013-03/msg00162.html -- http://robert.muntea.nu/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Robert Munteanu wrote:
On Thu, Jun 27, 2013 at 12:14 PM, Arvin Schnell <aschnell@suse.de> wrote:
I want you to tell your opinions . The initrd is terrible big, around 32MB. That should be fixed.
Agreed. Please note that there was a discussion on opensuse-factory regarding slow boot times due to a large initrd [1] so there's value in trimming it down. === There is advice on the systemd website that to speed up boot-- get rid of it entirely.
Wouldn't do for a generic -from-the-CD-install/boot, BUT, just as initrd is a custom config/user's system that is autobuilt for their system, why not do the same with a kernel so it boots directly from HD? Biggest things on my disk are the xen symbols followed by the desktop image. 5.5M vmlinux-3.9.0-1-default.gz 5.5M vmlinuz-3.5.4-Isht-Van 5.5M vmlinuz-3.8.4-Isht-Van 5.5M vmlinuz-3.8.8-Isht-Van 5.6M vmlinuz-3.3.6-Ish-Van 5.6M vmlinuz-3.6.0-Isht-Van 5.7M vmlinuz-3.4.4-Ish-Vanilla 5.8M vmlinux-3.9.0-1-desktop.gz 15M xen-syms-4.2.2_01-1.1 15M xen-syms-dbg-4.2.2_01-1.1
ll|grep vmlinuz|wc -l 27 === I have about 27 kernels on my boot disk right now Ishar:/boot> du -sh 245M . -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le jeudi 27 juin 2013 à 17:46 -0700, Linda Walsh a écrit :
Robert Munteanu wrote:
On Thu, Jun 27, 2013 at 12:14 PM, Arvin Schnell <aschnell@suse.de> wrote:
I want you to tell your opinions . The initrd is terrible big, around 32MB. That should be fixed.
Agreed. Please note that there was a discussion on opensuse-factory regarding slow boot times due to a large initrd [1] so there's value in trimming it down. === There is advice on the systemd website that to speed up boot-- get rid of it entirely.
I strongly doubt systemd folks are advising to drop initrd at all.. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 28/06/13 04:03, Frederic Crozat escribió:
I strongly doubt systemd folks are advising to drop initrd at all..
There is an article about that in the systemd online docs, however it intended for setups where you have complete control of the target environment, not for generic general purpose distributions. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
El 28/06/13 04:03, Frederic Crozat escribió:
I strongly doubt systemd folks are advising to drop initrd at all..
There is an article about that in the systemd online docs, however it intended for setups where you have complete control of the target environment, not for generic general purpose distributions.
It was aimed at end users who wanted fast boot times. Now they have a tutorial on how to create a minimal initrd with mkinitcpio: Trim the fat With your module list ready to go, it’s time to tear apart mkinitcpio.conf. Since you’re explicitly finding and loading modules, you’re going to be very light on hooks. Based on the above, you could put together the following config: # # /etc/mkinitcpio.conf # MODULES="ahci sd_mod ext4" BINARIES="fsck fsck.ext4" HOOKS="base" And that’s it. We don’t need udev, since anything in the MODULES variable will be explicitly loaded. mkinitcpio is also kind enough to do dependency resolution for us. I still advise you to keep (or add?) fsck to your image, as checking your filesystem before it’s even mounted is greatly beneficial. I’ll leave it as an exercise to the reader to figure out additional modules for things like: usb keyboards or raid/lvm root devices. For your maiden voyage, I highly recommend creating a separate image in case you’ve forgotten something. # mkinitcpio -g /boot/initramfs-linux-tiny.img Either add another entry to your bootloader, or feel free to modify it on the fly at bootup. If this image isn’t sufficient and init won’t mount your root, go back through sysfs another time and check your work. Pick through the output of ‘mkinitcpio -M’ and check over what the modules do with ‘modinfo’. The description may not be very useful, but the path within the module directory can be very telling. That’s pretty much all there is to it. A little bit of understanding about your hardware and some familiarity with the common kernel modules can go a long way. ---- That's cutting it to the bone. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2013-06-28 21:56, Linda Walsh wrote:
# # /etc/mkinitcpio.conf #
MODULES="ahci sd_mod ext4" BINARIES="fsck fsck.ext4" HOOKS="base"
And that’s it. We don’t need udev, since anything in the MODULES variable will be explicitly loaded.
udev (or something like it) does not just load modules, it also creates the required device nodes. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Jun 29, 2013 at 12:34:14AM +0200, Jan Engelhardt wrote:
On Friday 2013-06-28 21:56, Linda Walsh wrote:
# # /etc/mkinitcpio.conf #
MODULES="ahci sd_mod ext4" BINARIES="fsck fsck.ext4" HOOKS="base"
And that’s it. We don’t need udev, since anything in the MODULES variable will be explicitly loaded.
udev (or something like it) does not just load modules, it also creates the required device nodes.
No it doesn't, devtmpfs does that. udev sets the proper permissions on those device nodes, that's all. But the point that seems to escape some people on this thread, is that an initrd really is needed in order to be able to support the huge number of systems that the distro supports, so it isn't going away, sorry. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Greg KH wrote:
On Sat, Jun 29, 2013 at 12:34:14AM +0200, Jan Engelhardt wrote:
On Friday 2013-06-28 21:56, Linda Walsh wrote:
# # /etc/mkinitcpio.conf MODULES="ahci sd_mod ext4" BINARIES="fsck fsck.ext4" HOOKS="base"
And that’s it. We don’t need udev, since anything in the MODULES variable will be explicitly loaded. udev (or something like it) does not just load modules, it also creates the required device nodes.
No it doesn't, devtmpfs does that. udev sets the proper permissions on those device nodes, that's all.
BTW, I didn't write the above, it was from the webpage. However, doesn't some type of program or driver (specifically /devtmpfs) pre-create basic device nodes as a stop gap measure? What , they didn't realize that the thing that loads the devices isnt' the same driver that creates the nodes,_and_, I'm under the impression that devtmpfs's list of devices that it creates is fairly static.
But the point that seems to escape some people on this thread, is that an initrd really is needed in order to be able to support the huge number of systems that the distro supports, so it isn't going away, sorry. greg k-h
But you can support all the hardware with just the above modules on the initrd, right? That is from a general page for creating a minimal initRD to optimize & speed up boot. In the PC world, once you've loaded your drivers, now you can go to the HW abstraction layer in the kernel and run your startup daemon from the hard disk. Right? That is what the article is saying -- that the above is the minimum necessary to get the kernel running with enough on any given system so that it can continue the boot off of the hard disk (with fsck utils included for those file systems that need them). Or does suse need something else to handle the wide variety of pc-compatibles out there? Now lets suppose your root file system didn't need an "fsck". Example: "xfs". A fs on a solid state drive should be as safe as a ramdisk if not safer -- so maybe BRT_FS might not need a check either? If that's the case, then you only need those few modules for your machine. Now wouldn't it be possible to recompile a kernel and include those? Either you aren't telling us some other need than hardware, or I'm missing part of the requirements. So what am I missing? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jun 28, 2013 at 04:59:09PM -0700, Linda Walsh wrote:
If that's the case, then you only need those few modules for your machine. Now wouldn't it be possible to recompile a kernel and include those?
No user is ever going to be asked to rebuild any kernels, that's the point, sorry. Nor is it going to be automated. If you wish to do something like this, feel free to, but for a general-purpose Linux distro, that way lies madness, trust me[1]. greg k-h [1] I've helped develop/support/maintain 6 different Linux distros now, it's as if we actually know what we are doing... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
For me this thread is going roiund in circles gathering ever more snow. Greg h-k is of course right and there is nothing wrong with initrd(s) as separate files, booters know how to load them and they can be updated independen of the vm... The sole problem is that mkinitrd re-makes ALL initrds by DEFAULT, and thus silently break existing boot combinations. Also mkinitrd's command line arguments, which let you linit this are un-intuitive and complex. 99% of the problem would be fixed by having mkinitrd ONLY rebuild missing initrds and a '--all' switch and that is about 10 lines of bash. That is it, all the rest is a Unicorn hunt, and unless you build kernels to try to keep up with greg k-h 'stable' would never worry you, sometimes when I have just built 3.9.7 I wake up to find k-h just released 9,10 overnight. Greg keep up your goog works and thanks! MFG, omb
Am Fri, 28 Jun 2013 17:54:25 -0700, scheib Greg KH:
On Fri, Jun 28, 2013 at 04:59:09PM -0700, Linda Walsh wrote:
If that's the case, then you only need those few modules for your machine. Now wouldn't it be possible to recompile a kernel and include those?
No user is ever going to be asked to rebuild any kernels, that's the point, sorry. Nor is it going to be automated.
If you wish to do something like this, feel free to, but for a general-purpose Linux distro, that way lies madness, trust me[1].
greg k-h
[1] I've helped develop/support/maintain 6 different Linux distros now, it's as if we actually know what we are doing... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Greetings (mit freundlichen Grüßen), Brian. Dr. Brian O'Mahoney Email: omb@teraflex.ch Phone: +44 (0) 7711 489965 GPG Key ID: E4A3BCF8 2009-12-11, old PGP Key Id: 0xA0481D676FBC700C -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
root wrote:
The sole problem is that mkinitrd re-makes ALL initrds by DEFAULT, and thus silently break existing boot combinations. Also mkinitrd's command line arguments, which let you linit this are un-intuitive and complex.
Isn't that just: mkinitrd -i <initrd> -k <kernel> ? -- Per Jessen, Zürich (13.7°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
Am Sat, 29 Jun 2013 13:48:46 +0200, scheib Per Jessen:
root wrote:
That is fine Per, if you "know" what kernel you are building, which system installs usually don't, it is in a makefile somewhere in an RPM, so yes your suggestion is ok, mkinitrd -b $opt_boot -i initrd-$tag -M System.map-$tag -k vmlinuz-$tag -v is what I use, just so I can use mkinitrd AS IS, but that is a workround to the basic BUG, mkinitrd should not disturb EXISTING initrds, just leave them alone, saves al problems with a simple call of mkinitrd hosing all kernels. I found this chasing down a non 86 arch bug that broke symlinks made by cpio, but mkinitrd clobbering slowed the debug loop X 5. See attachment mkKern
The sole problem is that mkinitrd re-makes ALL initrds by DEFAULT, and thus silently break existing boot combinations. Also mkinitrd's command line arguments, which let you linit this are un-intuitive and complex.
Isn't that just: mkinitrd -i <initrd> -k <kernel> ?
-- Per Jessen, Zürich (13.7°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
-- Greetings (mit freundlichen Grüßen), Brian. Dr. Brian O'Mahoney Email: omb@teraflex.ch Phone: +44 (0) 7711 489965 GPG Key ID: E4A3BCF8 2009-12-11, old PGP Key Id: 0xA0481D676FBC700C
В Fri, 28 Jun 2013 16:02:50 -0700 Greg KH <gregkh@linux.com> пишет:
On Sat, Jun 29, 2013 at 12:34:14AM +0200, Jan Engelhardt wrote:
On Friday 2013-06-28 21:56, Linda Walsh wrote:
# # /etc/mkinitcpio.conf #
MODULES="ahci sd_mod ext4" BINARIES="fsck fsck.ext4" HOOKS="base"
And that’s it. We don’t need udev, since anything in the MODULES variable will be explicitly loaded.
udev (or something like it) does not just load modules, it also creates the required device nodes.
No it doesn't, devtmpfs does that. udev sets the proper permissions on those device nodes, that's all.
Does kernel create /dev/disk/by-id/... ?
But the point that seems to escape some people on this thread, is that an initrd really is needed in order to be able to support the huge number of systems that the distro supports, so it isn't going away, sorry.
greg k-h
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Jun 29, 2013 at 06:37:51AM +0400, Andrey Borzenkov wrote:
В Fri, 28 Jun 2013 16:02:50 -0700 Greg KH <gregkh@linux.com> пишет:
On Sat, Jun 29, 2013 at 12:34:14AM +0200, Jan Engelhardt wrote:
On Friday 2013-06-28 21:56, Linda Walsh wrote:
# # /etc/mkinitcpio.conf #
MODULES="ahci sd_mod ext4" BINARIES="fsck fsck.ext4" HOOKS="base"
And that’s it. We don’t need udev, since anything in the MODULES variable will be explicitly loaded.
udev (or something like it) does not just load modules, it also creates the required device nodes.
No it doesn't, devtmpfs does that. udev sets the proper permissions on those device nodes, that's all.
Does kernel create /dev/disk/by-id/... ?
Those aren't device nodes, are they :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2013-06-29 01:02, Greg KH wrote:
udev (or something like it) does not just load modules, it also creates the required device nodes.
No it doesn't, devtmpfs does that. udev sets the proper permissions on those device nodes, that's all.
And if you don't use devtmpfs, but just tmpfs? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Sep 14, 2013 at 07:11:49PM +0200, Jan Engelhardt wrote:
On Saturday 2013-06-29 01:02, Greg KH wrote:
udev (or something like it) does not just load modules, it also creates the required device nodes.
No it doesn't, devtmpfs does that. udev sets the proper permissions on those device nodes, that's all.
And if you don't use devtmpfs, but just tmpfs?
Try it and see :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Greg KH wrote:
On Sat, Sep 14, 2013 at 07:11:49PM +0200, Jan Engelhardt wrote:
On Saturday 2013-06-29 01:02, Greg KH wrote:
udev (or something like it) does not just load modules, it also creates the required device nodes. No it doesn't, devtmpfs does that. udev sets the proper permissions on those device nodes, that's all. And if you don't use devtmpfs, but just tmpfs?
Try it and see :)
Just a guess, but wouldn't it depend on whether an initrd was loaded and if that initrd image had device nodes? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Sep 14, 2013 at 09:19:46PM -0700, Linda Walsh wrote:
Greg KH wrote:
On Sat, Sep 14, 2013 at 07:11:49PM +0200, Jan Engelhardt wrote:
On Saturday 2013-06-29 01:02, Greg KH wrote:
udev (or something like it) does not just load modules, it also creates the required device nodes. No it doesn't, devtmpfs does that. udev sets the proper permissions on those device nodes, that's all. And if you don't use devtmpfs, but just tmpfs?
Try it and see :)
Just a guess, but wouldn't it depend on whether an initrd was loaded and if that initrd image had device nodes?
Try it and see. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (23)
-
1xx -
Andrey Borzenkov -
Arvin Schnell -
Bruno Friedmann -
Carlos E. R. -
Christian Boltz -
Claudio Freire -
Cristian Rodríguez -
Felix Miata -
Frederic Crozat -
Greg KH -
Hans Witvliet -
Jan Engelhardt -
Linda Walsh -
Ludwig Nussel -
Per Jessen -
Rajko -
Robert Munteanu -
Roman Bysh -
root -
Stefan Seyfried -
Stephan Kulow -
Yamaban