This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 27 Jul 2016 00:33, Maciej W. Rozycki wrote: > On Wed, 13 Jul 2016, Florian Weimer wrote: > > I assumed it was intended as a recovery tool if something is wrong with the > > DSO symbolic links, which is why I preserved it. On the other hand, in this > > day and age, systems will certainly not boot if simple binaries like ln cannot > > run, and the system administrator will not be able to log in, so such recovery > > actions appear rather unrealistic without the help of a rescue system. > > Why? > > E.g. booting Linux with `rw init=/bin/bash.static' has always worked for > me, with the root filesystem mounted r/w and ready for any recovery > actions, such as fixing up DSO symlinks. And I see no reason for it to > stop working even where an initial RAM disk is used, as an image of such a > RAM disk is always self-contained and not used beyond early (pre-init) > initialisation needed to pull the root and maybe console device drivers. > > Have I missed anything? > > This is to get the facts straight that is -- whether to keep or discard > `sln' is of course another matter. bash.static is just as much of a distro-specific convention. i haven't heard of this before, and Debian/Ubuntu/Gentoo don't have it. -mike
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |