Hello,
Many modern systems have their /etc/resolv.conf files autogenerated at
runtime with DHCP, PPP or so on. Thus, storing that file in /etc seems
no longer correct as that directory may be mounted read-only.
I'm attaching a net-dns/resolvconf-symlink ebuild which
replaces /etc/resolv.conf with
On Wed, 10 Aug 2011 11:55:19 +0200
Michał Górny wrote:
> Hello,
>
> Many modern systems have their /etc/resolv.conf files autogenerated at
> runtime with DHCP, PPP or so on. Thus, storing that file in /etc seems
> no longer correct as that directory may be mounted read-only.
Hi Michał!
While i
On Wed, 10 Aug 2011 13:37:30 +0300
Sergei Trofimovich wrote:
> On Wed, 10 Aug 2011 11:55:19 +0200
> Michał Górny wrote:
>
> > Hello,
> >
> > Many modern systems have their /etc/resolv.conf files autogenerated
> > at runtime with DHCP, PPP or so on. Thus, storing that file in /etc
> > seems no
> > > Many modern systems have their /etc/resolv.conf files autogenerated
> > > at runtime with DHCP, PPP or so on. Thus, storing that file in /etc
> > > seems no longer correct as that directory may be mounted read-only.
> >
> > While i don't disagree on that move i'm suspocious about the
> > who
On Wed, 10 Aug 2011 14:28:09 +0300
Sergei Trofimovich wrote:
> > > > Many modern systems have their /etc/resolv.conf files
> > > > autogenerated at runtime with DHCP, PPP or so on. Thus, storing
> > > > that file in /etc seems no longer correct as that directory may
> > > > be mounted read-only.
On Fri, Aug 05, 2011 at 12:46:04AM +, Robin H. Johnson wrote:
> The minimal initramfs would do the following.
>
> 1. Mount devtmpfs/sysfs/procfs as needed to access devices.
> 2. Mount real_root to /newroot
> 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab
> 4.1. If /newroot/etc/in
On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote:
> On Fri, Aug 05, 2011 at 12:46:04AM +, Robin H. Johnson wrote:
> > The minimal initramfs would do the following.
> >
> > 1. Mount devtmpfs/sysfs/procfs as needed to access devices.
> > 2. Mount real_root to /newroot
> > 3. Read /n
On Wed, Aug 10, 2011 at 01:32:12PM +0200, Michał Górny wrote:
> > > That one's udev specific? I guess it could be moved as well.
> >
> > It's a blkid(8) cache to mount stuff by uuid/label and guess FS.
> > Used at least by udev rules and stuff linked against libblkid
> > (fsck.*). Both can be trig
On Wed, Aug 10, 2011 at 4:06 PM, Robin H. Johnson wrote:
> On Wed, Aug 10, 2011 at 01:32:12PM +0200, Michał Górny wrote:
>> > > That one's udev specific? I guess it could be moved as well.
>> >
>> > It's a blkid(8) cache to mount stuff by uuid/label and guess FS.
>> > Used at least by udev rules a
On Wed, Aug 10, 2011 at 04:13:16PM -0400, Rich Freeman wrote:
> > It was historically in /etc because it got used to mount /var.
> > As an example, if you grab some RHEL systems on the default install,
> > every entry in the fstab is UUID=... rather than fixed devices. Not
> > having the cache the
On Wed, 10 Aug 2011 20:06:28 +
"Robin H. Johnson" wrote:
> On Wed, Aug 10, 2011 at 01:32:12PM +0200, Michał Górny wrote:
> > > > That one's udev specific? I guess it could be moved as well.
> > >
> > > It's a blkid(8) cache to mount stuff by uuid/label and guess FS.
> > > Used at least by ud
Robin H. Johnson wrote:
On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote:
I am concerned about /var being included in this because of the
potential of filling up the root partition.
Err, I don't follow. How does mounting /var fill up the root partition?
If you tak
On Wed, Aug 10, 2011 at 03:47:18PM -0500, Dale wrote:
> > On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote:
> >> I am concerned about /var being included in this because of the
> >> potential of filling up the root partition.
> > Err, I don't follow. How does mounting /var fill up the
On Wed, Aug 10, 2011 at 08:02:44PM +, Robin H. Johnson wrote:
> On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote:
> > I am concerned about /var being included in this because of the
> > potential of filling up the root partition.
> Err, I don't follow. How does mounting /var fill u
I've intermittently spent my last two days trying to figure out a
weird bug on Entropy dependency resolution algorithm (which is
actually just a simple topological sorting out of a digraph) due to an
user reporting me a problem occurring during app-office/libreoffice
pkg_setup phase. The problem is
Robin H. Johnson wrote:
On Wed, Aug 10, 2011 at 03:47:18PM -0500, Dale wrote:
On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote:
I am concerned about /var being included in this because of the
potential of filling up the root partition.
Err, I don't follow. Ho
On Wed, Aug 10, 2011 at 04:42:04PM -0500, Dale wrote:
> For the record, I think /usr should work on a separate partition as
> well.
You're entirely missing the point of this thread.
> One reason, I would like to use LVM on all but my / file system.
> This is something I been fiddling with for
On Wed, Aug 10, 2011 at 03:57:30PM -0500, William Hubbs wrote:
> Sorry, I should have been more clear here. Mounting /var doesn't fill up
> the root partition, but if you don't want to use the initramfs, this
> means that /var must also exist on the root partition, which can create
> more of a conc
Robin H. Johnson wrote:
The final solution in this thread:
TL;DR version: If your /usr is NOT on /, you MUST use an initramfs.
More detailed:
1. If you want /usr or /var on separate partitions (not LVM or anything
elsewhere userspace action is required to make the block devices
usable),
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10-08-2011 21:56, Robin H. Johnson wrote:
> On Wed, Aug 10, 2011 at 03:57:30PM -0500, William Hubbs wrote:
>> Sorry, I should have been more clear here. Mounting /var doesn't
>> fill up the root partition, but if you don't want to use the
>> initram
On 08/10/2011 02:14 PM, Fabio Erculiani wrote:
> The problem here is that Portage enforces the same rule by trying to
> schedule the PDEPEND "as soon as possible"
This behavior was introduced in order to solve bug 180045 [1].
We can accomplish similar results to the ASAP ("as soon as possible")
b
On Wednesday, August 10, 2011 05:55:19 Michał Górny wrote:
> I'm attaching a net-dns/resolvconf-symlink ebuild which
> replaces /etc/resolv.conf with a symlink to a runtime-writable location
> when installed. That package could be added to PDEPEND of packages like
> net-misc/networkmanager or net-d
On Sunday, August 07, 2011 19:21:15 Mike Frysinger wrote:
> now that yacc is no longer part of system, and we have multiple providers
> of yacc, we need a virtual. so unless there are any complaints, i'll be
> adding virtual/yacc which has "|| ( sys-devel/bison dev-util/yacc )".
implemented and a
On Sunday, August 07, 2011 23:32:09 Matt Turner wrote:
> On Sun, Aug 7, 2011 at 11:21 PM, Mike Frysinger wrote:
> > now that yacc is no longer part of system, and we have multiple providers
> > of yacc, we need a virtual. so unless there are any complaints, i'll be
> > adding virtual/yacc which h
On Thu, Aug 11, 2011 at 1:31 AM, Zac Medico wrote:
> On 08/10/2011 02:14 PM, Fabio Erculiani wrote:
>> The problem here is that Portage enforces the same rule by trying to
>> schedule the PDEPEND "as soon as possible"
>
> This behavior was introduced in order to solve bug 180045 [1].
>
> We can ac
On Wed, 10 Aug 2011 23:14:22 +0200
Fabio Erculiani wrote:
> I've intermittently spent my last two days trying to figure out a
> weird bug on Entropy dependency resolution algorithm (which is
> actually just a simple topological sorting out of a digraph)
You can't use a naive topological sort to d
On 2011-08-11 12:56 AM, Robin H. Johnson wrote:
> The problem of filling up
> / is PEBKAC primarily, and can happen equally for / (think /root), /usr
> on /, /var on /.
This does not match with my experience. Over the years, I have seen
/var filling up several times on servers, but not /. Please
Rich Freeman wrote:
On Thu, Aug 4, 2011 at 7:49 AM, Dale wrote:
From a users perspective. Could it not be possible to have some USE flag,
or other setting, that would tell portage that a separate /usr partition is
being used then have the needed files placed elsewhere on / ? I'm not a de
On 08/10/2011 10:19 PM, Fabio Erculiani wrote:
> On Thu, Aug 11, 2011 at 1:31 AM, Zac Medico wrote:
>> On 08/10/2011 02:14 PM, Fabio Erculiani wrote:
>>> The problem here is that Portage enforces the same rule by trying to
>>> schedule the PDEPEND "as soon as possible"
>>
>> This behavior was intr
On Wed, 10 Aug 2011 23:31:01 -0700
Zac Medico wrote:
> The ASAP behavior seems relatively optimal
Unfortunately, what it *seems* and what it *is* are two entirely
different things, and the whole thing breaks down when post-dependent
packages have dependencies themselves. If ASAP were specified, y
Hello.
How is it possible that this dependency became mandatory tonight for
k3b? I don't think a handbook is a critical feature and k3b has been
working like a charm for two years without it.
Cheers.
--
Jesús Guerrero Botella
On Thu, Aug 11, 2011 at 7:36 AM, Ciaran McCreesh
wrote:
> On Wed, 10 Aug 2011 23:14:22 +0200
> Fabio Erculiani wrote:
>> I've intermittently spent my last two days trying to figure out a
>> weird bug on Entropy dependency resolution algorithm (which is
>> actually just a simple topological sortin
On Thu, Aug 11, 2011 at 8:31 AM, Zac Medico wrote:
>
> The ASAP behavior seems relatively optimal, which makes it difficult to
> argue that ebuild maintainers should have to go to the trouble of
> creating virtuals and updating reverse dependencies.
Yes it is and I agree, but the point here is th
33 matches
Mail list logo
