/etc/pkg.conf when installing from snapshots
Is it unusual/unreasonable to install, not update, from a snapshot bsd.rd? If installing from a snapshot bsd.rd is not too unreasonable, does everyone doing that edit /etc/pkg.conf by hand to point to the local mirror's snapshots before re-booting, to pick up the firmware stuff in the first boot? In my case, that would be changing http://ftp.jaist.ac.jp/pub/OpenBSD/%c/packages/%a in /etc/pkg.conf to http://ftp.jaist.ac.jp/pub/OpenBSD/snapshots/packages/%a The reason I ask is that, having installed from last week's snapshot to an outboard drive for experimenting, I noticed, on the first boot, that it was looking for some uvideo (I think) firmware which it couldn't find with the installpath as it was. I changed the path to point to snapshots, then ran fw_update without parameters, and the only thing it told me was that quirks is up to date. I was expecting ti o say it found something, but, then again, the video controller on this guy is one of the unknowns in the dmesg, if I'm readng it right. dmesg for the snapshot: -- OpenBSD 5.8 (GENERIC.MP) #1234: Thu Aug 6 09:26:52 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1835790336 (1750MB) avail mem = 1776320512 (1694MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe4800 (43 entries) bios0: vendor Insyde version "F.0A" date 07/16/2014 bios0: Hewlett-Packard HP Pavilion 10 Notebook PC acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI HPET APIC MCFG ASF! BOOT FPDT MSDM SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices GPP0(S5) GPP1(S4) OHC1(S3) OHC2(S3) OHC3(S3) EHC1(S3) EHC2(S3) EHC3(S3) XHC0(S4) AWAD(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD A4-1200 APU with Radeon(TM) HD Graphics, 998.27 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD A4-1200 APU with Radeon(TM) HD Graphics, 998.13 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins ioapic1: misconfigured as apic 0, remapped to apid 5 acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (GPP0) acpiprt2 at acpi0: bus 5 (GPP1) acpiprt3 at acpi0: bus -1 (GPP2) acpiprt4 at acpi0: bus -1 (GPP3) acpiprt5 at acpi0: bus -1 (GFX_) acpiec0 at acpi0 acpicpu0 at acpi0: !C2(0@400 io@0x414), C1(@1 halt!), PSS acpicpu1 at acpi0: !C2(0@400 io@0x414), C1(@1 halt!), PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpitz0 at acpi0: critical temperature is 118 degC acpibtn0 at acpi0: PWRB acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 model "Primary" serial 43346 03/09/2014 type LIon oem "Hewlett-Packard" acpibtn1 at acpi0: LID_ acpivideo0 at acpi0: VGA_ acpivideo1 at acpi0: VGA_ cpu0: 998 MHz: speeds: 1000 900 800 700 600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 16h Host" rev 0x00 vga1 at pci0 dev 1 function 0 vendor "ATI", unknown product 0x9839 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) azalia0 at pci0 dev 1 function 1 vendor "ATI", unknown product 0x9840 rev 0x00: msi azalia0: no supported codecs pchb1 at pci0 dev 2 function 0 vendor "AMD", unknown product 0x1538 rev 0x00 ppb0 at pci0 dev 2 function 2 "AMD AMD64 16h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 rtsx0 at pci1 dev 0 function 0 "Realtek RTL8402 Card Reader" rev 0x01: msi sdmmc0 at rtsx0 re0 at pci1 dev 0 function 2 "Realtek 8101E" rev 0
Re: /etc/pkg.conf when installing from snapshots
Joel Rees writes: > Is it unusual/unreasonable to install, not update, from a snapshot bsd.rd? > > If installing from a snapshot bsd.rd is not too unreasonable, does > everyone doing that edit /etc/pkg.conf by hand to point to the local > mirror's snapshots before re-booting, to pick up the firmware stuff in > the first boot? > > In my case, that would be changing > > http://ftp.jaist.ac.jp/pub/OpenBSD/%c/packages/%a > > in /etc/pkg.conf to > > http://ftp.jaist.ac.jp/pub/OpenBSD/snapshots/packages/%a %c typically expands to 'snapshots' when you're running snapshots, but around release tagging time it's temporarily changed to match what the release will expand to. In a few weeks %c will expand to 'snapshots' again.
Re: /etc/pkg.conf when installing from snapshots
It occurred to me just now to take a diff on the dmesgs: On Mon, Aug 10, 2015 at 4:02 PM, Joel Rees wrote: > Is it unusual/unreasonable to install, not update, from a snapshot bsd.rd? > > If installing from a snapshot bsd.rd is not too unreasonable, does > everyone doing that edit /etc/pkg.conf by hand to point to the local > mirror's snapshots before re-booting, to pick up the firmware stuff in > the first boot? > > In my case, that would be changing > > http://ftp.jaist.ac.jp/pub/OpenBSD/%c/packages/%a > > in /etc/pkg.conf to > > http://ftp.jaist.ac.jp/pub/OpenBSD/snapshots/packages/%a > > The reason I ask is that, having installed from last week's snapshot > to an outboard drive for experimenting, I noticed, on the first boot, > that it was looking for some uvideo (I think) firmware which it > couldn't find with the installpath as it was. Judging from the lack of differences in the diff, I'm going to assume that, when the install path in /etc/pkg.conf is looking forward to the future, so to speak, it's safe to edit it and do the hw_update after the first boot. > I changed the path to point to snapshots, then ran fw_update without > parameters, and the only thing it told me was that quirks is up to > date. I was expecting ti o say it found something, but, then again, > the video controller on this guy is one of the unknowns in the dmesg, > if I'm readng it right. I'll have to try to remember to keep a better eye on that message when I re-install on the internal drive. > dmesg for the snapshot: > [...] diff of the dmesgs: --- 1,2c1,2 < OpenBSD 5.8 (GENERIC.MP) #1234: Thu Aug 6 09:26:52 MDT 2015 < dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP --- > OpenBSD 5.7-current (GENERIC_GPT.MP) #0: Sun Jun 14 23:13:31 JST 2015 > r...@phool.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC_GPT.MP 4c4 < avail mem = 1776320512 (1694MB) --- > avail mem = 1776336896 (1694MB) 19c19 < cpu0: AMD A4-1200 APU with Radeon(TM) HD Graphics, 998.27 MHz --- > cpu0: AMD A4-1200 APU with Radeon(TM) HD Graphics, 998.26 MHz 46,47c46,47 < acpicpu0 at acpi0: !C2(0@400 io@0x414), C1(@1 halt!), PSS < acpicpu1 at acpi0: !C2(0@400 io@0x414), C1(@1 halt!), PSS --- > acpicpu0 at acpi0: PSS > acpicpu1 at acpi0: PSS 130c130 < root on sd1a (8c7ca2743aa7e90e.a) swap on sd1b dump on sd1b --- > root on sd0a (c910159e72666593.a) swap on sd0b dump on sd0b --- Whatever it didn't find on the snapshot, it didn't seem to have found it before. Sorry for the noise. -- Joel Rees
Re: /etc/pkg.conf when installing from snapshots
On 2015-08-10, Joel Rees wrote:
> Is it unusual/unreasonable to install, not update, from a snapshot bsd.rd?
>
> If installing from a snapshot bsd.rd is not too unreasonable, does
> everyone doing that edit /etc/pkg.conf by hand to point to the local
> mirror's snapshots before re-booting, to pick up the firmware stuff in
> the first boot?
fw_update doesn't use this, it fetches from firmware.openbsd.org instead.
> In my case, that would be changing
>
> http://ftp.jaist.ac.jp/pub/OpenBSD/%c/packages/%a
>
> in /etc/pkg.conf to
>
> http://ftp.jaist.ac.jp/pub/OpenBSD/snapshots/packages/%a
>
> The reason I ask is that, having installed from last week's snapshot
> to an outboard drive for experimenting, I noticed, on the first boot,
> that it was looking for some uvideo (I think) firmware which it
> couldn't find with the installpath as it was.
If you can get it to do this again, please post the exact message
("dmesg -s" should make this easier).
Re: ps: display command arguments
Ingo Feinerer writes:
> Hi,
Hi Ingo,
> when running
>
> R --file=~/test.R --args -i -j -k
>
> with R from math/R in ports and test.R as
>
> commandArgs(TRUE)
> Sys.sleep(10)
>
> ps output displays
>
> /usr/local/lib/R/bin/exec/R --file=/home/user/test.R --args --args --args
> --args
>
> (Note the four --args.) However, R appears to have the right arguments
> (the first --args is deliberately ignored by R):
>
> R> commandArgs(TRUE)
> [1] "-i" "-j" "-k"
>
> Any ideas why the display of the arguments in ps differs from the
> command line?
One possible explanation is that R modifies its original argv[] in place.
--8<--
#include
int
main(int argc, char *argv[])
{
if (argc < 2)
return 1;
argv[1] = "new-argv[1]";
sleep(20);
return 0;
}
-->8--
If you launch ./r some-arg you'll see "new-argv[1]" in ps(1) output.
As a side note this doesn't happen on Linux thus some projects don't
care much about the possible breakage on OpenBSD (see the pexp in
net/geomyidae/pkg/geomyidae.rc).
> With a simple shell script I cannot reproduce this. E.g.,
>
> ./test.sh --args -i -j -k
>
> with test.sh as
>
> #!/bin/sh
*
> echo $@
> sleep 10
>
> results in ps displaying
>
> /bin/sh ./test.sh --args -i -j -k
ksh doesn't do weird stuff like that, at least...
* you could insert ''set -- --args --args --args --args'' here, to
replace the original arguments, ksh wouldn't modify argv either.
> Best regards,
> Ingo
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Is lack of a prompt in shell after building the kernel bad news?
I'm not sure this isn't just more noise, but someone points out that I didn't say I checked the tags. Nor did I confirm that I always use explicit tags when building -stable, following the advice in the FAQ. So the following is just to confirm that, and what I say here should be ignored by anyone who doesn't care about what I am sure was the result of trying to carry a non-GENERIC kernel forward. 2015/08/04 20:10 "Stuart Henderson" : > > On 2015-08-04, Joel Rees wrote: > > Thought login was freezing after the welcome message, beacause there was no > > prompt. So I hit the power button, watched it stop CUPS and something else > > and sync, and moved the old kernel back in for a build with GPT enabled, as > > a first wild guess. Just for the record, I had done a cvs up, with the rOPENBSD_5_7 specified, in .usr/src. I did not build userland before building the kernel. As I said in the original post, I did a csv up three times before building. But I'm sure I specified -rOPENBSD_5_7 each time. > > Same results, but I tried a few commands instead of > > just assuming no prompt meant freeze, and the "only" problem seems to be > > lack of prompt. Sort of. Piping to a pager doesn't page either. > > This kernel and userland are out of sync, there was a change made > at some point (I think it was between 5.7 and now but I could be wrong) > which did exactly this. IIRC this is the behaviour when you have newer > userland and old kernel. It's interesting that the behavior was the same. > Check your CVS trees and make sure they're > at the tags you expect (if that's 5.7, "cd /usr/src && cvs up -Pd -r > OPENBSD_5_7", if -current then -A instead of -r ). I looked at /usr/src/CVS/Tag and it said TOPENBSD_5_7. Checked all the directories going down to /usr/src/sys/arch/amd64, and they were the same. I'm not sure where else I'd look to check, after the fact. (Shell defaults, so I lose my history when I log out.) Well, if it's more important than I think it is, I can practice my skills with find and grep and negative conditions. I'm weak on find expressions. I'm still using this wedged system, since the old kernel has no issues and I never compiled and installed a new userland. I can still look for things if I know what to look for, but I'm willing to assume that it was the non-standard compiler option (GPT), possibly interacting with the changes Stuart mentioned above. And the not being able to go backward. And I'm okay with this. I finally got a block of time to re-install on the outboard drive, and once that's up I'll backup the data on the internal drive and wipe the GPT-enabled system. And try to avoid doing too many things at the same time in the future. Now can I leave this thread behind? -- Joel Rees
Patch for broken link at www.openiked.org
I'm not sure if this goes here. --- index.html.old Mon Aug 10 12:47:20 2015 +++ index.html Mon Aug 10 12:58:00 2015 @@ -24,8 +24,6 @@ - Language: en http://www.openbsd.org/translation.html";>[teams] - Resources http://www.openiked.org/goals.html";>Project Goals http://www.openiked.org/manual.html";>Manual Pages @@ -105,4 +103,4 @@ - \ No newline at end of file +
Re: Repartitioning
On 2015-08-06 23:13, Quartz wrote: > We have an older system running 4.9 that acts as a sort of > dev/test/scratch machine for messing around. When it was set up it we > threw a 10gb drive in there and did a generic install with all the > defaults. Over time, as we've used this for various stuff, we've > realized that that partitioning scheme turned out to be decidedly non > optimal. /usr/obj and /usr/src are eating up a gig each but only have > 2kb of data on them (this machine has never compiled anything). /home > and /usr/local are using less than 45mb combined. Meanwhile /var was > only set up at a few hundred megs and is bursting at the seams. Over > half the drive's capacity is being wasted. > > I'm not super familiar with how OpenBSD does disks and all of the > caveats. How easy would it be to nuke some of these partitions and > recombine the space? Is it something that could be done with a couple > fdisk commands or would it involve a lot of screwing around? I've looked > though the manual regarding fdisk and disklabel but I'm still not sure I > really understand how everything works together. So, I played a little with VirtualBox on my Mac, and realized that it can make screen capture videos. :-) I did a fresh install of OpenBSD 4.9 on a 10 GB virtual partition, using the default auto layout. And... here's an about 25 minute long video tutorial on how to do what I think you want. Yes I probably had better things to do, but nothing came to mind that seemed more fun... :-) There are some comments inline on what happens and why. But no sound, so put on some nice, engaging music while you watch! http://benny.lofgren.biz/tmp/repartitioning-openbsd-4.9.webm Unfortunately I don't know much about video formats and editing, so this is straight from VirtualBox in webm format, whatever that is. I know it plays under MPlayerX for Mac OS X, and I assume it'll play in most other incarnations of mplayer and other video players as well. One nag is that in my player the timestamps seem messed up. It claims to start at the 1:16:47 mark... but it plays fine. Feel free to ask me on or off list if you have any questions or run into any problems! But! Use this at your own risk and don't blame me if you mess up. :-) Take backups. Burn insense. Sacrifice a chicken at sunset. Walk three times counterclockwise around the old oak in moonlight, chanting "I trust the powers of OpenBSD". Use a condom. Have a fire extinguisher handy. Take preacutions. Have fun! Good luck! /Benny -- internetlabbet.se / work: +46 8 551 124 80 / "Words must Benny Lofgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted." /email: benny -at- internetlabbet.se
Re: Repartitioning
On 2015-08-10 11:21, Benny Lofgren wrote: Sacrifice a chicken at sunset. For clarity, I recall best practice is to use a rooster. :)
Re: Repartitioning
On 2015-08-10 17:32, Josh Grosse wrote: > On 2015-08-10 11:21, Benny Lofgren wrote: > >> Sacrifice a chicken at sunset. > > For clarity, I recall best practice is to use a rooster. :) Bummer! Missed that. But I think it's the default choice since OpenBSD 4.7 so it's probably okay. :-) /B
Re: Repartitioning
On 2015-08-10 17:21, Benny Lofgren wrote: > So, I played a little with VirtualBox on my Mac, and realized that it > can make screen capture videos. :-) I did a fresh install of OpenBSD 4.9 > on a 10 GB virtual partition, using the default auto layout. Okay... so this was kind of fun... I made another one showing how to combine two partitions as in the previous example, using disklabel and growfs. :-) http://benny.lofgren.biz/tmp/using-growfs-openbsd-4.9.webm /Benny -- internetlabbet.se / work: +46 8 551 124 80 / "Words must Benny Lofgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted." /email: benny -at- internetlabbet.se
Re: radeondrm firmware archive problem?
On Sun, 9 Aug 2015, Theo de Raadt wrote: On Sat, Aug 08, 2015 at 10:59:15PM -0800, pstern wrote: hello: I recently put a couple of Dell optiplex 7010 machiens in operation using OpenBSD 5.6 and 5.7. Both machines have a radeon card in them. vga1 at pci1 dev 0 function 0 "ATI Radeon HD 7470" rev 0x00 I ran into the video going to gray screen during the boot process when it tried to switch to high res. I disabled the radeondrm temporarily to get the machines to boot. I found the radeondrm-firmware-20131002p2.tgz at firmware.openbsd.org Trying to use pkd_add would not work because it kept reporting the archive was corrupt. I believe the problem was actually the signature in the archive wasn't current and could not be validated against the certificates in /etc/ssl or /etc/signify. Nope. it's that it's signed with the firmware keys... which is why you install firmwares with fw_update and not pkg_add. I ended up manually loading the firmware in /etc/firmware, which resulted in bypassing verifying the archive, but the archive expanded without a problem. The machines run fine with the contents of that archive in place. Is there something wrong with that archive? The fact that it looks like a normal package doesn't mean it's a normal package. Since you expanded it manually, you can look at the @signer line in the contents. You'll see the signature name in all its glories. The design of signify means it's the *commands* that decide which signatures they trust. There are three classes of keys in openbsd. Trying to verify a fw-signed archive with a pkg-checking command won't work. I saw that pkg_add is discouraged at the bottom of the man page for fw_update. Trying local update # ls -la /etc/firmware/*.tgz -rw-r--r-- 1 root wheel 1224091 Aug 8 15:08 /etc/firmware/radeondrm-firmware-20131002p0.tgz # fw_update -n -v -p /etc/firmware/radeondrm-firmware-20131002p0.tgz fw_update: Path to firmware: /etc/firmware/radeondrm-firmware-20131002p0.tgz fw_update: Installing firmware: radeondrm-firmware.file:/etc/firmware/radeondrm-firmware-20131002p0.tgz/ is empty Can't find radeondrm-firmware trying directly from firmware.openbsd.org fw_upate -n -v -p http://firmware.openbsd.org/firmware/5.7/radeondrm-firmware-20131002p0.tgz fw_update: Path to firmware: http://firmware.openbsd.org/firmware/5.6/radeondrm-firmware-20131002p0.tgz fw_update: Installing firmware: radeondrm-firmware. Error from http://firmware.openbsd.org/firmware/5.7/radeondrm-firmware-20131002p0.tgz/ ftp: Error retrieving file: 404 Not Found http://firmware.openbsd.org/firmware/5.7/radeondrm-firmware-20131002p0.tgz/ is empty Can't find radeondrm-firmware What is the correct way to deal with this file? Just Wow. The right way to use it is # fw_update That's it, you don't need any specific options, nor do you have to give it URLs to files. It autodiscovers. For some firmwares, you need to follow this with a reboot so that the kernel can find the actual firmwares early enough in boot. You really are inventing your own difficulties. Sometimes you have to step back and go "Wow, I am passing 5 arguments to the program. Is that what the system developers would have intended as normal operation?" The answer is NO. fw_update no parameters was the first thing I tried. Nothing happened. fw_update -v reported no firmware needed to be updated. the radeondrm firmware was not installed in /etc/firmware as part of install. To boot this machine, I had to disable radeondrm in UKC or video disappeared during the boot. I removed the radeondrm firmware and rebooted (disable radeondrm)then fw_update -a -v This works apparently because it walks firmware.openbsd.org/firmware/5.7/ and it installed the radeondrm firmware and every other firmware regardless of need. Sorry for the noise. I've been using openbsd since v2, but never had to deal with installing radeon or other firmware. Thank you, peter
Re: radeondrm firmware archive problem?
On Mon, Aug 10, 2015 at 08:29:11AM -0800, pstern wrote: > fw_update no parameters was the first thing I tried. Nothing happened. > > fw_update -v reported no firmware needed to be updated. > > the radeondrm firmware was not installed in /etc/firmware as part of > install. > > To boot this machine, I had to disable radeondrm in UKC or video disappeared > during the boot. That explains... ouch. fw_update radeondrm would have been enough. probably hard to guess.
resource impact of bgp-spamd
In general terms, what kind of additional memory/disk/cpu usage is incurred through the use of a bgp-spamd client? Is this something that is likely able to run on a low end device like a Soekris 5501, or is it something more suited to a Real Server? (I don't see any dedicated mailing list on the bgp-spamd.net web page, so hopefully this is an appropriate place to ask.) Devin
Re: radeondrm firmware archive problem?
On Mon, 10 Aug 2015, Marc Espie wrote: On Mon, Aug 10, 2015 at 08:29:11AM -0800, pstern wrote: fw_update no parameters was the first thing I tried. Nothing happened. fw_update -v reported no firmware needed to be updated. the radeondrm firmware was not installed in /etc/firmware as part of install. To boot this machine, I had to disable radeondrm in UKC or video disappeared during the boot. That explains... ouch. fw_update radeondrm would have been enough. probably hard to guess. I appreciate the suggestion, that works. Thanks, peter
