Re: [gentoo-user] blocks to fix
Allan Gottlieb schrieb: At Tue, 28 Oct 2008 22:43:38 -0400 James Homuth [EMAIL PROTECTED] wrote: -Original Message- From: Mark Knecht [mailto:[EMAIL PROTECTED] [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
Re: [gentoo-user] blocks to fix
On Thu, Oct 30, 2008 at 10:24 AM, Neil Bothwick [EMAIL PROTECTED] 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
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
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! signature.asc Description: PGP signature
Re: [gentoo-user] blocks to fix
On Thu, Oct 30, 2008 at 4:51 PM, Neil Bothwick [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
+++ 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 pgpdTCoP2RAaM.pgp Description: PGP signature
Re: [gentoo-user] blocks to fix
On Wed, Oct 29, 2008 at 9:24 AM, Andrew MacKenzie [EMAIL PROTECTED] 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
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. signature.asc Description: PGP signature
Re: [gentoo-user] blocks to fix
On Wed, Oct 29, 2008 at 1:49 PM, Neil Bothwick [EMAIL PROTECTED] 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
On Wed, Oct 29, 2008 at 08:49:13PM +, 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. pgp9BUugE72tu.pgp Description: PGP signature
[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
RE: [gentoo-user] blocks to fix
-Original Message- From: Mark Knecht [mailto:[EMAIL PROTECTED] 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
At Tue, 28 Oct 2008 22:43:38 -0400 James Homuth [EMAIL PROTECTED] wrote: -Original Message- From: Mark Knecht [mailto:[EMAIL PROTECTED] 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