PXE boot RHEL 6.3 or OL 6.3 from OpenBSD 5.4
Greetings, It is possible to PXE boot other OSs (like RHEL 6.3 and/or OL 6.3) with pxeboot. If so, can somebody point me to a valid PXE configuration. Ioan
Re: Help troubleshooting performance problem
OK, just to clarify: The kernel is 5.3 with the official patches applied, no other modifications. I read through the changes for 5.4 and certainly, there has been a ton of work done, and I will upgrade soon. Nothing listed in the changes seems like it would directly address a problem like this, so I'd guess it's not a bug though. It certainly *seems* like it could be a hardware problem that's just not throwing an error (yet). So, I guess what I'm asking everyone is: Other than what I've done, what are some ways I can investigate this further to determine where the problem lies? For example, let's say it *is* a failing hard drive in the softraid, and the system just hasn't failed the drive yet, because the operations still complete, just really slowly. What tools/techniques could I use to see that a process is waiting for a disk operation that's taking forever to complete? Thanks, -John On Sat, Nov 30, 2013 at 9:39 PM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Sat, Nov 30, 2013 at 07:04:44PM -0600, Shawn K. Quinn wrote: On Sat, Nov 30, 2013, at 03:55 PM, Kenneth R Westerback wrote: On Sat, Nov 30, 2013 at 04:02:58PM -0500, John Hynes wrote: OpenBSD 5.3 (GENERIC.MP) #0: Fri Sep 13 04:11:52 EDT 2013 j...@hytronix-gw1.hytronix.com:/usr/src/sys/arch/amd64/compile/ GENERIC.MP Try 5.4 or -current. Issues with non-home-compiled kernels are more interesting. I thought as long as it was an unmodified GENERIC or GENERIC.MP that the issue was still valid. Is this no longer the case? -- Shawn K. Quinn skqu...@rushpost.com Sure - but if it's unmodified, why compile a new one? And John did not state in his email that it was unmodified. Ken
Re: PXE boot RHEL 6.3 or OL 6.3 from OpenBSD 5.4
On Sun, Dec 01, 2013 at 10:20:55PM +1100, mufurcz wrote: Greetings, It is possible to PXE boot other OSs (like RHEL 6.3 and/or OL 6.3) with pxeboot. If so, can somebody point me to a valid PXE configuration. No because pxeboot is a modified version of the i386 second-stage bootstrap program, boot(8),... That said, it is OpenBSD specific. Check iPXE, http://ipxe.org/howto/chainloading. Problem is that dhcpd in default OpenBSD installation does not support the way how to escape netboot looping. Thus you have to use ISC dhcpd or another dhcpd, or you have to compile undionly.kpxe yourself with embedded script. There's compilation issue of iPXE on OpenBSD, see http://forum.ipxe.org/showthread.php?tid=7135. Description of loop problem: * dhcp client - tftp server * get's undionly.kpxe * undionly.kpxe (iPXE) again tries dhcp... * loop :-) Feel free to help with iPXE compilation. jirib
Re: PXE boot RHEL 6.3 or OL 6.3 from OpenBSD 5.4
On 1/12/2013 10:31 PM, Jiri B wrote: On Sun, Dec 01, 2013 at 10:20:55PM +1100, mufurcz wrote: Greetings, It is possible to PXE boot other OSs (like RHEL 6.3 and/or OL 6.3) with pxeboot. If so, can somebody point me to a valid PXE configuration. No because pxeboot is a modified version of the i386 second-stage bootstrap program, boot(8),... That said, it is OpenBSD specific. Check iPXE, http://ipxe.org/howto/chainloading. Problem is that dhcpd in default OpenBSD installation does not support the way how to escape netboot looping. Thus you have to use ISC dhcpd or another dhcpd, or you have to compile undionly.kpxe yourself with embedded script. There's compilation issue of iPXE on OpenBSD, see http://forum.ipxe.org/showthread.php?tid=7135. Description of loop problem: * dhcp client - tftp server * get's undionly.kpxe * undionly.kpxe (iPXE) again tries dhcp... * loop :-) Feel free to help with iPXE compilation. jirib Uhm, got it, I read the boot(8) man, however, I am curious, in the `Hitchhiker's Guide to OpenBSD` reads Can I boot other kinds of kernels using PXE other than bsd.rd? Yes, although with the tools currently in OpenBSD, PXE booting is primarily intended for installing the OS. I read this: `other OpenBSD kernels (only) than bsd.rd'. ioan
Re: PXE boot RHEL 6.3 or OL 6.3 from OpenBSD 5.4
On Sun, Dec 01, 2013 at 11:49:08PM +1100, mufurcz wrote: Uhm, got it, I read the boot(8) man, however, I am curious, in the `Hitchhiker's Guide to OpenBSD` reads Can I boot other kinds of kernels using PXE other than bsd.rd? Yes, although with the tools currently in OpenBSD, PXE booting is primarily intended for installing the OS. I read this: `other OpenBSD kernels (only) than bsd.rd'. pxeboot boots only OpenBSD kernels but you can boot normal 'bsd' kernel too, see how pxeboot(8) refers to boot.conf. jirib
Re: Help troubleshooting performance problem
On 12/01/13 06:20, John Hynes wrote: OK, just to clarify: The kernel is 5.3 with the official patches applied, no other modifications. I read through the changes for 5.4 and certainly, there has been a ton of work done, and I will upgrade soon. Nothing listed in the changes seems like it would directly address a problem like this, so I'd guess it's not a bug though. It certainly *seems* like it could be a hardware problem that's just not throwing an error (yet). So, I guess what I'm asking everyone is: Other than what I've done, what are some ways I can investigate this further to determine where the problem lies? For example, let's say it *is* a failing hard drive in the softraid, and the system just hasn't failed the drive yet, because the operations still complete, just really slowly. What tools/techniques could I use to see that a process is waiting for a disk operation that's taking forever to complete? Thanks, -John I've got one of these machines (Sun X2100 M2). I had performance problems in the past with it, similar to what you described, simple tasks which seemed to hang on disk I/O where disk I/O shouldn't have been a problem. I credited the problem to the nvidia chipset. I did recently blow the dust off the machine and put 5.4-current on it, and -- SO FAR -- it's running pretty darned well. The way the disks are connected to the main board, if you swap the red and blue SATA cables, you can route them to the PCIe slot rather than the on-board SATA connectors, and you may be able to put a third-party SATA controller to work with them (or you may not -- I made a VERY quick attempt at this recently, thinking I'd maybe be able to get AHCI performance out of it, and the thing booted the OpenBSD kernel but the controller (which I have used elsewhere without issue) didn't initialize properly, and so I had no disks after boot. Upon disassembly, I found the card was working its way loose, and it was late, so I didn't spend a lot of time trying to figure out exactly what was wrong, and I just switched back to my on-board SATA...which has been working fine for a week or so now). But really...it's an nvidia machine. if it works at all, you should be happy... I'd not trust it too far That being said...there are some nasty disk failure modes I've seen more than once, where a disk will start doing retries over and over until a successful read takes place...and then it will go on to the next read, with lots of retries ... etc. The result is a painfully slow machine, and it is somewhat hard to diagnose since the drive never returns an error to the OS. If you have disk activity lights for each disk, it's actually trivial to see where the machine is hung, but this machine's manufacturer doesn't feel that disk activity lights are useful (idiots. Blame Sun this time). Nick. On Sat, Nov 30, 2013 at 9:39 PM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Sat, Nov 30, 2013 at 07:04:44PM -0600, Shawn K. Quinn wrote: On Sat, Nov 30, 2013, at 03:55 PM, Kenneth R Westerback wrote: On Sat, Nov 30, 2013 at 04:02:58PM -0500, John Hynes wrote: OpenBSD 5.3 (GENERIC.MP) #0: Fri Sep 13 04:11:52 EDT 2013 j...@hytronix-gw1.hytronix.com:/usr/src/sys/arch/amd64/compile/ GENERIC.MP Try 5.4 or -current. Issues with non-home-compiled kernels are more interesting. I thought as long as it was an unmodified GENERIC or GENERIC.MP that the issue was still valid. Is this no longer the case? -- Shawn K. Quinn skqu...@rushpost.com Sure - but if it's unmodified, why compile a new one? And John did not state in his email that it was unmodified. Ken
Re: PXE boot RHEL 6.3 or OL 6.3 from OpenBSD 5.4
On 12/01/13 07:48, mufurcz wrote: On 1/12/2013 10:31 PM, Jiri B wrote: On Sun, Dec 01, 2013 at 10:20:55PM +1100, mufurcz wrote: Greetings, It is possible to PXE boot other OSs (like RHEL 6.3 and/or OL 6.3) with pxeboot. If so, can somebody point me to a valid PXE configuration. No because pxeboot is a modified version of the i386 second-stage bootstrap program, boot(8),... That said, it is OpenBSD specific. Check iPXE, http://ipxe.org/howto/chainloading. Problem is that dhcpd in default OpenBSD installation does not support the way how to escape netboot looping. Thus you have to use ISC dhcpd or another dhcpd, or you have to compile undionly.kpxe yourself with embedded script. There's compilation issue of iPXE on OpenBSD, see http://forum.ipxe.org/showthread.php?tid=7135. Description of loop problem: * dhcp client - tftp server * get's undionly.kpxe * undionly.kpxe (iPXE) again tries dhcp... * loop :-) Feel free to help with iPXE compilation. jirib Uhm, got it, I read the boot(8) man, however, I am curious, in the `Hitchhiker's Guide to OpenBSD` reads Can I boot other kinds of kernels using PXE other than bsd.rd? Yes, although with the tools currently in OpenBSD, PXE booting is primarily intended for installing the OS. I read this: `other OpenBSD kernels (only) than bsd.rd'. The FAQ is about OpenBSD, the page is about OpenBSD, I kinda assumed people would understand that by other kinds of kernels I meant OpenBSD kernels, and not suddenly jump way off topic here. I'm not a big fan of trying to deal with every imaginable way someone could misunderstand something, but adding one word might make it more clear, and I do seem to recall having wondered myself if I could boot other OSses this way...so I have changed it to read Can I boot other kinds of OpenBSD kernels using PXE ... Nick.
Re: PXE boot RHEL 6.3 or OL 6.3 from OpenBSD 5.4
On 2/12/2013 4:11 AM, Nick Holland wrote: On 12/01/13 07:48, mufurcz wrote: On 1/12/2013 10:31 PM, Jiri B wrote: On Sun, Dec 01, 2013 at 10:20:55PM +1100, mufurcz wrote: Greetings, It is possible to PXE boot other OSs (like RHEL 6.3 and/or OL 6.3) with pxeboot. If so, can somebody point me to a valid PXE configuration. No because pxeboot is a modified version of the i386 second-stage bootstrap program, boot(8),... That said, it is OpenBSD specific. Check iPXE, http://ipxe.org/howto/chainloading. Problem is that dhcpd in default OpenBSD installation does not support the way how to escape netboot looping. Thus you have to use ISC dhcpd or another dhcpd, or you have to compile undionly.kpxe yourself with embedded script. There's compilation issue of iPXE on OpenBSD, see http://forum.ipxe.org/showthread.php?tid=7135. Description of loop problem: * dhcp client - tftp server * get's undionly.kpxe * undionly.kpxe (iPXE) again tries dhcp... * loop :-) Feel free to help with iPXE compilation. jirib Uhm, got it, I read the boot(8) man, however, I am curious, in the `Hitchhiker's Guide to OpenBSD` reads Can I boot other kinds of kernels using PXE other than bsd.rd? Yes, although with the tools currently in OpenBSD, PXE booting is primarily intended for installing the OS. I read this: `other OpenBSD kernels (only) than bsd.rd'. The FAQ is about OpenBSD, the page is about OpenBSD, I kinda assumed people would understand that by other kinds of kernels I meant OpenBSD kernels, and not suddenly jump way off topic here. I'm not a big fan of trying to deal with every imaginable way someone could misunderstand something, but adding one word might make it more clear, and I do seem to recall having wondered myself if I could boot other OSses this way...so I have changed it to read Can I boot other kinds of OpenBSD kernels using PXE ... Nick. Thanks, apologies for the noise. ioan
Re: System freeze after zzz
On Tue, Nov 26, 2013 at 07:44:32AM -0500, Donald Allen wrote:
On Tue, Nov 26, 2013 at 2:15 AM, Mike Larkin mlar...@azathoth.net wrote:
On Sun, Nov 24, 2013 at 10:42:45AM -0500, Don Allen wrote:
..snip..
After waking up:
Switching consoles with ctrl-alt F2, I was able to run the date
command repeatedly, and the time is advancing. 'ls' also worked
normally, but 'ls -l' hung. 'ps aux' hangs. 'shutdown' and 'reboot'
both hang.
Switching consoles with ctrl-alt F1, I noticed the following chatter:
ahci0: device on port 0 didn't come ready TFD: 0x80BSY
ahci0: Stopping the port, soft reset slot 31 was still active
ahci0: unable to communicate with device on port 1
That's your problem, your disk didn't come back after resume. I'm not sure
why, this is the first time I've seen that. Maybe some ahci expert
can comment further. I've frequently seen the first ahci0: line above
but my disks always come back online after that.
I don't know if the above is significant, but it isn't there on that
first console if I don't suspend and it struck me as suspicious.
I also noticed that the disk-busy light on the front panel is on solid
after attempting to resume. In normal operation, when there is disk
activity and the light is on, I can hear the disk, presumably the
heads seeking. In this situation, I don't hear that. I realize that
doesn't mean there isn't disk activity, just not long enough head
excursions to be audible.
The disk came back partly-resumed. Who knows what state it's in.
I have all filesystems mounted with softdep enabled, and after
power-cycling to reboot, there's usually a lot of chatter from fsck
about repairing things on various filesystems. One that usually turns
up needing repair is sd0d, which is /tmp. If the fsck output is logged
somewhere and it would be helpful, I can send it. I tried to find it
with
cd /var
find . -exec fgrep SALVAGED {} \; -print
which turned up nothing. Or I can try to photograph the screen as it's
happening.
Your FSes were uncleanly shut down since the disk didn't resume and that's
why fsck finds a bunch of uncleanliness.
I also tried suspending with 'zzz' right after booting and logging in,
no 'startx'. After attempting to resume, I got a stream of messages on
the first console, all the same:
ehci_idone: ex=0x801f3c00 is done!
That's irrelevant and may even be fixed by some recent commits. It's
because we basically need to tear down the USB device tree and reconnect
it on resume. There was probably an xfer in flight when you suspended and
the device to which it was associated dissappeared (temporarily) on
resume.
The disk-busy light was not on. I could not switch consoles to try
commands and could not type at the console that was spewing these
messages. As with the above, I had to power-cycle to recover.
/Don
Your problem is that your disk didn't resume. There are some efforts going
on presently to improve some of the wakeup/resume codepaths, but those
diffs aren't in the tree yet. They may or may not help.
Why does OpenBSD lack a man page for ulimit?
I could expand about what caused my need for more memory, but I don't think that would be relevant. I am just really curious about this issue since everything else seems to be so well documented, this certainly seem like a weird phenomenon on OpenBSD. When I need to do something I can usually manage fine with just the man pages but I had to use Google to know how to use ulimit.
Re: Why does OpenBSD lack a man page for ulimit?
I could expand about what caused my need for more memory, but I don't think that would be relevant. I am just really curious about this issue since everything else seems to be so well documented, this certainly seem like a weird phenomenon on OpenBSD. When I need to do something I can usually manage fine with just the man pages but I had to use Google to know how to use ulimit. ulimit is a shell built-in. man ksh, then search the manual page. That is also why you won't find a man page for eval, fg, jobs, let, return, set ...
Re: Why does OpenBSD lack a man page for ulimit?
On Sun, Dec 01, 2013 at 07:50:29PM -0700, Jorge Castillo wrote: I could expand about what caused my need for more memory, but I don't think that would be relevant. I am just really curious about this issue since everything else seems to be so well documented, this certainly seem like a weird phenomenon on OpenBSD. When I need to do something I can usually manage fine with just the man pages but I had to use Google to know how to use ulimit. Ulimit is a ksh command. Please try `man ksh` A.
Re: Why does OpenBSD lack a man page for ulimit?
Okay, thanks. On Sun, Dec 1, 2013 at 7:53 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: I could expand about what caused my need for more memory, but I don't think that would be relevant. I am just really curious about this issue since everything else seems to be so well documented, this certainly seem like a weird phenomenon on OpenBSD. When I need to do something I can usually manage fine with just the man pages but I had to use Google to know how to use ulimit. ulimit is a shell built-in. man ksh, then search the manual page. That is also why you won't find a man page for eval, fg, jobs, let, return, set ...
