Compiling first and then installing using -K

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Compiling first and then installing using -K

Dale-46
Howdy,

I ran into a issue with qt upgrades and it got interesting.  Since it
was part way through, some applications that I needed wouldn't open due
to a mismatch in versions.  When I tried to logout and back in, sddm
wouldn't come up either, same reason I assume.  Now that I'm back, I'm
wanting to see if I can do upgrades by building the packages first and
then using the -K option.  Thing is, when I tried that just now for the
rest of this huge upgrade, I get this little message at the bottom.


!!! --buildpkgonly requires all dependencies to be merged.
!!! Cannot merge requested packages. Merge deps and try again.


So, I have to emerge packages in order to emerge others.  I get that
packages depend on each other but is there a way around that?  Would I
need to set up a chroot and build it there or is there a better way. 

Since it is the compiling that seems to cause issues generally, I'm
wanting to do that first and then it just install from the binary.  I
figure someone out there has found a good way to do this.  I just hope
someone is willing to share their good way to do this.  ;-)

Dale

:-)  :-) 

Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Nikos Chantziaras-2
On 17/02/2020 10:26, Dale wrote:
> I ran into a issue with qt upgrades and it got interesting.  Since it
> was part way through, some applications that I needed wouldn't open due
> to a mismatch in versions. [...]
>
> !!! --buildpkgonly requires all dependencies to be merged.
> !!! Cannot merge requested packages. Merge deps and try again.
>
> So, I have to emerge packages in order to emerge others.  I get that
> packages depend on each other but is there a way around that?
You'd need to maintain two gentoo installs (A and B) with the same exact
configuration with B serving as the build machine. Then you'd emerge the
packages in B, make binary packages out of every package, and then
emerge those in A.


Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Dale-46
Nikos Chantziaras wrote:

> On 17/02/2020 10:26, Dale wrote:
>> I ran into a issue with qt upgrades and it got interesting.  Since it
>> was part way through, some applications that I needed wouldn't open due
>> to a mismatch in versions. [...]
>>
>> !!! --buildpkgonly requires all dependencies to be merged.
>> !!! Cannot merge requested packages. Merge deps and try again.
>>
>> So, I have to emerge packages in order to emerge others.  I get that
>> packages depend on each other but is there a way around that?
> You'd need to maintain two gentoo installs (A and B) with the same
> exact configuration with B serving as the build machine. Then you'd
> emerge the packages in B, make binary packages out of every package,
> and then emerge those in A.
>
>
>


Would a chroot work for that?  I'm pretty sure it would but want to be
certain before I set all that up.  I'm pretty sure I can dig around and
find a hard drive somewhere. 

While at it, I wouldn't want grub or anything to pick it up.  Since grub
does so much automatically, would it "detect" that install or would it
ignore it? 

Thanks.

Dale

:-)  :-) 

Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Mark Knecht


On Mon, Feb 17, 2020 at 11:02 AM Dale <[hidden email]> wrote:
Nikos Chantziaras wrote:
> On 17/02/2020 10:26, Dale wrote:
>> I ran into a issue with qt upgrades and it got interesting.  Since it
>> was part way through, some applications that I needed wouldn't open due
>> to a mismatch in versions. [...]
>>
>> !!! --buildpkgonly requires all dependencies to be merged.
>> !!! Cannot merge requested packages. Merge deps and try again.
>>
>> So, I have to emerge packages in order to emerge others.  I get that
>> packages depend on each other but is there a way around that?
> You'd need to maintain two gentoo installs (A and B) with the same
> exact configuration with B serving as the build machine. Then you'd
> emerge the packages in B, make binary packages out of every package,
> and then emerge those in A.
>
>
>


Would a chroot work for that?  I'm pretty sure it would but want to be
certain before I set all that up.  I'm pretty sure I can dig around and
find a hard drive somewhere. 

While at it, I wouldn't want grub or anything to pick it up.  Since grub
does so much automatically, would it "detect" that install or would it
ignore it? 

Thanks.

Dale

Virtualbox should do it. Easy to maintain, easy to delete when your done. It will create a virtual disk using space on your current system so no requirement for a new drive. You can take images for backup if you ever decide you need that.

Gentoo is very happy in a VB VM.

Mark 
Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Nikos Chantziaras-2
In reply to this post by Dale-46
On 17/02/2020 20:01, Dale wrote:

> Nikos Chantziaras wrote:
>> On 17/02/2020 10:26, Dale wrote:
>>> I ran into a issue with qt upgrades and it got interesting.  Since it
>>> was part way through, some applications that I needed wouldn't open due
>>> to a mismatch in versions. [...]
>>>
>>> !!! --buildpkgonly requires all dependencies to be merged.
>>> !!! Cannot merge requested packages. Merge deps and try again.
>>>
>>> So, I have to emerge packages in order to emerge others.  I get that
>>> packages depend on each other but is there a way around that?
>> You'd need to maintain two gentoo installs (A and B) with the same
>> exact configuration with B serving as the build machine. Then you'd
>> emerge the packages in B, make binary packages out of every package,
>> and then emerge those in A.
>
>
> Would a chroot work for that?  I'm pretty sure it would but want to be
> certain before I set all that up.  I'm pretty sure I can dig around and
> find a hard drive somewhere.

Sure. Although it might be easier to use a container instead (like LXD
or Docker.)

Grub has nothing to do with it. You wouldn't actually run grub in the
container or chroot. You'd only install the grub package.

A VM like Mark suggested would probably be even easier to set up.
Although getting to the packages would be more complicated and it would
also be slower (and with the recent meltdown/spectre mitigation stuff,
probably much slower.) A chroot or container on the other hand is
extremely lightweight. There's no virtualization involved (or very
little of it), so it should be pretty much as fast as a native system.


Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Rich Freeman
On Mon, Feb 17, 2020 at 1:21 PM Nikos Chantziaras <[hidden email]> wrote:
>
> probably much slower.) A chroot or container on the other hand is
> extremely lightweight. There's no virtualization involved (or very
> little of it), so it should be pretty much as fast as a native system.

Chroots and containers are exactly as fast as the native system, and
don't involve any virtualization.

In fact, on linux you can't NOT run a process in a chroot or
container.  Every process has a root directory and a set of namespaces
applied to it, including init, and every new process just inherits the
settings of the process that execed it.  All linux users are
essentially using at least one container.  As such, running more than
one container doesn't involve any kernel behavior that running a
single container doesn't involve.

Now, it is true that if you're running multiple containers you're more
likely to have multiple copies of glibc and so on in RAM, and thus
there is a memory overhead, though that applies system-wide, and not
just to the processes running inside the additional containers.  Maybe
the one bit of overhead is the first time you launch a particular
process in a particular container any shared libraries it uses will
have to be loaded into RAM, while on the host there is a decent chance
that some of them are already in RAM.  We're really splitting hairs at
this point, however.

I wouldn't use a chroot for anything at this point - anything you can
do with one you can do just as easily with a container, with more
separation.  They're just as easy to set up as well - I personally use
nspawn to run my containers but I'm sure lxc is almost as simple and
of course it doesn't require running systemd.

Getting back to the original topic - you can just build binary
packages for stuff like qt without using a container, but if you do so
you won't be able to build more than one layer of dependencies.  It
still cuts down on the merge time considerably, but obviously not as
much as it does if you build everything ahead of time.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Nikos Chantziaras-2
On 17/02/2020 21:05, Rich Freeman wrote:
> I wouldn't use a chroot for anything at this point - anything you can
> do with one you can do just as easily with a container, with more
> separation.  They're just as easy to set up as well - I personally use
> nspawn to run my containers but I'm sure lxc is almost as simple and
> of course it doesn't require running systemd.

nspawn seems very nice indeed. Haven't used it before, and that's simply
because I never heard of it :-) Now that I did, it looks like it's what
I'll be using from now on:

https://wiki.archlinux.org/index.php/Systemd-nspawn


> Getting back to the original topic - you can just build binary
> packages for stuff like qt without using a container, but if you do so
> you won't be able to build more than one layer of dependencies.

Unfortunately, Qt depends on itself (qtgui depends on qtbase, for
example,) so you can't even do that.


Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Rich Freeman
On Mon, Feb 17, 2020 at 2:24 PM Nikos Chantziaras <[hidden email]> wrote:

>
> On 17/02/2020 21:05, Rich Freeman wrote:
> > I wouldn't use a chroot for anything at this point - anything you can
> > do with one you can do just as easily with a container, with more
> > separation.  They're just as easy to set up as well - I personally use
> > nspawn to run my containers but I'm sure lxc is almost as simple and
> > of course it doesn't require running systemd.
>
> nspawn seems very nice indeed. Haven't used it before, and that's simply
> because I never heard of it :-) Now that I did, it looks like it's what
> I'll be using from now on:
>
> https://wiki.archlinux.org/index.php/Systemd-nspawn

Well, if you decide to play with it I'll offer up:
https://rich0gentoo.wordpress.com/2014/07/14/quick-systemd-nspawn-guide/

That, and:
ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot
--link-journal=guest --directory=/path/to/container/root
--network-bridge=<brname>
KillMode=mixed
Type=notify

Though, if I didn't already have this recipe handy I'd be using nspawn
units I suppose.  Oh, this does require a bridge for your networking.
If you're using KVM you probably already have one set up - the
approach is identical.

Rich

Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Nikos Chantziaras-2
On 17/02/2020 21:46, Rich Freeman wrote:
>
> Well, if you decide to play with it I'll offer up:
> https://rich0gentoo.wordpress.com/2014/07/14/quick-systemd-nspawn-guide/

Hm. I'm too chicken to try it because I'm not sure it does what I think
it does, but does the "--ephemeral" option pretty much do *exactly* what
Dale was asking about? Can you start your current "/" as a container
as-is, emerge packages in it and save them as binaries, then install
those from the outside, then shutdown the container and all is forgotten?


Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Rich Freeman
On Mon, Feb 17, 2020 at 6:00 PM Nikos Chantziaras <[hidden email]> wrote:

>
> On 17/02/2020 21:46, Rich Freeman wrote:
> >
> > Well, if you decide to play with it I'll offer up:
> > https://rich0gentoo.wordpress.com/2014/07/14/quick-systemd-nspawn-guide/
>
> Hm. I'm too chicken to try it because I'm not sure it does what I think
> it does, but does the "--ephemeral" option pretty much do *exactly* what
> Dale was asking about? Can you start your current "/" as a container
> as-is, emerge packages in it and save them as binaries, then install
> those from the outside, then shutdown the container and all is forgotten?

You know, I think that might actually work.

Note that it depends on reflinks or snapshots for efficient operation,
and I'm not sure what the full list of supported filesystems are.
They do mention btrfs.  I'm not sure if zfs is supported (zfs supports
snapshots but clones would be needed here and those have some
limitations, and zfs does not support reflinks).

You'd obviously have to bind-mount your binary package directory - I
think you could do that even using the same root as this would enable
writes to that one path to escape the mount namespace and get into
your host filesystem.

Obvious way to test this would be to just set up a VM.  It has the
obvious advantage of always being in-sync with your host config.

I think I might actually try playing around with this.  I'm on zfs
though so I'm not sure how it will perform.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Nikos Chantziaras-2
On 18/02/2020 01:21, Rich Freeman wrote:

> On Mon, Feb 17, 2020 at 6:00 PM Nikos Chantziaras <[hidden email]> wrote:
>> Hm. I'm too chicken to try it because I'm not sure it does what I think
>> it does, but does the "--ephemeral" option pretty much do *exactly* what
>> Dale was asking about? Can you start your current "/" as a container
>> as-is, emerge packages in it and save them as binaries, then install
>> those from the outside, then shutdown the container and all is forgotten?
>
> Obvious way to test this would be to just set up a VM.  It has the
> obvious advantage of always being in-sync with your host config.
>
> I think I might actually try playing around with this.  I'm on zfs
> though so I'm not sure how it will perform.

I just tested it in a throw-away Ubuntu VM running on ext4. It crashed
and burned due to disk space. It tried to duplicate the whole "/" with
zero error checks. So free space reached 0 but it still didn't abort. I
had to abort with ctrl+c. Free space was then 200MB (out of 20GB). I did
"du -sh /*" to find where all the GBs went, but it doesn't find it.

So... yeah. Not very convincing implementation. Don't try it at home,
kids :-P


Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Rich Freeman
On Mon, Feb 17, 2020 at 6:31 PM Nikos Chantziaras <[hidden email]> wrote:

>
> On 18/02/2020 01:21, Rich Freeman wrote:
> > On Mon, Feb 17, 2020 at 6:00 PM Nikos Chantziaras <[hidden email]> wrote:
> >> Hm. I'm too chicken to try it because I'm not sure it does what I think
> >> it does, but does the "--ephemeral" option pretty much do *exactly* what
> >> Dale was asking about? Can you start your current "/" as a container
> >> as-is, emerge packages in it and save them as binaries, then install
> >> those from the outside, then shutdown the container and all is forgotten?
> >
> > Obvious way to test this would be to just set up a VM.  It has the
> > obvious advantage of always being in-sync with your host config.
> >
> > I think I might actually try playing around with this.  I'm on zfs
> > though so I'm not sure how it will perform.
>
> I just tested it in a throw-away Ubuntu VM running on ext4. It crashed
> and burned due to disk space. It tried to duplicate the whole "/" with
> zero error checks. So free space reached 0 but it still didn't abort. I
> had to abort with ctrl+c. Free space was then 200MB (out of 20GB). I did
> "du -sh /*" to find where all the GBs went, but it doesn't find it.
>

Hmm, if it just resorted to doing a cp it might have tried to copy the
copy, or if it was really brain-dead it might not have limited itself
to the root filesystem.  Granted, the necessary files might not all be
on one filesystem to begin with, but it would obviously have to avoid
copying /proc and so on.  I mean, it might have trouble with:
-r-------- 1 root root 128T Feb 11 14:31 /proc/kcore

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Mark Knecht
In reply to this post by Nikos Chantziaras-2


On Mon, Feb 17, 2020 at 4:32 PM Nikos Chantziaras <[hidden email]> wrote:

>
> On 18/02/2020 01:21, Rich Freeman wrote:
> > On Mon, Feb 17, 2020 at 6:00 PM Nikos Chantziaras <[hidden email]> wrote:
> >> Hm. I'm too chicken to try it because I'm not sure it does what I think
> >> it does, but does the "--ephemeral" option pretty much do *exactly* what
> >> Dale was asking about? Can you start your current "/" as a container
> >> as-is, emerge packages in it and save them as binaries, then install
> >> those from the outside, then shutdown the container and all is forgotten?
> >
> > Obvious way to test this would be to just set up a VM.  It has the
> > obvious advantage of always being in-sync with your host config.
> >
> > I think I might actually try playing around with this.  I'm on zfs
> > though so I'm not sure how it will perform.
>
> I just tested it in a throw-away Ubuntu VM running on ext4. It crashed
> and burned due to disk space. It tried to duplicate the whole "/" with
> zero error checks. So free space reached 0 but it still didn't abort. I
> had to abort with ctrl+c. Free space was then 200MB (out of 20GB). I did
> "du -sh /*" to find where all the GBs went, but it doesn't find it.
>
> So... yeah. Not very convincing implementation. Don't try it at home,
> kids :-P
>

Ouch!
Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Nikos Chantziaras-2
On 18/02/2020 02:01, Mark Knecht wrote:

>
> On Mon, Feb 17, 2020 at 4:32 PM Nikos Chantziaras <[hidden email]
>  > I just tested it in a throw-away Ubuntu VM running on ext4. It crashed
>  > and burned due to disk space. It tried to duplicate the whole "/" with
>  > zero error checks. So free space reached 0 but it still didn't abort. I
>  > had to abort with ctrl+c. Free space was then 200MB (out of 20GB). I did
>  > "du -sh /*" to find where all the GBs went, but it doesn't find it.
>  >
>  > So... yeah. Not very convincing implementation. Don't try it at home,
>  > kids :-P
>
> Ouch!

It gets worse. The container reconfigured the keyboard shortcuts on the
host! After booting a container, alt+Fn or alt+left/right on the host
started switching to the linux text-mode console. I pressed alt+f2 to
bring up the plasma search, I ended up on TTY2... ha ha.

Remember how I said I'll use nspawn from now on? I take that back. Let's
just say this thing is not even remotely production ready.


Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Rich Freeman
On Tue, Feb 18, 2020 at 2:06 PM Nikos Chantziaras <[hidden email]> wrote:
>
> It gets worse. The container reconfigured the keyboard shortcuts on the
> host! After booting a container, alt+Fn or alt+left/right on the host
> started switching to the linux text-mode console. I pressed alt+f2 to
> bring up the plasma search, I ended up on TTY2... ha ha.
>
> Remember how I said I'll use nspawn from now on? I take that back. Let's
> just say this thing is not even remotely production ready.

Never had any issues with it, but I've never tried to use my host root
as the input filesystem.  I suspect the issue is that this is giving
the container access to the host /dev, /sys and so on, and thus the
container isn't ending up being contained.  Normally you don't go
mounting a host /dev inside a container image before launching it...

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Michael Jones
On Tue, Feb 18, 2020 at 1:22 PM Rich Freeman <[hidden email]> wrote:
On Tue, Feb 18, 2020 at 2:06 PM Nikos Chantziaras <[hidden email]> wrote:
>
> It gets worse. The container reconfigured the keyboard shortcuts on the
> host! After booting a container, alt+Fn or alt+left/right on the host
> started switching to the linux text-mode console. I pressed alt+f2 to
> bring up the plasma search, I ended up on TTY2... ha ha.
>
> Remember how I said I'll use nspawn from now on? I take that back. Let's
> just say this thing is not even remotely production ready.

Never had any issues with it, but I've never tried to use my host root
as the input filesystem.  I suspect the issue is that this is giving
the container access to the host /dev, /sys and so on, and thus the
container isn't ending up being contained.  Normally you don't go
mounting a host /dev inside a container image before launching it...

--
Rich



@Nikos Chantziaras

In case it helps you at all, here's an example nspawn configuration file that I've been using for quite a while.

I have a skeleton filesystem tree in /var/lib/machines/multimedia-state that bind-mount read-writable stuff.
Everything else is read-only bind-mounted from my root FS. I store things like samba configuration, and local state, there. For example, the container is a member of my samba4 domain controller.

I use systemd-machined to launch this container at boot.

mimir /etc/systemd/nspawn # cat multimedia.nspawn
[Exec]
PrivateUsers=false
MachineID=131472ae68624b99b5ce0bf18194cda1

[Files]
BindReadOnly=/bin/
BindReadOnly=/usr/
BindReadOnly=/var/
BindReadOnly=/lib/
BindReadOnly=/etc/
BindReadOnly=/sbin/
BindReadOnly=/lib64/

BindReadOnly=/var/lib/machines/multimedia-state/etc/fstab:/etc/fstab
BindReadOnly=/var/lib/machines/multimedia-state/etc/hostname:/etc/hostname

Bind=/var/lib/machines/multimedia-state/var/log/:/var/log/
Bind=/var/lib/machines/multimedia-state/var/lib/samba/:/var/lib/samba/
Bind=/var/lib/machines/multimedia-state/var/cache/samba/:/var/cache/samba/
Bind=/var/lib/machines/multimedia-state/etc/systemd/system/:/etc/systemd/system/

TemporaryFileSystem=/home/
TemporaryFileSystem=/var/tmp/
TemporaryFileSystem=/var/lib/machines/

Bind=/media/raid/multimedia/

[Network]
MACVLAN=general
 
Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Nikos Chantziaras-2
In reply to this post by Rich Freeman
On 18/02/2020 21:22, Rich Freeman wrote:

> On Tue, Feb 18, 2020 at 2:06 PM Nikos Chantziaras <[hidden email]> wrote:
>>
>> It gets worse. The container reconfigured the keyboard shortcuts on the
>> host! After booting a container, alt+Fn or alt+left/right on the host
>> started switching to the linux text-mode console. I pressed alt+f2 to
>> bring up the plasma search, I ended up on TTY2... ha ha.
>>
>> Remember how I said I'll use nspawn from now on? I take that back. Let's
>> just say this thing is not even remotely production ready.
>
> Never had any issues with it, but I've never tried to use my host root
> as the input filesystem.

I didn't do that either. Unless you mean the throw-away VM experiment,
which is not where this happened.


Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Rich Freeman
On Tue, Feb 18, 2020 at 4:32 PM Nikos Chantziaras <[hidden email]> wrote:

>
> On 18/02/2020 21:22, Rich Freeman wrote:
> > On Tue, Feb 18, 2020 at 2:06 PM Nikos Chantziaras <[hidden email]> wrote:
> >>
> >> It gets worse. The container reconfigured the keyboard shortcuts on the
> >> host! After booting a container, alt+Fn or alt+left/right on the host
> >> started switching to the linux text-mode console. I pressed alt+f2 to
> >> bring up the plasma search, I ended up on TTY2... ha ha.
> >>
> >> Remember how I said I'll use nspawn from now on? I take that back. Let's
> >> just say this thing is not even remotely production ready.
> >
> > Never had any issues with it, but I've never tried to use my host root
> > as the input filesystem.
>
> I didn't do that either. Unless you mean the throw-away VM experiment,
> which is not where this happened.

Strange.  I use it all the time and have never seen anything like that
happen.  That said, I can't remember the last time I fired up an X
server on the host.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Dale-46
In reply to this post by Nikos Chantziaras-2
Nikos Chantziaras wrote:

> On 17/02/2020 20:01, Dale wrote:
>> Nikos Chantziaras wrote:
>>> On 17/02/2020 10:26, Dale wrote:
>>>> I ran into a issue with qt upgrades and it got interesting.  Since it
>>>> was part way through, some applications that I needed wouldn't open
>>>> due
>>>> to a mismatch in versions. [...]
>>>>
>>>> !!! --buildpkgonly requires all dependencies to be merged.
>>>> !!! Cannot merge requested packages. Merge deps and try again.
>>>>
>>>> So, I have to emerge packages in order to emerge others.  I get that
>>>> packages depend on each other but is there a way around that?
>>> You'd need to maintain two gentoo installs (A and B) with the same
>>> exact configuration with B serving as the build machine. Then you'd
>>> emerge the packages in B, make binary packages out of every package,
>>> and then emerge those in A.
>>
>>
>> Would a chroot work for that?  I'm pretty sure it would but want to be
>> certain before I set all that up.  I'm pretty sure I can dig around and
>> find a hard drive somewhere.
>
> Sure. Although it might be easier to use a container instead (like LXD
> or Docker.)
>
> Grub has nothing to do with it. You wouldn't actually run grub in the
> container or chroot. You'd only install the grub package.
>
> A VM like Mark suggested would probably be even easier to set up.
> Although getting to the packages would be more complicated and it
> would also be slower (and with the recent meltdown/spectre mitigation
> stuff, probably much slower.) A chroot or container on the other hand
> is extremely lightweight. There's no virtualization involved (or very
> little of it), so it should be pretty much as fast as a native system.
>
>
>

Well, I downloaded the starge3 tarball.  I then copied over my /etc,
world, all the portage stuff such as distfiles, binaries and the tree as
well.  I also copied over any local overlays I had as well.  Since I
want to end up with a system as close to what I have, so that the
binaries will be a perfect match, I figured copy over all the variables
and settings with it.  I can't even get through a simple emerge -e
system.  It's either circular deps, slot conflicts or some other error. 
The last one was something about a corrupted /dev.  I'm not sure what to
make of that yet.  After I got that, it refused to do anything at all. 
It acted like it was out of drive space/memory or something but it
isn't.  It's on a 750GB drive with a lot of space left yet.  I have
32GBs of memory here with 3/4s currently available. 

So, I'm doing a rm on that and starting over from scratch.  I guess I'll
just have to move the contents of world over a few at a time and hope
copying make.conf and the USE line over won't break anything. 

I'm sure it was my method.  I likely overwhelmed emerge but I'd hate to
know I had to reinstall from scratch and get back to a identical install. 

Some things that I vaguely recall; freetype, harfbuzz, zlib and issues
they created.  I got around a couple others easy enough but it basically
suicided itself after that.

Off to try this again. 

Dale

:-)  :-) 

P. S. Starting to wonder if I should copy my current install over and
start there.  I'd assume skipping /home, /proc and /sys would get me
started.  Still, gonna try the stage3 again.  Just for giggles.  Do all
this while I cook some BBQ chicken for supper tomorrow night. 

Reply | Threaded
Open this post in threaded view
|

Re: Compiling first and then installing using -K

Dale-46
Dale wrote:
>
> P. S. Starting to wonder if I should copy my current install over and
> start there.  I'd assume skipping /home, /proc and /sys would get me
> started.  Still, gonna try the stage3 again.  Just for giggles.  Do all
> this while I cook some BBQ chicken for supper tomorrow night. 
>

Wanted to update on this, in case some other poor soul wants to go down
this path.  The PS above is what I ended up doing.  That stage3 tarball
never worked.  It was like running in circles trying to emerge
anything.  Plus, copying over from my current install gives me a 100%
clone of my install.  So, I created a script, y'all would call it a
joke, to copy over all the directories/files from my current install. 
That seems to work.  I actually noticed I'm a version behind on
kde-plasma and am upgrading it in the chroot as I type.  Once that is
done, I can copy over the binaries and do a emerge -k for the running
install.  This is my scripts, y'alls jokes.  lol 


root@fireball / # cat /root/gentoo-mount
mount --types proc /proc /backup/gentoo-build/proc/
mount --rbind /sys /backup/gentoo-build/sys/
mount --rbind /dev /backup/gentoo-build/dev/


root@fireball / # cat /root/gentoo-rsync-build
rsync -av --progress --delete /bin/* /backup/gentoo-build/bin/
rsync -av --progress --delete /boot/* /backup/gentoo-build/boot/
rsync -av --progress --delete /etc/* /backup/gentoo-build/etc/
rsync -av --progress --delete /lib/* /backup/gentoo-build/lib/
rsync -av --progress --delete /lib64/* /backup/gentoo-build/lib64/
rsync -av --progress --delete /opt/* /backup/gentoo-build/opt/
rsync -av --progress --delete /run/* /backup/gentoo-build/run/
rsync -av --progress --delete /sbin/* /backup/gentoo-build/sbin/
rsync -av --progress --delete /usr/* /backup/gentoo-build/usr/
rsync -av --progress --delete /var/* /backup/gentoo-build/var/

echo "Sync done"
root@fireball / #


The first one mounts things, if they are not already mounted.  The
second one syncs up everything, except /dev, /sys etc etc. 

I'll know in a couple hours or so how well this works.  I can't see why
I would have any problems but . . . . . I'm me.  ROFL  :/ 

Dale

:-)  :-) 

12