Re: [gentoo-user] Bootloaders: SILENT CRISIS!!!

[Michael Morak]

On 26 January 2017 at 18:03, Alan Grimes  wrote:

> I looked for more information on GRUB form upstream but, on first
> impression, it's been an abandoned project since 2012... Apparently some
> users have posted patches to things like the invalid sector size problem
> but the project has been deaf to these problems and has done nothing
> whatsoever. =(
>

The official repository for grub shows regular activity (last commit was 2
days ago), see here: http://git.savannah.gnu.org/cgit/grub.git/log/


> *snip
>
> I don't know where Gentoo is getting it's source for Grub...
>

You can find this info by looking in the relevant ebuilds. Gentoo is
getting it's grub source from the official GNU grub repository: http://git.
savannah.gnu.org/r/grub.git


> Apparently the git version of Grub was abandoned in 2015, as far as I
> can tell...


See above.


> I'm trying to build it from source. As is appropriate the
> git repository doesn't have the git scripts, I tried running autoreconf
> on it but got error messages...
>
> I cleared a few of them but I'm like:
>
> ##
> atg@localhost ~/source/grub $ autoreconf
> autoreconf-2.69: configure.ac: AM_GNU_GETTEXT is used, but not
> AM_GNU_GETTEXT_VERSION
> automake-1.15: error: cannot open < Makefile.util.am: No such file or
> directory
> autoreconf-2.69: automake failed with exit status: 1
> atg@localhost ~/source/grub $
> ##
>
> Is there a way to ebuild a "grub-git" and produce a grub install with
> version = date of most recent commit on active fork?
>

If you'd like to build the most recent version directly from the git
repository you could emerge "=grub-" (portage will do everything for
you, that is, it pulls the sources directly from the master branch and
builds from them). Otherwise, clone the sources yourself and, instead of
autoreconf, run the provided autogen.sh script, which is what you should
generally do for autotools-projects instead of running autoconf yourself.

Hope this helps,
Michael

Re: [gentoo-user] ro /

[Michael Morak]

On 13 January 2017 at 23:04, Jorge Almeida  wrote:
>
> process foobard requires a library foo.so. foobard was started when /
> was ro. Then / is mounted rw and a new version of foo.so is installed.
> Of course, foobard still uses foo.so (old). What prevents / to be
> remounted ro? foo.so (new) is already on disk, foo.so (old) is still
> being used, kept in RAM (I assume...)
>

Almost, but not quite. The problem is that the POSIX standard requires that
any file *must* continue to exist until all file handles pointing to it are
closed. Thus, using your example, when file foo.so gets replaced, the new
foo.so is written to the disk somewhere, but, since foobard holds an open
file handle, the old file is not deleted from the disk yet. At that point,
the content of *both* files (and relevant inodes, etc.) exists on the
*disk*, and, in addition, there is a pending delete operation for the old
file (that is, a "write" operation to /). This prevents / from being
mounted ro, since the pending write must be executed first (hence the
message "/ is busy").

One reason for this behaviour is that foobard may duplicate its file
handle, pass it to some other process, and that process must then still be
able to read the file (from disk, that is, since it doesn't share memory
with the foobard process). This generally doesn't happen for library files,
but this is just how the system behaves for *any* file with an open handle.

But apart from these technical details, usually when you update a library,
you want all programs relying on it to start using the new version. So a
restart would be required anyways. As Dale just wrote while I was typing
this, the needrestart and checkrestart scripts basically check for all
processes that have open handles for files which have a pending delete
operation and output a list for you. The needrestart script can also try to
automatically restart them for you.

Hope this helps,
Michael

Re: [gentoo-user] ro /

[Michael Morak]

Hi,

I have a similar setup. The problem is that some of your services may still
have open handles on files that no longer exist after updating (i.e. the
service, when originally started, opened an .so library file that it needs
to run, but the file then gets deleted or replaced during the emerge -u).
Simply restart all services (and other running programs) that have locks on
files that were updated.

The reason those files do not show up in your lsof command is that they may
not be open for writing but only for reading. A read lock on a file may
still give you the "/ is busy" message, since the open-for-read file cannot
be (fully) deleted while a running application still has a lock on it. You
have to get the process to release the read lock on the file (which, for
libraries, is usually done by a restart).

Hope this helps.

Cheers,
Michael

On 11 January 2017 at 22:54, Jorge Almeida  wrote:

> I have my / partition mounted read-only. It works fine, /var is in a
> different partition, as well as /usr/portage. Of course, I have to
> remount / rw when emerging packages.
>
> The problem is that, more often than not, I cannot remount ro after
> emerging ("/ is busy").
> I tried "lsof / | awk '$4 ~ /[0-9].*w/'" and the only files that are
> open for writing are FIFOs, which are associated with services I put
> there myself and should be there ( and were there before emerging,
> anyway...) IOW, no file is unexpectedely open for writing in /.
>
> I suspect something related with updated libraries (old versions kept?).
> I tried logging out. The problem persists after logging in in a getty,
> with no X process active.
>
> I'm updating the system  with
> emerge -NDu world
>
> and then
> emerge @preserved-rebuild
>
> Maybe I'm missing something obvious re updating?
>
> Ideas, similar experiences?
>
> Thanks
>
> Jorge Almeida
>
>