Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
fastest boot
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
simon_irl
Guru
Guru


Joined: 07 Oct 2004
Posts: 403
Location: New Zealand

PostPosted: Sat Apr 20, 2013 11:33 am    Post subject: fastest boot Reply with quote

what is the fastest way to boot the linux kernel that can be achieved on a normal desktop or laptop without ridiculous efforts (e.g. writing your own boot loader in assembler)? i have no need for a boot *manager* like grub or lilo...they are a complete waste of time to me because i'm booting gentoo and nothing else, and if i screw up my kernel or whatever i can just boot from usb. if we have no choice but to use a boot manager i'm still interested to know which is fastest (out of grub2, grub legacy, lilo, syslinux and whatever else is out there); but ideally i'd like to dd something into the mbr that simply pointed the bios straight at /boot/vmlinuz on the first partition and fired it up, no messing around. i understand that it's probably not that simple (i imagine even identifying the first partition and reading vmlinuz from the filesystem may require a fair amount of code), but how simple can we get it? what's the leanest, fastest way to boot my gentoo?
Back to top
View user's profile Send private message
i92guboj
Moderator
Moderator


Joined: 30 Nov 2004
Posts: 10127
Location: Córdoba (Spain)

PostPosted: Sat Apr 20, 2013 2:40 pm    Post subject: Reply with quote

The fastest you can get in the pc world is coreboot/linuxbios.
_________________
Gentoo Handbook | My website
Back to top
View user's profile Send private message
Logicien
l33t
l33t


Joined: 16 Sep 2005
Posts: 856
Location: Montréal

PostPosted: Sat Apr 20, 2013 4:16 pm    Post subject: Reply with quote

An EFI bootloader can boot the Linux kernel as an EFI Stub without any other bootloader. With no delay to execute the default entry, a Linux bootloader like Grub or Lilo is fast to load the kernel.
_________________
Paul
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2592
Location: UK

PostPosted: Sat Apr 20, 2013 6:22 pm    Post subject: Re: fastest boot Reply with quote

simon_irl wrote:
but ideally i'd like to dd something into the mbr that simply pointed the bios straight at /boot/vmlinuz on the first partition and fired it up, no messing around.

That's exactly what LILO is doing when you set it to zero delay, apart from maybe one or two x86 instructions to check the keyboard interrupt and branch to the menu code. It sounds like you have a large misunderstanding of how it actually works...
Back to top
View user's profile Send private message
simon_irl
Guru
Guru


Joined: 07 Oct 2004
Posts: 403
Location: New Zealand

PostPosted: Sat Apr 20, 2013 9:17 pm    Post subject: Reply with quote

thanks ant p, i think you've answered my question: it seems you're saying that LILO with a zero delay is in fact the fastest way to load linux on a normal box, and although you haven't spelled it out, i'm assuming from the "large misunderstanding" comment that you're telling me that boot loaders are already extremely efficient, and their parsing configuration files and checking for keyboard interrupts doesn't delay the boot process by any more than a few microseconds at most, so that in fact there is nothing worthwhile to be gained by replacing the likes of GRUB or LILO with even leaner code that skips the parsing of configuration files and the checking for keyboard interrupts and the drawing "LILO" or "GRUB" on the screen, because all that stuff takes place so quickly that the "delay" it introduces to the boot process is effectively zero, in terms of what a human being can observe...is that right? in which case, it's not only LILO that does exactly what i'm asking about except for a couple of x86 instructions, but also GRUB, GRUB2 syslinux/extlinux and any others...these boot loaders are all already as fast as it's possible to be, so it makes no difference to boot speed which one we choose?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32456
Location: 56N 3W

PostPosted: Sat Apr 20, 2013 9:53 pm    Post subject: Reply with quote

simon_irl,

Correct. Loading the boot loader, the kernel and the initrd, if you use one is limited by the speed at which you can get the data off the HDD.
A SSD helps here. This is not a boot bottleneck, so don't waste time trying to improve it.

As i92guboj says, coreboot/linuxbios is the way to go here. The kernel can go in the BIOS ROM and boot times from power on to kernel running can be as low as 500ms.
Of course, this isn't booting the system ... its the kernel reading the root filesystem.

Do you really want to flash your BIOS to update the kernel?
Do you want to risk bricking your motherboard by flashing the BIOS with an unbootable kernel?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
simon_irl
Guru
Guru


Joined: 07 Oct 2004
Posts: 403
Location: New Zealand

PostPosted: Sun Apr 21, 2013 4:24 am    Post subject: Reply with quote

NeddySeagoon wrote:
Do you really want to flash your BIOS to update the kernel?
Do you want to risk bricking your motherboard by flashing the BIOS with an unbootable kernel?

no, not really

NeddySeagoon wrote:
Loading the boot loader, the kernel and the initrd, if you use one is limited by the speed at which you can get the data off the HDD.
A SSD helps here. This is not a boot bottleneck, so don't waste time trying to improve it

thanks :)
Back to top
View user's profile Send private message
i92guboj
Moderator
Moderator


Joined: 30 Nov 2004
Posts: 10127
Location: Córdoba (Spain)

PostPosted: Sun Apr 21, 2013 10:27 am    Post subject: Reply with quote

But, we knew that bootloaders are fast, didn't we?

If you want something faster you gotta go before the bootloader. Oh, and you needn't brick anything. Just pick a similar chip from a similar board, and save the original as a abckup
_________________
Gentoo Handbook | My website
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3042
Location: The Peanut Gallery

PostPosted: Sun Apr 21, 2013 5:40 pm    Post subject: Reply with quote

I changed my /bin/sh symlink to point to /bin/bb after I'd used it when setting up mutt and played with it in make. For the latter especially it made a big difference, so I thought I'd see what broke; more during normal usage than bootup, which didn't concern me and has never been something I worry about.

Glad to say, everything works fine :) I had a couple of warnings from initscripts, tho the system still worked, but they were easily patched to detect busybox and not use GNU-specific options (and I did tell a couple of openrc developers which scripts needed work; afaik one of them is playing with bb now himself.)

Boot time is amazing :) I used to get time to read all the console messages from services, and it was a noticeable length of time; now I glance away, and it's all over.

Plus the rest of my system is quicker as well.

By simply replacing one component, which I can do since it's the basis of Unix, I get across-the-board improvements.

Makes me laugh at the dead-end systemd One True Way of forgetting about the elegance of Unix since it's "traditional" == "bad".
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2592
Location: UK

PostPosted: Sun Apr 21, 2013 5:46 pm    Post subject: Reply with quote

You might get another slight speedup by passing the "quiet" flag on the kernel command line so that it doesn't print those messages at all - the built-in framebuffer console is painfully slow.
Back to top
View user's profile Send private message
simon_irl
Guru
Guru


Joined: 07 Oct 2004
Posts: 403
Location: New Zealand

PostPosted: Mon Apr 22, 2013 11:57 am    Post subject: Reply with quote

steveL: thanks...that's a great idea.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4349

PostPosted: Mon Apr 22, 2013 1:38 pm    Post subject: Reply with quote

steveL wrote:
I changed my /bin/sh symlink to point to /bin/bb

With dash this works nicely, but with bb I always got a lot of problems (and still get, I just tried) with openrc: In particular, start-stop-daemon breaks which means that no background service is started as it should. I didn't look at the issue in detail, though. However, there are so many other warnings/errors/problems that I gave up rather soon. Probably emerge of many packages will fail, too, due to ./configure or make scripts relying on GNU features (in theory, this shouldn't be the case, but in practice I would expect a bulk of problems).
Quote:
By simply replacing one component

Using bb you actually replace much more than only the shell component, namely all the tools which are now built-in are changed, too.
Back to top
View user's profile Send private message
i92guboj
Moderator
Moderator


Joined: 30 Nov 2004
Posts: 10127
Location: Córdoba (Spain)

PostPosted: Mon Apr 22, 2013 6:07 pm    Post subject: Reply with quote

In fact, changing the shell is not as trivial. Well, the step of changing it is trivial (just a symlink, you know...) but what it implies is far from being trivial, much less in Gentoo, where the package manager will depend on that...

As said above, it's just not the shell, but a whole lot of tools.

I am all for the fun of it, but just remember that you gotta keep the pieces when the thing breaks.

Besides that, we even have a gentoo way to do this (stupid, if you ask me, but hey!), it's called eselect-sh ;)
_________________
Gentoo Handbook | My website
Back to top
View user's profile Send private message
_______0
Guru
Guru


Joined: 15 Oct 2012
Posts: 521

PostPosted: Sat May 04, 2013 5:44 pm    Post subject: Reply with quote

SSD+ EFI stub + minor tweaks in openrc and other things afterward.

Some other things that could help:

prelink
readahead
/var and /tmp in ram.

By the way, could you post some results of your implementation?
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2344

PostPosted: Sun May 05, 2013 4:54 am    Post subject: Reply with quote

mv wrote:
With dash this works nicely, but with bb I always got a lot of problems (and still get, I just tried) with openrc:

mv, steveL ... I had the same experience with bb, even after removing some bashisms from the rcscripts, and have since been using dash as /bin/sh without issues.

mv wrote:
In particular, start-stop-daemon breaks which means that no background service is started as it should. I didn't look at the issue in detail, though. However, there are so many other warnings/errors/problems that I gave up rather soon.

At the time I'd thought it was more an issue with the rcscripts as the failures seemed to be specific services rather than openrc itself, I even filed some bugs, but ended up abandoning bb in favour of dash.

mv wrote:
Probably emerge of many packages will fail, too, due to ./configure or make scripts relying on GNU features (in theory, this shouldn't be the case, but in practice I would expect a bulk of problems).

"First off, I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture." Linus, Documentation/CodingStyle.

i92guboj wrote:
In fact, changing the shell is not as trivial. Well, the step of changing it is trivial (just a symlink, you know...) but what it implies is far from being trivial, much less in Gentoo, where the package manager will depend on that...

i92guboj ... you'd think that if /bin/bash was required it'd use /bin/bash (which, as far as I know, and from the various components under /usr/lib/portage/bin, seems to be the case). Anything linked as /bin/sh should have no other requirement than it be posix-2008. In the case of linux, and its linking /bin/bash to /bin/sh, this has introduced all kinds non portable code, because what bash will accept as posix is not defined by the posix standard:

Code:
% /bin/bash --posix
bash-4.2$ if [[ -n $HOME ]] ; then echo "not portable" ; fi
not portable
bash-4.2$ echo -e "not portable"
not portable
bash-4.2$ echo {not,portable}
not portable
bash-4.2$ bar="not portable" ; declare -u bar="$bar" ; echo $bar
NOT PORTABLE
bash-4.2$ foo=1 ; let foo=${foo}+1 ; echo $foo
2

This is all contrary to the claim that "[b]ash can be configured to be POSIX-conformant by default" and "--posix ... [c]hange the behavior of bash where the default operation differs from the POSIX standard to match the standard" (man bash). The problem is not that whatever is linked to /bin/sh can't be depended on but that bash has broken it, as now it is expected that /bin/sh will accept any bashism thrown at it.

This illustrates the adage, "Q. why is bash the default shell on linux? .. A. because bash is the default shell on linux".

best ... khay
Back to top
View user's profile Send private message
i92guboj
Moderator
Moderator


Joined: 30 Nov 2004
Posts: 10127
Location: Córdoba (Spain)

PostPosted: Sun May 05, 2013 7:27 am    Post subject: Reply with quote

khayyam wrote:

i92guboj wrote:
In fact, changing the shell is not as trivial. Well, the step of changing it is trivial (just a symlink, you know...) but what it implies is far from being trivial, much less in Gentoo, where the package manager will depend on that...

i92guboj ... you'd think that if /bin/bash was required it'd use /bin/bash (which, as far as I know, and from the various components under /usr/lib/portage/bin, seems to be the case). Anything linked as /bin/sh should have no other requirement than it be posix-2008. In the case of linux, and its linking /bin/bash to /bin/sh, this has introduced all kinds non portable code, because what bash will accept as posix is not defined by the posix standard:

Code:
% /bin/bash --posix
bash-4.2$ if [[ -n $HOME ]] ; then echo "not portable" ; fi
not portable
bash-4.2$ echo -e "not portable"
not portable
bash-4.2$ echo {not,portable}
not portable
bash-4.2$ bar="not portable" ; declare -u bar="$bar" ; echo $bar
NOT PORTABLE
bash-4.2$ foo=1 ; let foo=${foo}+1 ; echo $foo
2

This is all contrary to the claim that "[b]ash can be configured to be POSIX-conformant by default" and "--posix ... [c]hange the behavior of bash where the default operation differs from the POSIX standard to match the standard" (man bash). The problem is not that whatever is linked to /bin/sh can't be depended on but that bash has broken it, as now it is expected that /bin/sh will accept any bashism thrown at it.

This illustrates the adage, "Q. why is bash the default shell on linux? .. A. because bash is the default shell on linux".

best ... khay


Yes, that's what we get in Linux. There's no simple way around this, but live with it.

After all, what's what defines a standard? Is a standard still a standard when 99.9% of the users are breaking it? Do that 0.1% of puritans that dislike bash have the reason?

I'd expect correct coding practices but we all know that the theory, while being so nice and clean, doesn't really much the reality half of the times. While everything is sorted out, if that happens someday, we need a working os with a working init system :)
_________________
Gentoo Handbook | My website
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2344

PostPosted: Sun May 05, 2013 9:19 am    Post subject: Reply with quote

i92guboj wrote:
Yes, that's what we get in Linux. There's no simple way around this, but live with it. After all, what's what defines a standard? Is a standard still a standard when 99.9% of the users are breaking it? Do that 0.1% of puritans that dislike bash have the reason?

i92guboj ... well, I wouldn't say posix is great, its not, but the idea that lead to it was: with the various unix like OSes out there some level of compatibility between them could be maintained. There had been enough fragmentation and everyone benefits when code written for one *nix variant could be run on another with little modification. This is doubly true for utilities and the like because the time spent learning a language, or what-have-you, was hard to recoup if it could no longer be used, or worked, when on a different host. This is not a question of "purity", its pragmatism, and its simply not fair play to wave the flag of "standards" and at the same time cross ones fingers behind ones back. Additionally, its not a 99 to 1 split, its something we agree to do in good faith so that our labours are more relevant and useful to others, and we've all benefited from this. Unfortunately, this idea has been scuppered in many respects because like the behemoths that were seen as acting with little regard but for their own preservation, the likes of FSF/GNU have done the very same when it suited them (mostly in order to seem relevant, and to assert themselves as political actors).

As for disliking bash, well, seriously, what it there to like ... but that's beside the point, if you want bash as your interactive shell, or as the chosen interpreter for your scripts, then fine, but there is no reason that bash should have been enthroned as /bin/sh when it wasn't up to the task. The only reason it was so enthroned is that it was GNU, and to allow any opening for something non-GNU would have been, non-GNUish. The result of all this is that all manor of things expect /bin/sh to be bash, and so it better had be .... so, not just a shell, like any other, a dependency.

i92guboj wrote:
I'd expect correct coding practices but we all know that the theory, while being so nice and clean, doesn't really much the reality half of the times. While everything is sorted out, if that happens someday, we need a working os with a working init system :)

But this is all after the fact ... it didn't just magically happen, nor was it the result of some pressing reality. OSes have "worked" without bash and will continue to do so, the fact that linux and bash are joined at the hip is more the result of politics than anything relating to practical reality.

best ... khay
Back to top
View user's profile Send private message
i92guboj
Moderator
Moderator


Joined: 30 Nov 2004
Posts: 10127
Location: Córdoba (Spain)

PostPosted: Sun May 05, 2013 9:34 am    Post subject: Reply with quote

Yes, I mostly agree. But there's much more in this than just politics.

As with everything having to do with any open source niche, zealotry plays a big big role in the discussions about shells, just like it does in the DEs debate, in the GNU vs GNU/Linux thing, in udev vs. the rest of the world, and in initA vs initB vs initC systems; and we could continue with a lot of other things...

Except that this one has been going on since linux started to exist, almost.

It is not that I don't like bash, I'd just rather say that I don't have any concrete or strong reason to hate it.

As sub-optimal, bloated, big, slow, or whatever adjective you prefer, it is, we can't deny that it works, and, if we have learned to live with glibc which is the behemoth of behemoths, then we can do just fine with a 600kb binary... it's not that much of a big deal, really. The fact that it's installed by default in all the distros is only convenient. I just don't have a reason to uninstall it and install some other shell for no real gain.

The fact that, at some point, we all learn bash and sh in the university or whatever learning course we choose contributes to that as well. Come on, a shell script is not a rocket-science asm ultraoptimized piece of machine code, whatever you do in zsh, ash, sh, dash or foobarmoocowsh can be done in bash as well.

There's a lot of room for improvement, the real question I am asking here is why would anyone cares?

Even when it comes to init systems, desktops are not relevant and laptops use hibernation nowadays... :roll:
_________________
Gentoo Handbook | My website
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2344

PostPosted: Sun May 05, 2013 1:29 pm    Post subject: Reply with quote

i92guboj wrote:
Yes, I mostly agree. But there's much more in this than just politics. As with everything having to do with any open source niche, zealotry plays a big big role in the discussions about shells, just like it does in the DEs debate, in the GNU vs GNU/Linux thing, in udev vs. the rest of the world, and in initA vs initB vs initC systems; and we could continue with a lot of other things...

i92guboj ... I'm not sure these are the same issues at all, its not a question of which is the best shell, its a question of why the shell which is set as the "posix" shell doesn't know the difference between its own extentions and the posix standard (even though it claims it can be "configured to be POSIX-conformant"). This is not entirely a problem with bash, there has been some level of fragmentation wraught by various players, but if your playing both "standards complient" and making it so that your standard is *the* standard then you might as well not bother with the standard at all ... and thats what makes it political, it then becomes simply about who gets to define what the standard is.

Also, I think its a mistake to frame these debates as entirely sectarian, sure people make all manor of decisions based on brand loyalty or what-have-you, but they also make pragmatic decisions based on necessity and usefulness. I'm personally prepared to make compromises for the sake of getting along, but I hope I can see clearly enough to percieve when such a compromise is leading to a dead end, or when the choices offered are being narrowed.

i92guboj wrote:
It is not that I don't like bash, I'd just rather say that I don't have any concrete or strong reason to hate it.

Again, I don't think this is the same issue, its not really about "hating bash", I don't particularly care what shell other choose to use, but such choices shouldn't have the knock-on effect that our respective usage can't converge. So, say, the standard of using "posix" as a guideline for rcscripts, or what-have-you, should benefit both of us, that this is circumvented by /bin/sh *having* to be bash is divergent from that goal. Its not a question of purging bash, but that if there are to be standards then there should be no crossing of fingers behind the back.

i92guboj wrote:
As sub-optimal, bloated, big, slow, or whatever adjective you prefer, it is, we can't deny that it works, and, if we have learned to live with glibc which is the behemoth of behemoths, then we can do just fine with a 600kb binary... it's not that much of a big deal, really. The fact that it's installed by default in all the distros is only convenient. I just don't have a reason to uninstall it and install some other shell for no real gain.

Its not that its installed, after all, there would be nothing to prevent you installing it if it wasn't, and its not that it needs to be replaced with some other shell ... these are entirely seperate questions.

i92guboj wrote:
The fact that, at some point, we all learn bash and sh in the university or whatever learning course we choose contributes to that as well. Come on, a shell script is not a rocket-science asm ultraoptimized piece of machine code, whatever you do in zsh, ash, sh, dash or foobarmoocowsh can be done in bash as well.

Not all shells are created equal as I'm sure any one whos used csh would agree, infact its well known that csh should be considerd harmful. If you use a shell on a regular basis then these things do matter, I can provide umpteen examples of zsh interactive usage which are short and succinct and which the equivelent in bash would be labourious (or infact not possible, or require the use of external commands) ... but no one is saying you should, or must, use zsh, nor is zsh a replacement for portable code. More to the point, the zsh manpage clearly states that its 'emulate sh' is not posix.

i92guboj wrote:
There's a lot of room for improvement, the real question I am asking here is why would anyone cares?

I've provided some of that reasoning above ... fragmentation, time investment, interoperability, standards, community, etc.

i92guboj wrote:
Even when it comes to init systems, desktops are not relevant and laptops use hibernation nowadays...

Its extreamly relevant. Your taking the ecosystem to consit of only linux, fragmentation between various OSes is a bad thing for all involved. Remember, numerious things we now take for granted, commands like 'ifconfig' for example, were all ported from BSD, and having a wider ecosystem within which such exchanges occur is neccessary for the ecosystem not to become a monoculture. Additionally, when something depends on X for it to function, everything requires X, Y is then not an option, so you have either a limiting of avalilable choice or fragmentation (forking, inoperability, etc). This serves no one except the vendors of X .... and vendors are in the business of narrowing your choices to their products.

best ... khay
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3042
Location: The Peanut Gallery

PostPosted: Sun May 05, 2013 2:07 pm    Post subject: Reply with quote

i92guboj wrote:
As sub-optimal, bloated, big, slow, or whatever adjective you prefer, it is, we can't deny that it works, and, if we have learned to live with glibc which is the behemoth of behemoths, then we can do just fine with a 600kb binary... it's not that much of a big deal, really. The fact that it's installed by default in all the distros is only convenient. I just don't have a reason to uninstall it and install some other shell for no real gain.

I'm not in favour of uninstalling bash. It's required for ebuilds, and additionally many scripts do require bash. I maintain and use one daily myself.

Quote:
The fact that, at some point, we all learn bash and sh in the university or whatever learning course we choose contributes to that as well. Come on, a shell script is not a rocket-science asm ultraoptimized piece of machine code, whatever you do in zsh, ash, sh, dash or foobarmoocowsh can be done in bash as well.

The problem is many "developers" who learnt it at university or in some course, or even worse from TLDP ABS, learn it badly. And they look down on shell, write it badly with not much idea of what they're doing, and don't really understand that actually there is a world of difference between POSIX sh and BASH. And yes, you can do everything in BASH that you can do in SH. That's not the point.
Quote:
There's a lot of room for improvement, the real question I am asking here is why would anyone cares?

The point is that if you stick to POSIX sh, with the addition of the 'local' keyword (iirc that's a requirement for a debian sh), then your scripts can be executed by something like busybox or mirsh with a great deal more efficiency. Exactly the "ultraoptimized" effect you were describing in fact.

Note that portability also has a lot to do with the commands and options you (don't) use. So really it's sticking to POSIX sh, and the utilities and options described in the POSIX standard. You can see the relevant documentation with: man 1p foo
In fact, #bash on IRC: chat.freenode.net is very good on portability of the commands and utils you use. They'll even help you write sh, if you tell them upfront that's what you're doing.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3042
Location: The Peanut Gallery

PostPosted: Sun May 05, 2013 2:18 pm    Post subject: Reply with quote

mv wrote:
steveL wrote:
I changed my /bin/sh symlink to point to /bin/bb

With dash this works nicely, but with bb I always got a lot of problems (and still get, I just tried) with openrc: In particular, start-stop-daemon breaks which means that no background service is started as it should. I didn't look at the issue in detail, though. However, there are so many other warnings/errors/problems that I gave up rather soon. Probably emerge of many packages will fail, too, due to ./configure or make scripts relying on GNU features (in theory, this shouldn't be the case, but in practice I would expect a bulk of problems).

No, emerges do not fail. I'm surprised that with your experience you should think autoconf would fail without sh as bash. The whole point of it is to generate scripts for the lowest common denominator sh.

Nothing fails at runtime here, though I did get an email from someone using mysql, which I don't use since I turned off semantic-craptop, who said he has a similar problem with ssd when he came into #openrc. We're going to look into it when he comes back. Perhaps I'm lucky and don't have anything which uses ssd.

Wrt to initscript issues, I've started a thread to discuss them. I had to patch 3 initscripts for warnings which did not cause boot failure; the patches for stable openrc-0.11.8 initscripts are in the bug, though the openrc developer wants to hold off on supporting busybox in openrc, until busybox code is extended to support openrc.
Quote:
Using bb you actually replace much more than only the shell component, namely all the tools which are now built-in are changed, too.

Yes, that's exactly why I like it. But even replacing it with dash, or ash-bb, is the same method: and only works because of the modular design inherent in Unix, and all *nix that implement POSIX sanely.
_________________
creaker wrote:
systemd. It is a really ass pain

update - "a most excellent portage wrapper"

#friendly-coders -- We're still here for you™ ;)
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3042
Location: The Peanut Gallery

PostPosted: Mon May 06, 2013 1:28 am    Post subject: Reply with quote

The start-stop-daemon thing has been tracked down: turns out it is builtin in busybox. Additionally openrc s-s-d is actually '/sbin/rc -a start-stop-daemon'. Combining the two factors, the best fix would be a simple alias at the top of runscript.sh, just after the copyright notice:
Code:
alias start-stop-daemon='/sbin/rc -a start-stop-daemon'

A version of this (taking prefix into account) will be in runscript.sh.in once WilliamH has checked it with the embedded people, but in the meantime that should fix any problem you might be having with the busybox s-s-d failing.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4349

PostPosted: Mon May 06, 2013 6:15 am    Post subject: Reply with quote

khayyam wrote:
commands like 'ifconfig' for example, were all ported from BSD

I am really not an expert in this, but Roy Marples complained that the BSD network commands are much superior and have much more functionality which is available in Linux only partly and even then only with iproute2.

This is really a serious problem: For the shell itself, one can live with POSIX, because most features of bash can just be rewritten into compatible POSIX if required (although still there, there are important exceptions like <(...)). However, for the tools it is a different thing. I just mention a few examples: readlink -f, stat, cp -rl, and the worst thing: find.
Emulating these in shell code would just be stupid (or in case of stat is not possible at all), and there is no POSIX substitute. I remember that I wanted to keep squash_dir compatible with POSIX and thus tested with bb - in the end, I had to hack up the script to use the external find even in bb, because there was not even closely a way of doing what I wanted with bb's find (I do not remember whether it was a POSIX features not provided by bb or whether it was not even POSIX - probably both problems occurred, but I would have to look up the details).


Last edited by mv on Mon May 06, 2013 6:28 am; edited 1 time in total
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4349

PostPosted: Mon May 06, 2013 6:26 am    Post subject: Reply with quote

steveL wrote:
mv wrote:
Probably emerge of many packages will fail, too, due to ./configure or make scripts relying on GNU features (in theory, this shouldn't be the case, but in practice I would expect a bulk of problems).

No, emerges do not fail. I'm surprised that with your experience you should think autoconf would fail without sh as bash. The whole point of it is to generate scripts for the lowest common denominator sh.

As I said: In theory, this shouldn't be the case. But in practice it is. It is not that I "think" there are build failures: I experienced them even when changing /bin/sh to dash. Here are some lines from my package.cflags (maybe some of these packages have been fixed in newer version, I haven't checked since quite a while):
/etc/portage/package.cflags/patches wrote:
app-text/u2ps "EXTRA_EMAKE+='SHELL=/bin/bash'"
media-gfx/gimp "EXTRA_EMAKE+='SHELL=/bin/bash'"
media-libs/libmikmod "EXTRA_EMAKE+='SHELL=/bin/bash'"
net-misc/nxserver-freenx "EXTRA_EMAKE+='SHELL=/bin/bash'"
x11-libs/gtk+ "EXTRA_EMAKE+='SHELL=/bin/bash'"

The problem is that while automake/autoconf itself is of course compatible, nobody prevents developers from using all sorts of bashisms in the code they add manually - they wouldn't realize on most systems since automake/autoconf defaults to SHELL=/bin/sh which is bash on most systems. Yes, these are bugs in the code, but if even just for bash->dash there are so many packages failing, I would expect even more problems with busybox, because then even all tools (find, install) have limited features very likely not expected by most developers.
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2344

PostPosted: Mon May 06, 2013 7:24 am    Post subject: Reply with quote

mv wrote:
khayyam wrote:
commands like 'ifconfig' for example, were all ported from BSD

I am really not an expert in this, but Roy Marples complained that the BSD network commands are much superior and have much more functionality which is available in Linux only partly and even then only with iproute2.

mv ... roy is correct, but its not just ifconfig's functionality, there is more emphasis on incorporating the often disparate features into one command, so ifconfig contains the switches spread between ip, iw, iwconfig, iwlist, etc, it also incorporates a 'debug' switch which enables/disables the drivers debugging. However, NETLINK and iproute2 has improved things and in some ways the approach is similar, ip incorporates ifconfig, route, arp, netstat (some functions at least), tunctl, etc.

Perhaps not supprising but net-tools has been without maintainership since 2001, its been languishing in backwardness for the entire time that linux was said to be conquering the internet.

So while the various BSD's haven't spead ahead with drivers for every possible dingle and dongle they have been able to focus on a tight userland (or base system) and there is a lot less discrepency bettween the various flavors if say comparing RH, Debian, Gentoo, etc.

best ... khay
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum