[gentoo-user] blocks to fix

[gentoo-user] blocks to fix

[Mark Knecht]

Are there any issues with all these blocks that I need to fix for updates?

Thanks,
Mark

[ebuild     U ] sys-fs/e2fsprogs-1.41.2 [1.40.9] USE="nls (-static%)" 4,263 kB
[ebuild  N    ] sys-libs/e2fsprogs-libs-1.41.2  USE="nls" 479 kB
[blocks B     ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] <sys-fs/e2fsprogs-1.41 (is blocking
sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] sys-libs/e2fsprogs-libs (is blocking
sys-libs/ss-1.40.9, sys-libs/com_err-1.40.9)

Total: 8 packages (7 upgrades, 1 new, 4 blocks), Size of downloads: 12,182 kB

RE: [gentoo-user] blocks to fix

[James Homuth]

 

-----Original Message-----
From: Mark Knecht [mailto:markknecht@gmail.com] 
Sent: October 28, 2008 10:35 PM
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] blocks to fix

Are there any issues with all these blocks that I need to fix for updates?

Thanks,
Mark

[ebuild     U ] sys-fs/e2fsprogs-1.41.2 [1.40.9] USE="nls (-static%)" 4,263
kB
[ebuild  N    ] sys-libs/e2fsprogs-libs-1.41.2  USE="nls" 479 kB
[blocks B     ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] sys-libs/com_err (is blocking
sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] <sys-fs/e2fsprogs-1.41 (is blocking
sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] sys-libs/e2fsprogs-libs (is blocking
sys-libs/ss-1.40.9, sys-libs/com_err-1.40.9)

Total: 8 packages (7 upgrades, 1 new, 4 blocks), Size of downloads: 12,182
kB

E1fsprogs and com_err have apparently been merged into the new package
portage wants to install for you. It's been suggested remove the two
packages it wants to upgrade, then install that one.

Hint: emerge --fetchonly sys-libs/e2fsprogs-libs; emerge --unmerge
e2fsprogs; emerge --unmerge com_err; emerge sys-libs/e2fsprogs-libs *should*
work. I say should, because I haven't actually tried it.

Re: [gentoo-user] blocks to fix

[Allan Gottlieb]

At Tue, 28 Oct 2008 22:43:38 -0400 James Homuth <james@the-jdh.com> wrote:

>  
>
> -----Original Message-----
> From: Mark Knecht [mailto:markknecht@gmail.com] 
> Sent: October 28, 2008 10:35 PM
> To: gentoo-user@lists.gentoo.org
> Subject: [gentoo-user] blocks to fix
>
> Are there any issues with all these blocks that I need to fix for updates?
>
> Thanks,
> Mark
>
> [ebuild     U ] sys-fs/e2fsprogs-1.41.2 [1.40.9] USE="nls (-static%)" 4,263
> kB
> [ebuild  N    ] sys-libs/e2fsprogs-libs-1.41.2  USE="nls" 479 kB
> [blocks B     ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2)
> [blocks B     ] sys-libs/com_err (is blocking
> sys-libs/e2fsprogs-libs-1.41.2)
> [blocks B     ] <sys-fs/e2fsprogs-1.41 (is blocking
> sys-libs/e2fsprogs-libs-1.41.2)
> [blocks B     ] sys-libs/e2fsprogs-libs (is blocking
> sys-libs/ss-1.40.9, sys-libs/com_err-1.40.9)
>
> Total: 8 packages (7 upgrades, 1 new, 4 blocks), Size of downloads: 12,182
> kB
>
> E1fsprogs and com_err have apparently been merged into the new package
> portage wants to install for you. It's been suggested remove the two
> packages it wants to upgrade, then install that one.
>
> Hint: emerge --fetchonly sys-libs/e2fsprogs-libs; emerge --unmerge
> e2fsprogs; emerge --unmerge com_err; emerge sys-libs/e2fsprogs-libs *should*
> work. I say should, because I haven't actually tried it.

It is not quite that simple.  There were many posts today (28 oct) on
this.  I suggest reading them.  You might need to unmask mit-krb5 for
example.  There is a danger of rendering wget and hence emerge unusable
(but if you have already --fetchonly'ed the pkgs then emerge can install
them).

To repeat the main point:  Read *carefully* today's discussion.

good luck,
allan

Re: [gentoo-user] blocks to fix

[Andrew MacKenzie]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

+++ Allan Gottlieb [gentoo-user] [Tue, Oct 28, 2008 at 11:11:48PM -0400]:
> It is not quite that simple.  There were many posts today (28 oct) on
> this.  I suggest reading them.  You might need to unmask mit-krb5 for
> example.  There is a danger of rendering wget and hence emerge unusable
> (but if you have already --fetchonly'ed the pkgs then emerge can install
> them).
> 
> To repeat the main point:  Read *carefully* today's discussion.
Yeah, I'll second this.  At the very least make sure you "emerge -f"
anything you unmerge.  To make it easy to re-merge if you break wget.

I had one system that specified USE="kerberos" and krb5 kept wanting to
pull back in com_err (I think).  Also removing com_err seemed to break wget
(and curl) on that system so I had to manually fetch some packages.

-- 
// Andrew MacKenzie  |  http://www.edespot.com
// GPG public key: http://www.edespot.com/~amackenz/public.key
// October.
// 
// This is one of the peculiarly dangerous months to speculate in stocks in.
// 
// The others are July, January, September, April, November, May, March, June,
// December, August, and February.
// 
//                 -- Mark Twain, "Pudd'nhead Wilson's Calendar"

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] blocks to fix

[Mark Knecht]

On Wed, Oct 29, 2008 at 9:24 AM, Andrew MacKenzie <amackenz@edespot.com> wrote:
> +++ Allan Gottlieb [gentoo-user] [Tue, Oct 28, 2008 at 11:11:48PM -0400]:
>> It is not quite that simple.  There were many posts today (28 oct) on
>> this.  I suggest reading them.  You might need to unmask mit-krb5 for
>> example.  There is a danger of rendering wget and hence emerge unusable
>> (but if you have already --fetchonly'ed the pkgs then emerge can install
>> them).
>>
>> To repeat the main point:  Read *carefully* today's discussion.
> Yeah, I'll second this.  At the very least make sure you "emerge -f"
> anything you unmerge.  To make it easy to re-merge if you break wget.
>
> I had one system that specified USE="kerberos" and krb5 kept wanting to
> pull back in com_err (I think).  Also removing com_err seemed to break wget
> (and curl) on that system so I had to manually fetch some packages.
>
> --
> // Andrew MacKenzie  |  http://www.edespot.com

Thanks all. I do need to be careful about this as the machine is 400
miles away and the user is completely unable to be of any help if it
stops working meaning I have to drive or the box has to be shipped.
Either alternative is not good.

Cheers,
Mark

Re: [gentoo-user] blocks to fix

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On Wed, 29 Oct 2008 11:00:41 -0700, Mark Knecht wrote:

> Thanks all. I do need to be careful about this as the machine is 400
> miles away and the user is completely unable to be of any help if it
> stops working meaning I have to drive or the box has to be shipped.
> Either alternative is not good.

It's a bit late now, but installing a second distro, or a bare stage 3
gentoo, as a dual boot so you can still access the machoine if it breaks.
As an alternative, send the user a GRML CD and get them to boot that if
things go wrong.


-- 
Neil Bothwick
Dream as if you'll live forever. Live as if you'll die today.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] blocks to fix

[Mark Knecht]

On Wed, Oct 29, 2008 at 1:49 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 29 Oct 2008 11:00:41 -0700, Mark Knecht wrote:
>
>> Thanks all. I do need to be careful about this as the machine is 400
>> miles away and the user is completely unable to be of any help if it
>> stops working meaning I have to drive or the box has to be shipped.
>> Either alternative is not good.
>
> It's a bit late now, but installing a second distro, or a bare stage 3
> gentoo, as a dual boot so you can still access the machoine if it breaks.
> As an alternative, send the user a GRML CD and get them to boot that if
> things go wrong.
>
>
> --
> Neil Bothwick

I tried the Gentoo install CD with him a couple of years ago. He was
unable to get ssh set up and tell me what his firewall's IP address
was.

Please remember, some of these folks fought in WW2. They are not
recent IT graduates! ;-)

Having a second install is a reasonable idea. I suppose I can probably
install that remotely but I cannot test it remotely (AFAIK) without
someone handy to choose the right line in the grub menu...

Thanks,
Mark

Re: [gentoo-user] blocks to fix

[Alex Schuster]

Mark Knecht writes:

> Having a second install is a reasonable idea. I suppose I can probably
> install that remotely but I cannot test it remotely (AFAIK) without
> someone handy to choose the right line in the grub menu...

You can use the grub-set-default command to boot another than the default 
entry:

default saved
fallback 0
...
title System A
kernel (hd0,0)/A

title System B
kernel (hd0,1)/B


System A is your default system. When you have installed B, activate the 2nd 
entry with "grub-set-default 1" (grub counts from 0). Put something 
like "sleep 600 & reboot" into B's /etc/conf.d/local.start that will make 
it reboot after a while, unless you are able to log in from remote and kill 
the sleep command.
Now reboot. B will be started. Try to log in. If it fails, wait a little, 
and try again. This time A should be up again.

Unless you have a kernel panic, and the system is just halted. Does anyone 
know if there is something one could do about that?

	Wonko

Re: [gentoo-user] blocks to fix

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]

On Thu, 30 Oct 2008 21:44:53 +0100, Alex Schuster wrote:

> Unless you have a kernel panic, and the system is just halted. Does
> anyone know if there is something one could do about that?

Isn't there a kernel option to force a reboot in the event of a panic?


-- 
Neil Bothwick

Death to all fanatics!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] blocks to fix

[Paul Hartman]

On Thu, Oct 30, 2008 at 4:51 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 30 Oct 2008 21:44:53 +0100, Alex Schuster wrote:
>
>> Unless you have a kernel panic, and the system is just halted. Does
>> anyone know if there is something one could do about that?
>
> Isn't there a kernel option to force a reboot in the event of a panic?

BOOTPARAM_SOFTLOCKUP_PANIC may be what you're thinking of.

Re: [gentoo-user] blocks to fix

[BRM]

That might work for some scenerios; however, it wouldn't likely for the recent e2fsprogs-lib/ss/com_err fiasco because the booting system would be unable to execute mount and wait until the user either entered the root password for maintenance mode or pressed "CTRL+D" to continue. (Yep, I hosed one of my systems over that issue!) So the system would not be either in a kernel panic nor able to run /etc/conf.d/local.start. So it wouldn't reboot without user intervention.

In most cases that would likely work though.

Ben



----- Original Message ----
From: Alex Schuster <wonko@wonkology.org>
To: gentoo-user@lists.gentoo.org
Sent: Thursday, October 30, 2008 4:44:53 PM
Subject: Re: [gentoo-user] blocks to fix

Mark Knecht writes:

> Having a second install is a reasonable idea. I suppose I can probably
> install that remotely but I cannot test it remotely (AFAIK) without
> someone handy to choose the right line in the grub menu...

You can use the grub-set-default command to boot another than the default 
entry:

default saved
fallback 0
...
title System A
kernel (hd0,0)/A

title System B
kernel (hd0,1)/B


System A is your default system. When you have installed B, activate the 2nd 
entry with "grub-set-default 1" (grub counts from 0). Put something 
like "sleep 600 & reboot" into B's /etc/conf.d/local.start that will make 
it reboot after a while, unless you are able to log in from remote and kill 
the sleep command.
Now reboot. B will be started. Try to log in. If it fails, wait a little, 
and try again. This time A should be up again.

Unless you have a kernel panic, and the system is just halted. Does anyone 
know if there is something one could do about that?

    Wonko

Re: [gentoo-user] blocks to fix

[Mark Knecht]

Good ideas all. Thanks.

I can do some work setting things up and then not test it until I have
my dad sitting in front of the machine. He can hit Ctrl-D. We've seen
that one before.

Cheers,
Mark

On Thu, Oct 30, 2008 at 3:12 PM, BRM <bm_witness@yahoo.com> wrote:
> That might work for some scenerios; however, it wouldn't likely for the recent e2fsprogs-lib/ss/com_err fiasco because the booting system would be unable to execute mount and wait until the user either entered the root password for maintenance mode or pressed "CTRL+D" to continue. (Yep, I hosed one of my systems over that issue!) So the system would not be either in a kernel panic nor able to run /etc/conf.d/local.start. So it wouldn't reboot without user intervention.
>
> In most cases that would likely work though.
>
> Ben
>
>
>
> ----- Original Message ----
> From: Alex Schuster <wonko@wonkology.org>
> To: gentoo-user@lists.gentoo.org
> Sent: Thursday, October 30, 2008 4:44:53 PM
> Subject: Re: [gentoo-user] blocks to fix
>
> Mark Knecht writes:
>
>> Having a second install is a reasonable idea. I suppose I can probably
>> install that remotely but I cannot test it remotely (AFAIK) without
>> someone handy to choose the right line in the grub menu...
>
> You can use the grub-set-default command to boot another than the default
> entry:
>
> default saved
> fallback 0
> ...
> title System A
> kernel (hd0,0)/A
>
> title System B
> kernel (hd0,1)/B
>
>
> System A is your default system. When you have installed B, activate the 2nd
> entry with "grub-set-default 1" (grub counts from 0). Put something
> like "sleep 600 & reboot" into B's /etc/conf.d/local.start that will make
> it reboot after a while, unless you are able to log in from remote and kill
> the sleep command.
> Now reboot. B will be started. Try to log in. If it fails, wait a little,
> and try again. This time A should be up again.
>
> Unless you have a kernel panic, and the system is just halted. Does anyone
> know if there is something one could do about that?
>
>    Wonko
>
>

[gentoo-user] Re: blocks to fix

[»Q«]

On Wed, 29 Oct 2008 20:49:13 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> It's a bit late now, but installing a second distro, or a bare stage 3
> gentoo, as a dual boot so you can still access the machoine if it
> breaks.

System Rescue CD is Gentoo-based and can be installed on HDD very
quickly and easily -- only seven files to copy from the CD, and add a
boot manager entry.

<http://www.sysresccd.org/>

-- 
»Q«
     Kleeneness is next to Gödelness.

Re: [gentoo-user] blocks to fix

[Momesso Andrea]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

On Wed, Oct 29, 2008 at 08:49:13PM +0000, Neil Bothwick wrote:
> On Wed, 29 Oct 2008 11:00:41 -0700, Mark Knecht wrote:
> 
> > Thanks all. I do need to be careful about this as the machine is 400
> > miles away and the user is completely unable to be of any help if it
> > stops working meaning I have to drive or the box has to be shipped.
> > Either alternative is not good.
> 
> It's a bit late now, but installing a second distro, or a bare stage 3
> gentoo, as a dual boot so you can still access the machoine if it breaks.
> As an alternative, send the user a GRML CD and get them to boot that if
> things go wrong.
> 

There is no need to drive there or to send a cd. Even with no com_err
and no wget, you can still ssh into the machine, so scp should work too.


[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] blocks to fix

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

On Thu, 30 Oct 2008 06:46:30 +0100, Momesso Andrea wrote:

> > It's a bit late now, but installing a second distro, or a bare stage 3
> > gentoo, as a dual boot so you can still access the machoine if it
> > breaks. As an alternative, send the user a GRML CD and get them to
> > boot that if things go wrong.

> There is no need to drive there or to send a cd. Even with no com_err
> and no wget, you can still ssh into the machine, so scp should work too.

On this occasion, yes. But as a general CYA policy, as long as the user
is capable of making a selection from a boot menu, a fallback distro
would be useful in this situation.


-- 
Neil Bothwick

If it isn't broken, I can fix it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] blocks to fix

[Mark Knecht]

On Thu, Oct 30, 2008 at 10:24 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 30 Oct 2008 06:46:30 +0100, Momesso Andrea wrote:
>
>> > It's a bit late now, but installing a second distro, or a bare stage 3
>> > gentoo, as a dual boot so you can still access the machoine if it
>> > breaks. As an alternative, send the user a GRML CD and get them to
>> > boot that if things go wrong.
>
>> There is no need to drive there or to send a cd. Even with no com_err
>> and no wget, you can still ssh into the machine, so scp should work too.
>
> On this occasion, yes. But as a general CYA policy, as long as the user
> is capable of making a selection from a boot menu, a fallback distro
> would be useful in this situation.
>
>
> --
> Neil Bothwick

Yes, it would be helpful. In my case it would need to be configured
for full ssh/noip support, and probably shouldn't be Gentoo based as
this selection wouldn't likely get updated very often and the now far
more restrictive policies on how often Gentoo has to be updated
probably aren't appropriate for this task.

None the less maybe a good thing for me to do would be to do an
install of something like this remotely, test it, and then deal with
system updates later.

Also, as long as ssh isn't harmed I can pretty much scp any package to
the machine and get it working again, albeit with some extra work.
Normally I already do a --fetchonly any time I'm planning on an emerge
-DuN world but if I forgot usually you can still make it work somehow.

Take care,
Mark

Re: [gentoo-user] blocks to fix

[KH]

Allan Gottlieb schrieb:
> At Tue, 28 Oct 2008 22:43:38 -0400 James Homuth <james@the-jdh.com> wrote:
>
>   
>>  
>>
>> -----Original Message-----
>> From: Mark Knecht [mailto:markknecht@gmail.com] 
>> [snip]
>>
>> E1fsprogs and com_err have apparently been merged into the new package
>> portage wants to install for you. It's been suggested remove the two
>> packages it wants to upgrade, then install that one.
>>
>> Hint: emerge --fetchonly sys-libs/e2fsprogs-libs; emerge --unmerge
>> e2fsprogs; emerge --unmerge com_err; emerge sys-libs/e2fsprogs-libs *should*
>> work. I say should, because I haven't actually tried it.
>>     
>
> It is not quite that simple.  There were many posts today (28 oct) on
> this.  I suggest reading them.  You might need to unmask mit-krb5 for
> example.  There is a danger of rendering wget and hence emerge unusable
> (but if you have already --fetchonly'ed the pkgs then emerge can install
> them).
>
> To repeat the main point:  Read *carefully* today's discussion.
>
> good luck,
> allan

Consider using quikpkg before unmerging anything

kh