[osol-help] Is xVM on Solaris 10 or not?
I'm sure this has been asked tens of times, and still I don't get it. Downloaded the latest Sol10 to install it, because the web page implied xVM was on Solaris 10. But after the install, I didn't get the choice as I used to under OpenSolaris (Nevada). Now I wonder, if it has been backported or not? Thanks in advance! -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] OpenSolaris 2009.06 stalls always after some 5 minutes
What next? The machine answered the question: It was running smoothly for close to an hour. Then I left for lunch. When I came back, the monitor was black, no reaction. I tried all and everything, with power button as last resort. That resulted in a cold start. Since this was a good opportunity, I gave it a shot and pulled a network cable to it, and disabled WLAN. And it connected properly to the network; so the NIC is probably not broken, as one could assume. The message lines are as in my earlier mail, except that there are two more: one with bge0 link up, immediately followed by bad address 0.0.0.0 I had issued ifconfig bge0 dhcp afterwards, and there are no more bge0 messages in the log. So what we seem to encounter here, is a bad architectural mistake in the kernel. Blame nwam on pulling the wrong cords, nevermind. But the kernel must not allow this to happen: When bge0 can't connect, it monopolises all resources to load the 'correct' firmware to get it back up? On top of that, I never used bge0, always wpi0. So there is no reason at all for the kernel to try to force bge0 to work. -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] OpenSolaris 2009.06 stalls always after some 5 minutes
Is it possible that the ip address assigned to the system's hostname was bound to the bge0 interface; that is, after disabling the bge driver, connections to the local machine using the machine' `hostname` failed ? I suspect that the X screen blank needs such a connection to wake up from screen blank mode... No, bge0 came in later. That was when it was running wpi0, with bge0 disabled in the kernel. That is, when there is no cable connected to the bge NIC hardware, the machine starts to consume lots of kernel cpu time after a few minutes, and eventually hangs the system? Correct. And when a cable is connected, there is no excessive kernel cpu time usage, and the machine doesn't hang? Aside of those many mwaiti86 (or so), correct. At least, the machine doesn't hang (as before, let's leave out the non-return after some 2 hours of my absence), and has a beautiful load less 0.10. Yep; I'd say something is broken in the bge driver... And in the kernel architecture, I'd add. I don't consider it proper for the kernel to shoot itself by trying to wake up a little NIC at the periphery.? Maybe the BIOS has configured the nic hardware to enter a power saving state after five minutes with no activity; and the Solaris bge driver is confused when the device enters that power saving state (it tries to recover by reseting the bge hardware, but fails to wake up the hardware, and tries to wait forever for the firmware to become ready) ? As I mentioned before, the BIOS is most ugly in this machine, it doesn't allow much, many settings seem to be inaccessible by the user. As for your theory above, we have two phases to consider: 1. For some reason, the kernel tries hard to wake up bge0 after some 5 minutes, consuming all of CPU0 2. After a few minutes more, the system is completely dead. What else does it do, what does it try to achieve a few minutes later that kills it completely? I think a possible workaround is to disable svc:/network/physical:nwam, enable svc:/network/physical:default, and manually configure the wpi0 interface (and not use the bge interface for now). My workaround is much more elegant: Boot to Ubuntu, OpenBSD or XP. They all work pretty well on this machine. :( Nevertheless, if there is anything more required from my side to help debugging this situation, let me know! Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] OpenSolaris 2009.06 stalls always after some 5 minutes
ISR(s) ... 25 0x30 4 PCIEdg MSI0 1 - pepb_intr_handler could be related to PCI-e / PCI bus bridge; maybe some hotplug or power management event interrupt. The five minute delay could be a hint that it is related to power management. Are there perhaps BIOS setup options to enabled / disable power management for PCI-e devices? Alas, no. As much as I have come to like the machine, the BIOS is atypical. Just a proprietary down to cannot set anything here from HP. -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] OpenSolaris 2009.06 stalls always after some 5 minutes
If you repeat that lockstat, does the result look similar? cpu usage by cpu[0]+4, in tsc_read(), ddi_mem_get32(), tsc_gethrtime(), ...drv_usecwait() ? Maybe we can find out who's calling drv_usecwait(), using: lockstat -kIW -f drv_usecwait -s 10 sleep 15 Okay, think, I caught them all here: First the two at sanity (~0% CPU): # lockstat -kIW -f drv_usecwait -s 10 sleep 15 Profiling interrupt: 1 events in 15.041 seconds (0 events/sec) --- Count indv cuml rcnt nsec Hottest CPU+PILCaller 1 100% 100% 0.00 1246 cpu[0] drv_usecwait nsec -- Time Distribution -- count Stack 2048 |@@ 1 ec_wait_ibf_clear ec_rd ec_handler AcpiEvAddressSpaceDispatch AcpiExAccessRegion AcpiExFieldDatumIo AcpiExExtractFromField AcpiExReadDataFromField AcpiExResolveNodeToValue --- # lockstat -kIW -D 20 sleep 15 Profiling interrupt: 2918 events in 15.042 seconds (194 events/sec) Count indv cuml rcnt nsec Hottest CPU+PILCaller --- 2896 99% 99% 0.00 3174 cpu[1] i86_mwait 12 0% 100% 0.00 3050 cpu[0] (usermode) 2 0% 100% 0.00 2757 cpu[0] mutex_enter 1 0% 100% 0.00 1944 cpu[1]+11 savectx 1 0% 100% 0.00 1886 cpu[1] cv_broadcast 1 0% 100% 0.00 4440 cpu[1] page_get_mnode_freelist 1 0% 100% 0.00 1777 cpu[1] bt_getlowbit 1 0% 100% 0.00 3452 cpu[0] hwblkpagecopy 1 0% 100% 0.00 3109 cpu[0]+5 ddi_mem_put8 1 0% 100% 0.00 3844 cpu[0] _sys_sysenter_post_swapgs 1 0% 100% 0.00 1414 cpu[0]+2 dtrace_dynvar_clean --- The first command usually returned nothing; I ran it around 10 times until I got that output above. Next, the two at ~50% CPU use: # lockstat -kIW -D 20 sleep 15 Profiling interrupt: 3268 events in 16.849 seconds (194 events/sec) Count indv cuml rcnt nsec Hottest CPU+PILCaller --- 1601 49% 49% 0.00 1098 cpu[1]+9 i86_mwait 781 24% 73% 0.00 881 cpu[0]+4 tsc_read 315 10% 83% 0.00 531420 cpu[0]+4 ddi_getl 245 7% 90% 0.00 871 cpu[0]+4 tsc_gethrtime 136 4% 94% 0.00 864 cpu[0]+4 mul32 83 3% 97% 0.00 860 cpu[0]+4 gethrtime 73 2% 99% 0.00 869 cpu[0]+4 drv_usecwait 8 0% 99% 0.0075265 cpu[1] (usermode) 4 0% 99% 0.00 1023 cpu[1]+9 mutex_delay_default 3 0% 99% 0.00 2278 cpu[0]+4 do_splx 3 0% 100% 0.00 1653 cpu[0] AcpiUtDebugPrint 1 0% 100% 0.00 3645 cpu[1]+9 as_segcompar 1 0% 100% 0.00 1710 cpu[1]+9 avl_find 1 0% 100% 0.00 3877 cpu[1]+9 page_lookup_create 1 0% 100% 0.00 976 cpu[1]+9 default_lock_delay 1 0% 100% 0.00 3036 cpu[1]+9 mutex_enter 1 0% 100% 0.00 3232 cpu[1]+9 inb 1 0% 100% 0.00 1633692 cpu[1]+9 ddi_io_put32 1 0% 100% 0.00 951528 cpu[1]+9 ddi_getw 1 0% 100% 0.00 1419253 cpu[1] ddi_getb --- # lockstat -kIW -f drv_usecwait -s 10 sleep 15 Profiling interrupt: 88 events in 16.823 seconds (5 events/sec) --- Count indv cuml rcnt
Re: [osol-help] OpenSolaris 2009.06 stalls always after some 5 minutes
Hmm, looks like the bge driver is using software interrupts, and I think these could be running at priority level 4. Seems that the bge hardware has some problems, and the driver tries to reset the bge network hardware in an attempt to recover from the bge hardware problem. bge_poll_firmware() could be busy waiting for up to one second; I suspect this could explain the kernel cpu time usage. Are there any error or warning messages logged to /var/adm/messages when the system starts consuming kernel cpu time? Maybe the hang can be avoided when the bge nic driver isn't used and the bge interface is unconfigured / unplumbed? Or the bge nic driver isn't allowed to load, by using the kernel option -B disable-bge=true ? I started at the end, with -B disable-bge=true. The network applet still shows bge0, but it doesn't try to configure it. ifconfig bge0 unplumb says bge0 is no interface, so the kernel option seems to have worked. Lockstat though still shows 98% of i86_mwait at 'sane' state. I checked the /var/adm/messages, but it is so long, and I don't know what I should look for. I tried 'excess' and 'consum', but neither had any hits. What looks strange to me, the layperson in kernel land: Aug 8 22:05:34 OSolUwe mac: [ID 469746 kern.info] NOTICE: bge0 registered Aug 8 22:05:34 OSolUwe pci_pci: [ID 370704 kern.info] PCI-device: pci103c,3...@e, bge0 Aug 8 22:05:34 OSolUwe genunix: [ID 936769 kern.info] bge0 is /p...@0,0/pci8086,2...@1e/pci103c,3...@e Aug 8 22:05:46 OSolUwe genunix: [ID 408114 kern.info] /p...@0,0/pci8086,2...@1e/pci103c,3...@e (bge0) online Aug 8 22:05:47 OSolUwe ip: [ID 856290 kern.notice] ip: joining multicasts failed (4) on bge0 - will use link layer broadcasts for multicast Aug 8 22:05:50 OSolUwe in.ndpd[366]: [ID 169330 daemon.error] Interface bge0 has been removed from kernel. in.ndpd will no longer use it Aug 8 22:05:54 OSolUwe genunix: [ID 408114 kern.info] /p...@0,0/pci8086,2...@1e/pci103c,3...@e (bge0) online At least, I can confirm that now the system keeps running normally; meaning that at least the symptoms have been suppressed by that kernel option. What next? -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] OpenSolaris 2009.06 stalls always after some 5 minutes
Ok, for system cpu time usage: try to run a kernel profile, to find out what kernel functions are consuming the time, lockstat -kIW -D 20 sleep 15 I did one on the machine, and then quickly an ssh and another one in ssh for the screenshot: # lockstat -kIW -D 20 sleep 15 Profiling interrupt: 3074 events in 15.841 seconds (194 events/sec) Count indv cuml rcnt nsec Hottest CPU+PILCaller --- 2430 79% 79% 0.00 2682 cpu[0] i86_mwait 279 9% 88% 0.00 1364 cpu[0]+4 tsc_read 113 4% 92% 0.00 554980 cpu[0]+4 ddi_mem_get32 103 3% 95% 0.00 1437 cpu[0]+4 tsc_gethrtime 53 2% 97% 0.00 1369 cpu[0]+4 mul32 35 1% 98% 0.00 1337 cpu[0]+4 gethrtime 28 1% 99% 0.00 1379 cpu[0]+4 drv_usecwait 11 0% 99% 0.00 4931 cpu[0] (usermode) 4 0% 99% 0.00 2269 cpu[0]+4 do_splx 2 0% 99% 0.00 2306 cpu[1] fsflush_do_pages 2 0% 100% 0.00 279710 cpu[0] ddi_io_getw 1 0% 100% 0.00 2382 cpu[1] as_fault 1 0% 100% 0.00 1887 cpu[1] xsetitimer 1 0% 100% 0.0013510 cpu[1] segvn_lockop 1 0% 100% 0.00 1705 cpu[0] poll_common 1 0% 100% 0.00 4468 cpu[1] syscall_mstate 1 0% 100% 0.00 3378 cpu[1]+11 thread_lock 1 0% 100% 0.00 2526 cpu[1] page_trylock 1 0% 100% 0.00 2103 cpu[1] kstat_compare_bykid 1 0% 100% 0.00 1403 cpu[1]+9 mutex_delay_default --- and 10 seconds later it was completely dead. Does this help, or do you need another one? -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] OpenSolaris 2009.06 stalls always after some 5 minutes
Looks like driver interrupts, on cpu #0, and at IPL 4. What interrupts are bound to cpu 0 / IPL 4, on your machine? This information is printed by echo ::interrupts | mdb -k This is whole lot while 'sane' (close to 0 CPU use): IRQ Vect IPL BusTrg Type CPU Share APIC/INT# ISR(s) 10x41 5 ISAEdg Fixed 1 1 0x0/0x1 i8042_intr 40xb0 12 ISAEdg Fixed 0 1 0x0/0x4 asyintr 70x43 5 ISAEdg Fixed 1 1 0x0/0x7 ecpp_isr 90x81 9 PCILvl Fixed 1 1 0x0/0x9 acpi_wrapper_isr 12 0x42 5 ISAEdg Fixed 0 1 0x0/0xc i8042_intr 14 0x40 5 ISAEdg Fixed 0 1 0x0/0xe ata_intr 15 0x44 5 ISAEdg Fixed 1 1 0x0/0xf ata_intr 16 0x88 9 PCILvl Fixed 1 3 0x0/0x10 drm_irq_handler_wrap, wpi_intr, bge_intr 18 0x84 9 PCILvl Fixed 1 2 0x0/0x12 pcic_intr, uhci_intr 19 0x85 9 PCILvl Fixed 0 2 0x0/0x13 hci1394_isr, uhci_intr 20 0x82 9 PCILvl Fixed 1 2 0x0/0x14 uhci_intr, ehci_intr 21 0x83 9 PCILvl Fixed 0 2 0x0/0x15 audiohd_intr, uhci_intr 22 0x20 1 PCILvl Fixed 0 1 0x0/0x16 sdhost_intr 24 0x86 7 PCIEdg MSI1 1 - pepb_intr_handler 25 0x30 4 PCIEdg MSI0 1 - pepb_intr_handler 26 0x87 7 PCIEdg MSI1 1 - pepb_intr_handler 160 0xa0 0 Edg IPIall 0 - poke_cpu 192 0xc0 13 Edg IPIall 1 - xc_serv 208 0xd0 14 Edg IPIall 1 - kcpc_hw_overflow_intr 209 0xd1 14 Edg IPIall 1 - cbe_fire 210 0xd3 14 Edg IPIall 1 - cbe_fire 240 0xe0 15 Edg IPIall 1 - xc_serv 241 0xe1 15 Edg IPIall 1 - apic_error_intr device | cpu0 %tim cpu1 %tim -+-- ata#1 | 0 0.0 0 0.0 audiohd#0 | 2 0.0 0 0.0 bge#0 | 0 0.059 0.0 ehci#0 | 0 0.0 4 0.0 hci1394#0 | 2 0.0 0 0.0 i915#0 | 0 0.059 0.0 pcic#0 | 0 0.0 2 0.0 uhci#0 | 0 0.0 4 0.0 uhci#1 | 2 0.0 0 0.0 uhci#2 | 0 0.0 2 0.0 uhci#3 | 2 0.0 0 0.0 wpi#0 | 0 0.059 0.1 The latter doesn't change very much once the mess has started, though (this is after the CPU use has bumped to 50%): device | cpu0 %tim cpu1 %tim -+-- ata#0 | 1 0.0 0 0.0 ata#1 | 0 0.0 0 0.0 audiohd#0 | 1 0.0 0 0.0 bge#0 | 0 0.0 2 0.1 ehci#0 | 0 0.0 1 0.0 hci1394#0 | 1 0.0 0 0.0 i915#0 | 0 0.0 2 0.0 pcic#0 | 0 0.0 1 0.0 uhci#0 | 0 0.0 1 0.0 uhci#1 | 1 0.0 0 0.0 uhci#2 | 0 0.0 1 0.1 uhci#3 | 1 0.0 0 0.0 wpi#0 | 0 0.0 2 0.0 Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] OpenSolaris 2009.06 stalls always after some 5 minutes
Yes, it is the Core 2 Duo (isainfo -k: amd64), and it runs in 'SATA Native Mode' disabled. It wouldn't run XP the other way round. Bluetooth is disabled. mdb says: Kernel: 13% ZFS File Data 8% Anon 9% Page cache 2% Free (cachelist) 1% Free 66% Total 3311 Physical 3311 What I observed: the Gnome Resource Applet shows normal values, after around 5 minutes, whatever I do, the CPU will suddenly jump to 50% usage and stay there. Then, and this is also reproducable, the external mouse becomes almost unresponsive, while the touchpad gets 'jumpy' only. Then I have another 2 minutes or so to shut down, or the system will hang 100%. -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] OpenSolaris 2009.06 stalls always after some 5 minutes
Did you have a look at mpstat 1 output before and after the jump to 50% cpu usage? Does it consume user or system cpu time? 100% system time of CPU0 when the CPU usage bumps up to 50%. Before it is around 1-3 % for each CPU. -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] OpenSolaris 2009.06 stalls always after some 5 minutes
I gave OpenSolaris 2009.06 a shot, on an old HP nx6320. Already during the install, it slows down considerably, and got stuck completely. The third effort succeeded finally. Now, after reboot, the system is normal, if not snappy, for a few minutes, then the mouse starts to react slow, that is, it jumps as if it would read the position data once per second, and after a few more minutes it freezes completely: no more keyboard, no more mouse, and it doesn't answer to ping-s any more. Hard reboot, and the same starts all over. Since it is a fresh install from the original CD, I guess, there is a serious problem. The same notebook runs XP and Ubuntu very well; memory test goes through for 24 hours. I have tried an update, which resulted in an 'opensolaris-1' grub entry, and it behaves likewise. It has 4 GB of RAM. Just after boot, 31% thereof are consumes for programs, 0% for cache, by the desktop alone. Is that normal? Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] How to use a fixed IP address?
netstat -r -n will do. It does everywhere, by the way; be it on Linux, Solaris, BSD. Even Windows. When Microsoft copied it, they forgot that on Windows options are usually indicated by '/'. So netstat is completely cross-platform, AFAIK. Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] How do I change the root password?
Hmm. Here (nv107) it works pretty well: # passwd root New Password: Re-enter new Password: passwd: password successfully changed for root Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] After changing Wireless Card, the end?
What does it show at boot? Maybe you should give it 5 minutes at least of no-action before you give up. Here it also tends to stuck for minutes. [Solution? Rip out the by now completely screwed up network settings and rewrite them from scratch. But that's intended for the coders, not for you. A search in the forum will prove that this is a commonly encountered problem and a major stumbling block to wider acceptance.] -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] How do I change the root password?
Don't worry. We all started somehow. Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] VirtualBox Installation Sucessful - But It Won't Start...
The problem is #. Try to run VirtualBox on '$', that is unprivileged! Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] up nv106-nv107 breaks keyboard layout to US
Thanks, Alan! For everyone else, the correct one is this: Section InputDevice Identifier Keyboard0 Driver kbd Option XkbRules xorg Option XkbModel pc105 Option XkbLayout de_CH #Option XkbVariant ch EndSection The driver is 'kbd'; the one I mentioned before was wrong. And I locked myself out with the XkbVariant; this is not supported it seems. With Option XkbLayout de Option XkbVariant ch the keyboard turned dead and I couldn't even shut down properly. Therefore, better do something like % cat /usr/X11/lib/X11/xkb/rules/base | grep ch or likewise with the language of choice to gather the support it gives you. Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] small problem lu 105-106
[i]Doing pkgadd of SUNWdcopy to / 288 blocks Usage: update_drv [ -f | -v ] driver_module update_drv [ -b basedir ] [ -f | -v ] -a [-m 'permission'] [-i 'identify_name'] [-P privilege] [-p 'policy'] driver_module update_drv [ -b basedir ] [ -f | -v ] -d [-m 'permission'] [-i 'identify_name'] [-P privilege] [-p 'policy'] driver_module NOTE: at least one of m/i/P/p must be specified with -a and -d. pkg_drvadd(): Failed update_drv -b /a -i 'pciex8086,1a38 pciex8086,360b pciex8086,402f' ioat! pkgadd: ERROR: postinstall script did not complete successfully Installation of SUNWdcopy failed. pkgadd return code = 1[/i] I wonder how to rectify this one. It seems to be not too grave. Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Upgrade 101-103 breaks all
FYI and fairness: finally it is up. After a ludelete-lucreate-luupgrade snv103 is there. Ni idea, why not in the first place. Some cruft, eventually? Or is the 'old' BE completely wiped at luupgrade? Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Upgrade 101-103 breaks all
Puuh, got it back with single-user and luactivate. Haha. Now it is # lustatus Boot Environment Is Active ActiveCanCopy Name Complete NowOn Reboot Delete Status -- -- - -- -- nv103 yes no noyes- nv101 yes yesyes no - , but at boot the cursor still stands on nv103. Another luactivate will fail, saying 101 is already active. Another argument that liveupgrade is a great idea, but the implementation is a four-letter word starting with 'c'. (Now I am almost afraid to ludelete nv103; wondering what will happen then ...) Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] Upgrade 101-103 breaks all
Again, I need help after a botched upgrade. (I think I did everything correct, though.) After luactivate and init 6 neither old nor new start. Both hang after the third line, the copyright notice. At failsafe, the /dev rotates forever. The only unexpected occurrence was at luactivate (of nv_103), when some 'system/hal' was found to be deficient and put into maintenance state. Any hint appreciated, Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] No install possible on Acer Aspire 4930 - nv_103
No, doesn't. Okay, the ISADIR-removal makes it boot to 32 bits, true. But it still hangs. With 8, it simply hangs. With 4, it dumps core and reboots. With 2, it displays pcplusmp: mod_remove_by_name failed 16, then it hangs. I guess, there's a whole lot of machines acting likewise, as a search in the bugs database will show (e.g. 6293571, 6505915). Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] No install possible on Acer Aspire 4930 - nv_103
Here they are, I guess the last line is most relevant. (all lines copied manually, so no guarantee): SMBIOS loaded cpu0 pseude-device dld0 dld0 is /pseude/[EMAIL PROTECTED] npe0 at root: space 0 offset 0 npeo is /[EMAIL PROTECTED],0 8042 device: [EMAIL PROTECTED], kb6042 # 0 kb80420 is isa/[EMAIL PROTECTED],60/[EMAIL PROTECTED] 8042 device : [EMAIL PROTECTED], mouse8042 #0 mouse80420 is isa/[EMAIL PROTECTED],60/[EMAIL PROTECTED] NOTICE: kernel debugger present: disabling console power management (freeze) Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Upgrade 101-103 breaks all
I have done a few dozen by now, and I guess properly: (This is UFS, I leave out the options, since I can't retrieve them from that machine) lofimount of image 103 to /mnt upgrading liveupgrade20 (in case it has changed) lumake nv99 lurename nv99-nv103 luupgrade nv103 -s/mnt Everything without a hitch here, at least without error message. Then logged off to console umount /mnt and lofi luactivate nv103 init 6 (This, by the way, confirms my suspicions and earlier results (failures at times), that the BEs are not independent. I still consider it a flaw that a liveupgrade touches files of the 'old' BE. Otherwise the former could never break.) Uwe, still hoping for a way to recover the old BE -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Upgrade 101-103 breaks all
I seem to get further with the single user mode boot. Though, from what I can see, there was no error. On the new BE (103) I can find: In upgrade_log: [i] ... Installation of SUNWgtkperf was successful. Doing pkgadd of SUNWgtkspell to / 80 blocks Installation of SUNWgtkspell was successful. Doing pkgadd of SUNWgtkspell-devel to / 61 blocks Installation of SUNWgtkspell-devel was successful. Doing pkgadd of SUNWhermon to / 2688 blocks Installation of SUNWhermon was successful. Doing pkgadd of SUNWhexedit to / 99 blocks Installation of SUNWhexedit was successful. Doing pkgadd of SUNWhpijs to / 11029 blocks Installation of SUNWhpijs was successful. Doing pkgadd of SUNWhxge to / 1102 blocks Installation of SUNWhxge was successful. The messages printed to the screen by this upgrade have been saved to: /a/var/sadm/system/logs/upgrade_log After this system is rebooted, the upgrade log can be found in the file: /var/sadm/system/logs/upgrade_log Please examine the file: /a/var/sadm/system/data/upgrade_cleanup It contains a list of actions that may need to be performed to complete the upgrade. After this system is rebooted, this file can be found at: /var/sadm/system/data/upgrade_cleanup After performing cleanup actions, you must reboot the system. - Environment variables (/etc/default/init) Adding operating system patches to the BE nv103. [/i] And in upgrade_cleanup: [i] --- /etc/gconf/2/path: existing file renamed to /etc/gconf/2/path~11 /var/run/dbus: had been deleted and has now been restored. /sbin/bootadm: existing file renamed to /sbin/bootadm~11 /usr/lib/libc/libc_hwcap2.so.1: existing file renamed to /usr/lib/libc/libc_hwcap2.so.1~11 /usr/share/mime/aliases: existing file renamed to /usr/share/mime/aliases~11 /usr/share/mime/application/ram.xml: existing file renamed to /usr/share/mime/application/ram.xml~11 /usr/share/mime/application/sdp.xml: existing file renamed to /usr/share/mime/application/sdp.xml~11 /usr/share/mime/application/vnd.oasis.opendocument.database.xml: existing file renamed to /usr/share/mime/application/vnd.oasis.opendocument.database.xml~11 /usr/share/mime/application/vnd.oasis.opendocument.formula.xml: existing file renamed to /usr/share/mime/application/vnd.oasis.opendocument.formula.xml~11 /usr/share/mime/application/vnd.oasis.opendocument.graphics-template.xml: existing file renamed to /usr/share/mime/application/vnd.oasis.opendocument.graphics-template.xml~11 /usr/share/mime/application/vnd.oasis.opendocument.graphics.xml: existing file renamed to /usr/share/mime/application/vnd.oasis.opendocument.graphics.xml~11 /usr/share/mime/application/vnd.oasis.opendocument.presentation-template.xml: existing file renamed to /usr/share/mime/application/vnd.oasis.opendocument.presentation-template.xml~11 /usr/share/mime/application/vnd.oasis.opendocument.presentation.xml: existing file renamed to /usr/share/mime/application/vnd.oasis.opendocument.presentation.xml~11 /usr/share/mime/application/vnd.oasis.opendocument.spreadsheet-template.xml: existing file renamed to /usr/share/mime/application/vnd.oasis.opendocument.spreadsheet-template.xml~11 /usr/share/mime/application/vnd.oasis.opendocument.spreadsheet.xml: existing file renamed to /usr/share/mime/application/vnd.oasis.opendocument.spreadsheet.xml~11 /usr/share/mime/application/vnd.oasis.opendocument.text-master.xml: existing file renamed to /usr/share/mime/application/vnd.oasis.opendocument.text-master.xml~11 /usr/share/mime/application/vnd.oasis.opendocument.text-template.xml: existing file renamed to /usr/share/mime/application/vnd.oasis.opendocument.text-template.xml~11 /usr/share/mime/application/vnd.oasis.opendocument.text-web.xml: existing file renamed to /usr/share/mime/application/vnd.oasis.opendocument.text-web.xml~11 /usr/share/mime/application/vnd.oasis.opendocument.text.xml: existing file renamed to /usr/share/mime/application/vnd.oasis.opendocument.text.xml~11 /usr/share/mime/application/vnd.sun.xml.calc.template.xml: existing file renamed to /usr/share/mime/application/vnd.sun.xml.calc.template.xml~11 /usr/share/mime/application/vnd.sun.xml.calc.xml: existing file renamed to /usr/share/mime/application/vnd.sun.xml.calc.xml~11 /usr/share/mime/application/vnd.sun.xml.draw.template.xml: existing file renamed to /usr/share/mime/application/vnd.sun.xml.draw.template.xml~11 /usr/share/mime/application/vnd.sun.xml.draw.xml: existing file renamed to /usr/share/mime/application/vnd.sun.xml.draw.xml~11 /usr/share/mime/application/vnd.sun.xml.impress.template.xml: existing file renamed to /usr/share/mime/application/vnd.sun.xml.impress.template.xml~11 /usr/share/mime/application/vnd.sun.xml.impress.xml: existing file renamed to /usr/share/mime/application/vnd.sun.xml.impress.xml~11 /usr/share/mime/application/vnd.sun.xml.math.xml: existing file renamed to
Re: [osol-help] No install possible on Acer Aspire 4930 - nv_103
Use is subject to license terms. And then it ends. The only thing eventually suspicious: It still says ... 64 bit. If i am not mistaken, my other boxes said 32 bit in the installer, if memory serves right. Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] No install possible on Acer Aspire 4930 - nv_103
That's all I can say. It comes up with the usual first 3 lines (...snv_103...), and then it gets stuck forever. Even Ctrl-Alt-Del doesn't do anything beyond that point. And I have already set the Sata-mode to IDE. Anything else that I could do? Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] No install possible on Acer Aspire 4930 - nv_103
That's all I can say. It comes up with the usual first 3 lines (...snv_103...), and then it gets stuck forever. Even Ctrl-Alt-Del doesn't do anything beyond that point. And I have already set the Sata-mode to IDE. Anything else that I could do? Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] No install possible on Acer Aspire 4930 - nv_103
That's all I can say. It comes up with the usual first 3 lines (...snv_103...), and then it gets stuck forever. Even Ctrl-Alt-Del doesn't do anything beyond that point. And I have already set the Sata-mode to IDE. Anything else that I could do? Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] No install possible on Acer Aspire 4930 - nv_103
That's all I can say. It comes up with the usual first 3 lines (...snv_103...), and then it gets stuck forever. Even Ctrl-Alt-Del doesn't do anything beyond that point. And I have already set the Sata-mode to IDE. Anything else that I could do? Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Un Installation process
[i]How could I un install the OpenSolaris 2008.05? [/i] Even if this sounds snotty: Install another operating system. In case I wanted to use the space for data, I'd boot to Knoppix and fdisk-ed the partition type to 83 or b and did an appropriate mkfs. Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] Upgrade to nv101: no disappointment!
Afetr my first upgrade nv99-nv101 became unusable through one CPU saturating itself with controlling the APIC for the second, and my second upgrade became unusable with an NVRM/nv_open error (both reported and being worked on), my third upgrade was no disappointment: After a proper luactivate and init 6, going through without any sign of problem, I was greeted by a Bad PBR Sig in red. Fortunately, I know how to handle this. Then, immediately after boot, a new problem: pcplusmp: mod_reserve_by_name failed And my earlier multicast problem with bge0 replaced with bge0: DL_DISABMULTI_REQ failed: DL_SYSERR (errno 5) No disappointment here. Third upgrade, third fail. But let's be fair: It is 101, that is the first alpha of the new hundred! Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Support for Realtek 8211cl?
Sure. I hope the attachments will go through. :) Uwe -- This message posted from opensolaris.org dmesg_ud Description: Binary data prtdiag_v_ud Description: Binary data prtconf_Dpv_ud Description: Binary data ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Upgrade nv99-nv101 failed: NVRM/nv_open
[i]But when you boot into nv101 the problem with RmInitAdaptor failed (0x12:0x2b:1636) is reproducible ?? [/i] Yes. [i]That should be the nvidia MSI interrupt problem... Uncommenting AllowMSI=0 in /kernel/drv/nvidia.conf should work around the problem.[/i] Yes. Though, the screen is quite funny initially, with the panel in the vertical center, wrong resolution, and the NVIDIA-server settings telling me about some mistakes MetaMode 2 of Screen 0 is the same as Meta Mode 1.All Meta Modes must be unique. I clicked 'Fix it' then it crashed. When it came back, the panel applet had crashed and wanted me to send a bug report, then I tried again, setting it to 1600x1200, it came up at 1280x1024, and only then I could finally set it to 1600x1200. I'll do some real work before trying the new driver, and report back. Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] Upgrade nv99-nv101 failed: NVRM/nv_open
[tried my luck another time, different box. luupgrade went through successful; though with a flushing-by message of conflicts of sectors or so, it was on command line, so I couldn't recall it.] After reboot, X does not start; it goes in circles: NOTIVE NVRM RmInitAdaptor failed (0x12:0x2b:1636) nv_open: rm_init_adaptor (0) failed. It is a PCIE GeForce 6200 card that seems to fail here. After reboot, this time nv99 starts properly and brings up the display. Uwe, who feels like warning against upgrades to nv101 ;) -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Support for Realtek 8211cl?
Close, but no cigar. # pci bus 0x cardnum 0x09 function 0x00: vendor 0x10de device 0x760 It also shows under prtconf -Dpv as compatible pcide10de, 760.1043.82e2a and a few more ... vendor-id 10de device-id 0760 name 'pci1043.82e2' I added nvidia pci10de,760 to /etc/driver_aliases (btw., your entry is there, at least in nv101!) did the set ip:dohwcksum=0 and sys-unconfig Alas, this ended me at the dreaded Use is Subject to License terms forever, hanging. Reboot, to Failsafe, mounted on /a and vi-ed to remove it. Ha, the misery of Failsafe: it doesn't know my terminal and only allows 'q'. crap is crap is crap. Started from scratch, this time, daring: rge pci10de,760 because actually it is (rge) This got me further, with rge0 coming up, with an IP-address (fixed), but still impossible to work: ether 0:0:0:0:0:0 Last effort: rge pci1043,82e2 Result: the beloved useless boot cycle. [No, I don't see OpenSolaris around in a few years any more. I'd love to, but all this is way too far behind. :( Plugging a Ubuntu 8.04-containing drive, it simply came up. Except of the correct X. Installed on different hardware, it immediately notified me of available online updates.] Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] How to install to OpenSolaris on ZFS and leaving /export untouched?
[This is related to another thread, but to me, in 'Help' for 'discussing difficulties in getting, building and installing OpenSolaris' seems a veritable contender of its own] It was a revelation some 10 years ago to me, that it could be done in Linux: Reinstall the OS from scratch and not touch /home. Even though the Solaris tradition is not necessarily the stand-alone desktop, we are moving there. Can it be done as easily as it ought to be, to make it an extra sales argument? The whole 'restore' is - as far as I can make out - somewhat missing in (Open)Solaris. Again, I don't intend to get hints to Flash-archives or backup here. Rather a restore of an underlying OS, same version, on the very same machine, without touching /export. On ZFS. Can it be done? Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Support for Realtek 8211cl?
No, alas. I hope I did everything okay, but nothing would show. No /dev/rge and no ifconfig -a Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] How to install to OpenSolaris on ZFS and leaving /export untouched?
[i]Is there a current Linux distro that actually configures itself so this can happen? Most of the ones I've seen don't bother.[/i] Mike, does 'Debian' or 'Ubuntu' ring a bell? Both cater for this situation in the text based installer. And surely a few more, that I only haven't tried. I *am* disappointed, this is so obvious to do. And is so obvious a feature needed and useful. [At times I really question the vision of higher management in SUN. Having great engineers doing the groundwork often is not enough for business survival.] [i]Whether any of the current installation scripts are smart enough to let you do so is another question.[/i] What do you mean with 'smart'? I would be even more disheartened if ZFS could only either distroy and recreate a whole pool. Does ZFS not allow to simply dump files to all but a single location, rpool/export? Take heed, I don't talk about *creating* a pool and leaving parts of an old one untouched. I only talk about adding two hooks to the installer script: One that allows the user to keep the existing filesystem/pool for the new installation (and skip the creation), and one that skips the eventual writing of data into /export/home. Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] Support for Realtek 8211cl?
The mainboard is: Asus M3N78 Pro The manual says: Realtek 8211CL Gigabit PHY scanpci essentially is of the opinion: Vendor 0x10de device 0x0760 bvidia Corporation MCP78S [GeForce 8200] Ethernet CardVendor 0x1043 card 0x82e2 snv101 does not find it; so it seems. At least, ifconfig does not mention it. Any chance to download a driver for this card? Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] After luupgrade to nv_101, cannot revert to nv_99
You're very advanced, I don't understand mainly the first sentence. There seems to be no SUNWCXall nor SUNWCall. Could you specify what your proposal entails, please? Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] After luupgrade to nv_101, cannot revert to nv_99
Alas, not. What I get is (I don't know how to copy it, so I used pencil and paper): ZFS 1/6 cannot mount '/export': directory is not empty (6/6) /usr/bin/zfs mount -a failed exit status 1 svc:/system/filesystem/local:default: /lib/svc/method/fs-local failed system /filesystem/local:default failed And when I boot to nv99 failsafe, I get Searching for installed .. ROOT/nv_101 only! But, from nv101: # lustatus Boot Environment Is Active ActiveCanCopy Name Complete NowOn Reboot Delete Status -- -- - -- -- nv_99 yes no noyes- nv_101 yes yesyes no - I have definitively not removed anything, nor deactivated nv_101!! After 6-8 luupgrades, and meticulously following the recipe above, I seem to have hit a snag, another time. luupgrade is really crappy! :( Whatever, this is what I get on nv_99; maybe it can help to recover the situation: # cat /.alt.nv_99/root/vfstab #device device mount FS fsckmount mount #to mount to fsck point typepassat boot options # fd - /dev/fd fd - no - /proc - /proc proc- no - /dev/zvol/dsk/rpool/swap- - swap- no - /devices- /devicesdevfs - no - sharefs - /etc/dfs/sharetab sharefs - no - ctfs- /system/contractctfs- no - objfs - /system/object objfs - no - swap- /tmptmpfs - yes - # cat /.alt.nv_99/root/mount rpool/ROOT/nv_99/ rpool/export/home /export/home rpool /rpool # cat /.alt.nv_99/root/df_h Filesystem size used avail capacity Mounted on rpool/ROOT/nv_99 128G 10.0G48G18%/ /devices 0K 0K 0K 0%/devices /dev 0K 0K 0K 0%/dev ctfs 0K 0K 0K 0%/system/contract proc 0K 0K 0K 0%/proc mnttab 0K 0K 0K 0%/etc/mnttab swap 6.9G 308K 6.9G 1%/etc/svc/volatile objfs0K 0K 0K 0%/system/object sharefs 0K 0K 0K 0%/etc/dfs/sharetab /usr/lib/libc/libc_hwcap2.so.158G 10.0G48G18%/lib/libc.so.1 fd 0K 0K 0K 0%/dev/fd swap 6.9G 0K 6.9G 0%/tmp swap 6.9G20K 6.9G 1%/var/run rpool/export/home 128G60G48G56%/export/home rpool 128G41K48G 1%/rpool Again, luupgrade went through without any trouble, not a single error message, no crash, everything in 'order'. One can only hope and pray, that the future live-upgrade system will provide for 2 completely independent instances. Any hint on how to recover my beloved and only working nv_99 is wellcome! Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] After luupgrade to nv_101, cannot revert to nv_99
I did a - hopefully proper - luupgrade of nv_99 to nv_101; like [i] lofiadm -a /export/home/udippel/Sources/sol-nv-b101-x86-dvd.iso mount -F hsfs /dev/lofi/1 /b sh /b/Solaris_11/Tools/Installers/liveupgrade20 lucreate -n nv_101 luupgrade -u -n nv_101 -s /b umount /b lofiadm -d /dev/lofi/1 luactivate nv_101 init 6 [/i] It went through without a hitch. Now the nv_101 creates a lot of trouble here, so I simply rebooted to nv_99. This now seems anything but healthy, though I shut it down and luactivated properly (see above). This is what it says after it fails mounting the ZFS: [i]svc:/system/filesystem/local:default (local file system mounts) State: maintenance since Mon Nov 03 23:47:31 2008 Reason: Start method exited with $SMF_EXIT_ERR_FATAL. See: http://sun.com/msg/SMF-8000-KS See: /var/svc/log/system-filesystem-local:default.log Impact: 37 dependent services are not running: svc:/system/webconsole:console svc:/system/filesystem/autofs:default svc:/system/system-log:default svc:/milestone/multi-user:default svc:/system/intrd:default svc:/milestone/multi-user-server:default svc:/system/basicreg:default svc:/system/zones:default svc:/application/graphical-login/cde-login:default svc:/application/cde-printinfo:default svc:/network/smtp:sendmail svc:/network/ssh:default svc:/system/dumpadm:default svc:/system/fmd:default svc:/system/sysidtool:net svc:/network/rpc/bind:default svc:/system/sysidtool:system svc:/platform/i86pc/kdmconfig:default svc:/system/postrun:default svc:/network/inetd:default svc:/application/stosreg:default svc:/system/cron:default svc:/application/opengl/ogl-select:default svc:/application/font/fc-cache:default svc:/system/dbus:default svc:/system/filesystem/rmvolmgr:default svc:/system/hal:default svc:/system/avahi-bridge-dsd:default svc:/system/boot-archive-update:default svc:/network/shares/group:default svc:/network/shares/group:zfs svc:/system/xvm/store:default svc:/system/xvm/xend:default svc:/system/xvm/domains:default svc:/system/xvm/console:default svc:/system/xvm/virtd:default svc:/system/sac:default svc:/network/rpc/smserver:default (removable media management) State: uninitialized since Mon Nov 03 23:47:21 2008 Reason: Restarter svc:/network/inetd:default is not running. See: http://sun.com/msg/SMF-8000-5H See: man -M /usr/share/man -s 1M rpc.smserverd Impact: 3 dependent services are not running: svc:/milestone/multi-user-server:default svc:/system/basicreg:default svc:/system/zones:default svc:/network/dns/multicast:default (DNS Service Discovery and Multicast DNS) State: disabled since Mon Nov 03 23:47:22 2008 Reason: Disabled by an administrator. See: http://sun.com/msg/SMF-8000-05 See: man -M /usr/share/man -s 1M mdnsd See: http://opensolaris.org/os/project/nwam/service-discovery/ Impact: 1 dependent service is not running: svc:/system/avahi-bridge-dsd:default [/i] I don't understand anything here, what needs to be done to bring nv_99 back? Uwe -- This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Obscene RAM usage
Here I get (on UFS):
Page SummaryPagesMB %Tot
Kernel 86839 3399%
Anon 162519 634 18%
Exec and libs 27726 1083%
Page cache 31144 1213%
Free (cachelist)48056 1875%
Free (freelist)559054 2183 61%
Total 915338 3575
Physical 915337 3575
Here I get 61% free, with the System Monitor it is 67. Nevermind. I wonder what
kernel would need 350MB?
And on quite another aspect: I run the system as multi-boot with ubuntu, and
there the memory usage with the similar applications open, I get some 15% of
RAM usage, some 20% of cache, and the rest remains free.
Uwe
--
This message posted from opensolaris.org
___
opensolaris-help mailing list
opensolaris-help@opensolaris.org
Re: [osol-help] Luupgrade nv81-nv95 ... fails (after reboot)
There are some other threads in here, but none of them shows a solution, like http://www.opensolaris.org/jive/thread.jspa?messageID=221772 Now I have tried to disable the nvidia in xorg. but to no avail. The probing seems to go on; and started at boot: checking hardware against drivers without considering the config files. Now I have a proposal where someone might be able to help out: How does one uninstall a package in a not-mounted BE? I tried failsave, and pkginfo in /a/, but everything was empty, so that's not the way. Which is the way, please, to tell the starting system that NVDAgraphics is not installed? Thanks, Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Luupgrade nv81-nv95 ... fails (after reboot)
Finally, I found the solution: Boot to Failsafe, enter all necessary commands to get the new Boot Environment mounted. Then # pkgrm -R /a NVDAgraphics # pkgrm -R /a NVDAgraphicsr Then reboot, and it should start relatively normal. Then download the latest 96.43-driver from Nvidia, and install it on a command line session. Thanks to all off-line helpers! Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] snv_95 spontaneously rebooting
Not much of a help here, but my nv95s don't reboot spontaneously. So what I guess, is that the reboot has to make with the running hot. Have you tried to fiddle with the Power Management under Preferences to make it use lower clock cycles? Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Solaris Express build 95 DVD (Single Image)
REPAIRED BUT NOT SOLVED Now the file name and number are okay, but with SDM it still says wrong data size in destination file, like http://opensolaris.org/jive/thread.jspa?threadID=62697 With Mozilla, it seems to come down okay. Uwe :( This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Installing over Solaris on triple boot system??
[i]Other than the installer overwriting grub on the mbr, there shouldn't be any problems.[/i] Yes. Here my usual suggestion: Supergrub (http://www.supergrubdisk.org/), 'find /grub/stage1','root (hd0,n)', 'setup (hd0)' [Read the manual!] Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Browsing a Windows Share?
kebabber, not exactly. Depending on the Windows configuration, one might need to enter a domain, username and password. I know it works with Places-Connect to Server-Windows Share. What I was asking was, how to enter the credentials at browsing the network, identical to browsing from Windows: When using Windows, and a domain/userid is needed, it will pop up a window asking for it. On Solaris, it will subsequently show the share as empty; obvious, since there are no credentials. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] Solaris Express build 95 DVD (Single Image)
Is it really only 467.33 MB of size? I guess I can use some CDs then, from my oversupply. ;) The name on the download page is sol-nv-b95-x86-lang-v1-iso.zip. so this might still be a mistake? Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] Browsing a Windows Share?
[I have tried to search for this, but probably didn't find the good keywords?] I need to browse a Windows Network, so I click on the Network icon, and can go to the respective Domain, where I see all PCs, with their names. When I click one in Windows, I get a username/password prompt. When I do this in OpenSolaris, the machine opens, but the window remains blank (for a good reason, I have not authenticated). Where and how can I enter my credentials in order to access those shares? Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Solaris Express build 95 DVD (Single Image)
[i]I'm trying to download the sparc version using SDM and it tells me I've exceeded my retry attempts[/i] Confirmed, same here. And I never ever downloaded a single SPARC Nevada, and neither B95. Call it an engineering snafu, and one that should not happen to a reputable company like SUN (backup, failover, anyone?). :( This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] Suggestions on xVM
I saw the last movie on Virtualbox on MacWorld, and it looked great! Now I wonder how to actually do it with nv93 as host? I rebooted, to xVM, and got the Virtual Machine Manager running, it looked somewhat similar to the one in the video. I set everything, with ubuntu-8.04-alternate-amd64.iso, full virtualisation. This starts, but not fast. Very slow, actually. Displaying the first boot screen (languages) takes close to 20 seconds, and all subsequent screens are not faster (slower?) than the venerable qemu. 1. What do I do wrong w.r.t. the speed? (Dual Athlon, 4 GB) 2. Why does the Virtual Machine Manager show constantly 94% Memory Usage at Dom-0 as only domain? The System Monitor shows 41%, 0% as cache, for example. 3. When I run qemu (qemu -cdrom ...) as normal user, the screen goes black and the machine reboots. Is this a bug? (I guess, yes) 4. In this operating method, bootadm list-menu is invalid: % bootadm list-menu bootadm: unsupported GRUB slice file (/etc/lu/GRUB_slice) exists - ignoring. The location for the active GRUB menu is: /boot/grub/menu.lst bootadm: menu file not found: /boot/grub/menu.lst Why is this the case, what could be wrong? Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Suggestions on xVM
[Sorry for now mainly talking to myself] With respect to the documentation on VirtualBox (PDF), these were the commands I had to issue: $ gunzip -cd VirtualBox-1.6.2-SunOS_amd64.tar.gz | tar xvf - # pkgadd -G -d VirtualBoxKern-1.6.2-SunOS-r31466.pkg # pkgadd -G -d VirtualBox-1.6.2-SunOS-amd64-r31466.pkg The last gives an error: ## Executing postinstall script. Configuring VirtualBox kernel module... Cannot find module (vboxdrv). Aborting due to attach failure. Creating links... devfsadm: driver failed to attach: vboxdrv Done. I'll keep you updated how I fare ... Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Suggestions on xVM
The mistake was already in the Subject: xVM and Virtualbox seem to be virtually exclusive. Virtualbox only runs when xVM doesn't. The write-up for installing VirtualBox on AMD64 is here: http://forums.virtualbox.org/viewtopic.php?t=8345 Now I am installing ubuntu-8.04-alternate-i386.iso (amd64 doesn't want, but that's minor), and the speed is blazingly fast for a VM. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] wpa2 with Intel 2100b wireless card
Probably you expect a more educated answer. While that is pending, to me it remains unsupported. Alas. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] Changes in /etc/default/su some time?
My latest install, nv93, seems to have an empty /etc/default/su: -rw-r--r-- 1 root sys0 Jun 27 07:10 su Now I wonder, if this is a change, or a mistake? On nv81 it was not empty ... Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] HowTo update with liveupdate?
Step by step ... [i]WARNING: The file contains a list of 2 potential problems (issues) that were encountered while populating boot environment . INFORMATION: You must review the issues listed in and determine if any must be resolved. In general, you can ignore warnings about files that were skipped because they did not exist or could not be opened. You cannot ignore errors such as directories or files that could not be created, or file systems running out of disk space. You must manually resolve any such problems before you activate boot environment . [...] The two problems are: cpio: Error during chown() of /.alt.tmp.b-hR.mnt/dev/zcons/t-zone/masterconsole , errno 22, Invalid argument cpio: Error during chown() of /.alt.tmp.b-hR.mnt/dev/zcons/t-zone/zoneconsole, errno 22, Invalid argument , but that should be okay when you're not running zones ... [/i] Comes from these chaps here: lrwxrwxrwx 1 4294967041 4266395868 -75302090 Jul 27 16:52 masterconsole - ../../../devices/pseudo/[EMAIL PROTECTED]/[EMAIL PROTECTED]:masterconsole lrwxrwxrwx 1 4294967041 sys -75302090 Jul 27 16:52 zoneconsole - ../../../devices/pseudo/[EMAIL PROTECTED]/[EMAIL PROTECTED]:zoneconsole I deleted them, those integer overflows can't be correct. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Changed MBR
On Fri, 18 Jul 2008 08:51:37 -0700, Jason Edwards wrote: My brother recommended I reinstall GRUB. Does this sound doable? No need. Get supergrub. It is one of my most often used tool these days. But you also need to read the man-pages, or better 'info grub' to understand. http://www.supergrubdisk.org/ Uwe ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] How to update an incomplete bug?
Good boy! Except that there is exactly the same situation, and the bug not found. Is your link eventually one pointing to Indiana? This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] How to update an incomplete bug?
Can you just have a nice cuppa or whatnot and relax??! I was simply following the link to file bug reports on the first page of OpenSolaris. If Sun or OpenSolaris put a link on their first page for filing bug reports that is where they expect the submission. At least that is what I'd be doing. If phigamma can pull another link, there is still no good reason to use language link 'complain' and 'blame others' against me. This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] How to update an incomplete bug?
(Maybe this belongs into help or website?) I received some mail that a bug I filed was marked Status: 2-Incomplete Substatus: Need More Info Interestingly enough, there seems to be no way for me to complete it. I don't even know which info is needed or where to send it. The number doesn't show when I search bugs, and the committer was some alpha-numeral, 1-58HAJ7. No wonder, that SUN finds community-building outside of the company itself so cumbersome. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] HowTo update with liveupdate?
SOLVED While I *still* think that one needs to collect items from here or there, I have finally managed to liveupdate *another* machine, also from nv81 to (now) nv93 without any hitch. Everything went through exactly as described in here and elsewhere. On this, the successful, machine there is also not that confusion with the disk controllers, the disk (first SATA) is and remains c1d0, out and over. The answer/explanation on why it failed and fails so miserably on that other machine is still pending, though. Thanks for everyone's input, Uwe P.S.: I found the two resources most helpful: http://developers.sun.com/sxde/upgrade_guide.jsp http://blogs.sun.com/4ctom/entry/live_upgrade_on_my_laptop#comments This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] HowTo update with liveupdate?
I have to add some details: 0. I ludelete-d nv91 # lustatus Boot Environment Is Active ActiveCanCopy Name Complete NowOn Reboot Delete Status -- -- - -- -- nv81 yes yesyes no -# Gone. Gone? 1. After booting to failsafe, the described proposal to upgrade an out of sync boot archive on /dev/dsk/c2d0s4 came up again, I rejected the proposal. A shell came up, I entered 'format', and now two (!?) BEs were on offer: 1 /dev/dsk/c2d0s0 ... snv_81 2 /dev/dsk/c2d0s4 ... snv_91 Makes me wonder how successful the ludelete was!? And I also got further with the strange allocation of disks: 'format' in failsafe offered c0t0d0: the USB-drive with 3 ext3-partitions only c2d0: the SATA drive In nv81 both show as AVAILABLE DISK SELECTIONS: 0. c1d0 DEFAULT cyl 9725 alt 2 hd 255 sec 63 /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 1. c2t0d0 Maxtor-OneTouch-0200 cyl 38911 alt 2 hd 255 sec 63 /[EMAIL PROTECTED],0/pci1565,[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 though. Yes, they are just swapped. Next, I followed skg's advice to turn off the USB-drive. Reboot, and now the out of sync boot archive is on /dev/dsk/c1d0s4! And the 2 boot archives are still there, now on c1d0: 1 /dev/dsk/c1d0s0 ... snv_81 2 /dev/dsk/c1d0s4 ... snv_91 To me, personally, this is quite a mess. How can a SATA controller make it to c0, c1 or c2 just according to the liking of the system (reproduceable, though)? Should we not expect some consistency here? (I personally expect c0 to be the single IDE-controller, c1 to identify the SATA-controller, and c2 to be the USB-controller, for example) And should we not expect a ludelete to delete a boot environment? Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] HowTo update with liveupdate?
[i]DO NOT HIT the RESET button[/i] I don't think there was anything wrong with the Reset-button. I could have entered a 'no', but heaven knows and the BE would have been updated on 'halt'. [i]you shoul dhave said yes, please synchronize for me and thanks btw opensolaris[/i] No, OpenSolaris, no thanks! I don't want any buggy software to write a slice denominator into my BE; one that mount will not be able to find later and subsequently fail to mount; ending with a panic. By now, I have filed a bug report on the erroneous behaviour here. This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] HowTo update with liveupdate?
[i][yes, so the 'failsafe install you achieved above is exactly what you ask for in the second excerpt, by selecting a failsafe boot under Grub, you should be presented with the 'Milestone' menu. then you can select to boot into the BE of choice and end upat a terminal prompt./i] So I tried this, selecting Solaris failsafe at the boot. It said: An out of sync boot archive was detected on /dev/dsk/c2d0s4. The boot archive [...] Do you wish to automatically update this boot archive?[y,n,?] Not knowing what to do (and remembering that last time this was the last thing before the panic, I pressed the hard-reset button; and puuhh, could finally boot back into nv81. Something must be very wrong either with what I am doing or with live_update, that a Failsafe install is complete. ends like this. Again, here is the layout: Specify disk (enter its number): 0 selecting c1d0 Controller working list found [disk formatted, defect list found] Warning: Current Disk has mounted partitions. /dev/dsk/c1d0s0 is currently mounted on /. Please see umount(1M). /dev/dsk/c1d0s1 is currently used by swap. Please see swap(1M). /dev/dsk/c1d0s4 is in use for live upgrade /. Please see ludelete(1M). /dev/dsk/c1d0s7 is currently mounted on /export/home. Please see umount(1M). Again, no typo here, like above: How can format say c1d0s4, while failsafe says c2d0s4?? This must be a bug!!: Specify disk (enter its number): 1 selecting c2t0d0 Total disk size is 38913 cylinders Cylinder size is 16065 (512 byte) blocks Cylinders Partition StatusType Start End Length% = == = === == === 1 Linux native 0 3039430395 78 2 Linux native 30395 364746080 16 3 Linux native 36475 389122438 6 Maybe this is the underpinning of the whole trouble here? Remember, earlier the lucreate would create the BE happily humming along on a non-existing disk /dev/dsk/c0d0s4, though there is simply no master in the primary IDE, and neither does format find any disk. /dev/dsk/c2d0s4 is where the failsafe wants to update a boot archive, while c2d0s4 does not exist. The drives that I am actually using are: Primary IDE, slave: DVD - mounts as /dev/dsk/c0t1d0 First Sata: fixed hard disk - mounts as /dev/dsk/c1d0 USB hard disk - mounts as /dev/dsk/c2t0d0 Could this be the bug that has prevented me from achieving a single proper live_update? Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] HowTo update with liveupdate?
All fine, but not with the messed up disks. Messed up by a bug in Solaris. lucreate wrote to a non-existing drive, and the USB has no swap. Zero. It contains 3 partitions for data only. Read the identifier closely: format says dev/dsk/c1d0 failsafe wants to update the boot archive on /dev/dsk/c2d0 No, there is no other drive, no other BE and no other Solaris- or Linux-swap partition on c2. This shouts to be a bug. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] HowTo update with liveupdate?
@ jabrewer: But I try to upgrade from nv81, and there were some problems telling me that the update was 'partial', see above; and the lucreate also had run into errors. @skg: The new installer offers a single extra slice, s4, only. Also, what I meant is exactly not luactivate nv91 and reboot; because this is where the panic was forthcoming last time. What I meant, and as far as I understand until here, that as long as I don't do luactivate, I can of course lucreate and luupgrade as long as I like, since they don't touch the current BE at all (correct?), there is no fear for loss of the installation. Since I lost my install last time after the luactivate, I had suggested to boot the new BE (nv91) in a virtual environment from my current (and working) BE of nv81. If it panics, I can fdisk that slice (s4), and try again. Once I have luactivate BE nv91, it is too late if it doesn't boot. Thanks for your patience, I think I'll wait for nv92 or nv93, maybe the live_upgrade is going to achieve an error-free upgrade, Uwe, who still considers a HowTo missing; one like we have for zones, or even branded zone, e.g., pointing out step-by-step how to use it. Roman (and me here) had found that we had to assemble the bits and pieces from here or there, with still some questions left unclear. This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] HowTo update with liveupdate?
[i]The lucreate and luupgrade man pages says just about all there is to say, with plenty of examples. [/i] Except, I am too dumb to understand, that is? I never found the need to umount and vi vfstab in there. It says: Note that, for successful completion of an luupgrade opera- tion, the status of a BE must be complete, which it still is not here, it is 'partial'. I do understand and believe that the man-pages as well as the documentation offered by SUN are complete and full of examples. But despite all those specific examples of splitting and merging filesystems amd whatnot, there is not a single one that I could understand and follow through successfully. Before one can make use of a comprehensive list of specific features, one needs to successfully do the standard version; in which I am still failing, for one reason or another. It would be more helpful to point out what went wrong in my previous efforts, respectively in the current one (see above), and the mistakes that I made, the wrong commands, instead of pointing me again and again to the manpages, which I have read up and down. As a system admin on OpenBSD, reading man-pages is something I am very much used to do, by the way. Last time, having read everything, both BEs panicked. I had read the man-pages, but did not (yet) get it done; the version that is supposed to work 'off-the-shelf'. I have learned by now, that 'init 6' and 'reboot' are different in OpenSolaris; which is not the case in Linux. This is probably why I screwed up my earlier effort so that it panicked. This was not in the man-page. Then I learned the trick to umount second_root AND remove it from vfstab. This is not in the man-pages. Those in the know are aware, I am not. So I am collecting all these valuable (and obviously) important gems; and once I have everything together, I will write the HowTo, once I get it done. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] HowTo update with liveupdate?
1. the first thing I'd check is the actual size of the slices, /dev/dsk/c1d0s4 15G 8.7G 5.9G60%/.alt.nv91 1.5 also if you burned the dvd yourself, maybe do a checksum on the original image Of course I did, and it was correct 2. it looks like you had failsafe installed for the new nv91 BE so... not tried this myself No, I didn't. I don't know what this is, and didn't do anything but the commands I found in this thread. you should be able to luactivate nv91 and then boot into the failsafe session. This is exactly what I did last time, with nv81 luupgrade(d) from nv79, when the new BE failed with some panic. But when a luactivate of the old one also resulted in a panic, no more help was forthcoming and I had to reinstall. :( Bitten once, I don't want to play the fool again. This is why I asked for a HowTo in the first place this time around, and followed meticulously, plus the vfstab-umount that was explained in the thread to Roman's question; but not a single keystroke more. And despite of following and documenting all steps and outcomes here, I seem to be heading for another fail. I don't mind deleting the new BE and start from scratch. Having been sysadmin and in FOSS (Linux, BSD) for close to 10 years, I can't believe that liveupdate doesn't work for me, so I don't mind learning. Thanks, Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] HowTo update with liveupdate?
Okay, first part done: # cp /etc/vfstab /etc/vfstab.orig [backup] # vi /etc/vfstab [# at begin of line with /second_root] # umount /second_root/ # lustatus [2 lines with ERROR; that is okay, no boot environment created yet] # lucreate -m /:/dev/dsk/c1d0s4:ufs -c nv81 -n nv91 Discovering physical storage devices Discovering logical storage devices Cross referencing storage devices with boot environment configurations Determining types of file systems supported Validating file system requests Preparing logical storage devices Preparing physical storage devices Configuring physical storage devices Configuring logical storage devices Analyzing system configuration. No name for current boot environment. Current boot environment is named nv81. Creating initial configuration for primary boot environment nv81. The device /dev/dsk/c1d0s0 is not a root device for any boot environment; cannot get BE ID. PBE configuration successful: PBE name nv81 PBE Boot Device /dev/dsk/c1d0s0. Comparing source boot environment nv81 file systems with the file system(s) you specified for the new boot environment. Determining which file systems should be in the new boot environment. Updating boot environment description database on all BEs. Searching /dev for possible boot environment filesystem devices Updating system configuration files. The device /dev/dsk/c1d0s4 is not a root device for any boot environment; cannot get BE ID. Creating configuration for boot environment nv91. Source boot environment is nv81. Creating boot environment nv91. Checking for GRUB menu on boot environment nv91. The boot environment nv91 does not contain the GRUB menu. Creating file systems on boot environment nv91. Creating ufs file system for / in zone global on /dev/dsk/c1d0s4. Mounting file systems for boot environment nv91. Calculating required sizes of file systems for boot environment nv91. Populating file systems on boot environment nv91. Checking selection integrity. Integrity check OK. Populating contents of mount point /. Copying. WARNING: The file /tmp/lucopy.errors.2685 contains a list of 2 potential problems (issues) that were encountered while populating boot environment nv91. INFORMATION: You must review the issues listed in /tmp/lucopy.errors.2685 and determine if any must be resolved. In general, you can ignore warnings about files that were skipped because they did not exist or could not be opened. You cannot ignore errors such as directories or files that could not be created, or file systems running out of disk space. You must manually resolve any such problems before you activate boot environment nv91. Creating shared file system mount points. Copying root of zone t-zone. Creating compare databases for boot environment nv91. Creating compare database for file system /. Updating compare databases on boot environment nv91. Making boot environment nv91 bootable. Updating bootenv.rc on ABE nv91. Population of boot environment nv91 successful. Creation of boot environment nv91 successful. The two problems are: cpio: Error during chown() of /.alt.tmp.b-hR.mnt/dev/zcons/t-zone/masterconsole , errno 22, Invalid argument cpio: Error during chown() of /.alt.tmp.b-hR.mnt/dev/zcons/t-zone/zoneconsole, errno 22, Invalid argument , but that should be okay when you're not running zones ... # lustatus Boot Environment Is Active ActiveCanCopy Name Complete NowOn Reboot Delete Status -- -- - -- -- nv81 yes yesyes no - nv91 yes no noyes- # bootadm list-menu The location for the active GRUB menu is: /boot/grub/menu.lst default 0 timeout 10 0 Solaris Express Community Edition snv_81 X86 1 Solaris xVM 2 Solaris failsafe This shows that after a reboot nv81 will be booted. [default 0 == snv_81] Next I'll try a reboot. This is so exciting, I did almost the same some months ago, and then it didn't boot, and nobody could help me to recover the system. I think I didn't uncomment the second_root in vfstab then, though. And tell me nobody, this was easy and foolproof. I had made a mistake, originally, here: # lucreate -m /:/dev/dsk/c0d0s4:ufs -c nv81 -n nv91 Discovering physical storage devices Discovering logical storage devices Cross referencing storage devices with boot environment configurations Determining types of file systems supported [...] until I noticed my mistake and issued Ctrl-C ;) though there is no c0d0!: # format Searching for disks... The device does not support mode page 3 or page 4, or the reported geometry info is invalid. WARNING: Disk geometry is based on capacity data. The current rpm value 0 is invalid, adjusting it to 3600 done c2t0d0: configured with capacity of 298.07GB AVAILABLE DISK SELECTIONS: 0. c1d0 DEFAULT cyl 9725 alt 2 hd 255 sec 63 /[EMAIL
Re: [osol-help] HowTo update with liveupdate?
Yes, the old one rebooted after lucreate. puh! Then # luupgrade -u -n nv91 -s /media/SOL_11_X86/ [I have no .iso here] Copying failsafe kernel from media. Uncompressing miniroot Uncompressing miniroot archive (Part2) 13371 blocks Creating miniroot device miniroot filesystem is ufs Mounting miniroot at /media/SOL_11_X86//Solaris_11/Tools/Boot Mounting miniroot Part 2 at /media/SOL_11_X86//Solaris_11/Tools/Boot Validating the contents of the media /media/SOL_11_X86/. The media is a standard Solaris media. The media contains an operating system upgrade image. The media contains Solaris version 11. Constructing upgrade profile to use. Locating the operating system upgrade program. Checking for existence of previously scheduled Live Upgrade requests. Creating upgrade profile for BE nv91. Checking for GRUB menu on ABE nv91. Checking for x86 boot partition on ABE. Determining packages to install or upgrade for BE nv91. Performing the operating system upgrade of the BE nv91. CAUTION: Interrupting this process may leave the boot environment unstable or unbootable. Upgrading Solaris: 100% completed Installation of the packages from this media is complete. Deleted empty GRUB menu on ABE nv91. Adding operating system patches to the BE nv91. The operating system patch installation is complete. ABE boot partition backing deleted. Configuring failsafe for system. Failsafe configuration is complete. INFORMATION: The file /var/sadm/system/logs/upgrade_log on boot environment nv91 contains a log of the upgrade operation. INFORMATION: The file /var/sadm/system/data/upgrade_cleanup on boot environment nv91 contains a log of cleanup operations required. WARNING: 2 packages failed to install properly on boot environment nv91. INFORMATION: The file /var/sadm/system/data/upgrade_failed_pkgadds on boot environment nv91 contains a list of packages that failed to upgrade or install properly. INFORMATION: Review the files listed above. Remember that all of the files are located on boot environment nv91. Before you activate boot environment nv91, determine if any additional system maintenance is required or if additional media of the software distribution must be installed. The Solaris upgrade of the boot environment nv91 is partially complete. Installing failsafe Failsafe install is complete. Still, before having to fdisk the whole drive just another time, I considered the problem message: The file /var/sadm/system/data/upgrade_failed_pkgadds on boot environment nv91 contains a list of packages that failed to upgrade or install properly. By now, thanks to your hint 'man live_upgrade', I could easily mount the new BE: # lumount nv91 /.alt.nv91 and read the problem statement: # cat /.alt.nv91/var/sadm/system/data/upgrade_failed_pkgadds SUNWxwplt SUNWmcc # luumount nv91 # Good so far. Next I'd need to know what went wrong with the 2 packages? By the way, I wonder if - with all the virtualisation - we should be able to 'test-boot' a boot environment; be it in VxM, qemu or whatnot. Doesn't need to be fast, not even X, just to get a console. Would save a lot of nerves; and a re-install of everything in case something fails after the luactivate. It is a full BE, so why would this not be feasible? But this is future. Next I need to know what to do about the 'partial luupgrade' that my efforts ended with. This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] HowTo update with liveupdate?
Sorry, but I have no clue. After reading http://www.sun.com/bigadmin/features/articles/live_upgrade.html I have less of a clue, to be honest. http://docs.sun.com/app/docs/doc/820-0178/lucreate-1?l=ena=view is another contender to help me, but it does neither. To me both look rather different, by the way. What I am hoping for, is a practical example for a newbie. I did try the live-upgrade before (I wrote about it here), but it had failed miserably; and I want to have success once in a while. ;) Okay, I do understand this part here: lucreate [-A 'BE_description'] -c BE_name -n BE_name , but fail to understand the rest: -m mountpoint:device[,metadevice]:fs_options [-m ...] Is there any (recent) link on how to upgrade a standard nv_xx install to nv_yy using luupgrade? This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] smserver fails to start
SOLVED! But unconvincing, IMHO. /var/adm/messages is empty /var/svc/log/system-filesystem-local:default.log finally gave the culprit away: me. Several months ago I had - for reasons of simplicity - added an external (to Solaris) filesystem into vfstab, for 'mountall'. And forgotten about it. Then I moved the box one desktop further, did not move the filesystem with it. And then mountall failed, and with it everything else didn't go up neither. Once plugged the filesystem back, everything is okay. Unconvincing, because - I wouldn't expect this misery from some data file system being unattached - I'd expect it to speak out on what the problem is more clearly. Thanks for your help! Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] smserver fails to start
Thanks, I was able to try these [without much comprehension, I concede] % svcs -l smserver .. uninitialized ... svcs -x svc:/network/inetd:default ... Reason: is not running because a method failed ... /var/svc/log/network-inetd:default.log has no entries beyond February 17. The date is correct. So when I issue svcadm restart network/inetd it comes back with the prompt, neither any message nor anything in the log file. svcs | grep inetd offline . svc:/network/inetd:default.log The one on maintenance is svc:/system/filesystem/local:default Does that mean there is a problem with the file system? ifconfig looks good to me, there is a an IP-address, I have plumb-ed ethernet and l0, but no difference to ifconfig -a as before. l0 is there. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] timezone setting different from UTC - how?
I have tried this as much as I could, and did the search, to no avail. I want to run the machine (hardware clock) on UTC (as usual), but the OS is supposed to display the local time (Kuala Lumpur, UTC+8). This works on Linux, XP and OpenBSD. But the nv81 install always displays UTC, and sets the hardware clock back by 8 hours. /etc/rtc_config is correct, though, so I guess: zone_info=Asia/Kuala_Lumpur zone_lag=28800 How can I run the hardware on UTC and still display the proper local time? This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] smserver fails to start
Having used this install for some time, suddenly X does not come up and it says: svc:/network/rpc/smserver:default State uninitialized since .. Reason: Restarter svc:/network/inetd:default is not running See: http:/sun.com/msg/SMF-8000-5H See: man rpc.smserverd 3 dependent services are not running: multi-user-server basicreg zones I followed the instructions, and tried svcs -l service_fmri svcs -x restarter_service_fmri but neither seems to exist What could I do? Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Trouble writing to only dvdrw cd/dvd creator
What happens if you insert a blank disk? A pop-up should show up asking you what you want to do with it. [For some DVDs it did not work for me, and I reported the problem. For others it did pop up; for CD it always showed ...] Does a non-empty disk bring up the files on it? - then we can know if the drive is seen by OpenSolaris. This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Best chipsets for an (Open)Solaris system?
I can't say 'best', but cheapest? NF630a that is it, here. Biostar TF7050-M2; maybe some will cough, but it is also the most energy efficient, at least with the low-TDP AMD CPUs;and this is why I bought it. 1 single chip, supports audio 2.1, NVIDIA-IGP with HDMI, TV-out (on-board); plus a Broadcom RTL 8111B, 1 Gb-LAN; all out of the box nv81. Don't forget to upgrade the BIOS, though. YMMV, Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Upgrading OpenSolaris
Yes, it is working (usually). Yes. Yes.
I did some upgrade from the CD (what do you mean, Live-CD; there is nothing
like that for Nevada), some worked, some didn't. ('Yes, it is working')
luupgrade is supported and presumably working. Though here I lost a complete
install. YMMV. ('Yes')
It does cause headache, 'Yes'.
YPMV (Your Perspective May Vary), from the viewpoint of an ex-Debian-user, that
is an apt-get-junkie, ' Upgrading OpenSolaris' is a dog.
Uwe
This message posted from opensolaris.org
___
opensolaris-help mailing list
opensolaris-help@opensolaris.org
Re: [osol-help] Upgrading OpenSolaris
Yessir!
[Funny, how a no-nothing like me suddenly takes up difficult items ... :)
Hopefully somewhat correct, though]
That is actually the idea of the second root ('/second_root'), but I wouldn't
call it 'rollback'. There is only so much to roll to as the previous version,
that you can boot to instead.
[No, I don't want to have an argument on the topic 'is one previous state a
rollback?']
Uwe
This message posted from opensolaris.org
___
opensolaris-help mailing list
opensolaris-help@opensolaris.org
Re: [osol-help] patchadd on nv81?
Which patch? 120186-15 120186-13 had applied fine, but before I created the zone(s). Alas, I can't patchrm that one, for lack of backout data. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] patchadd on nv81?
[i]The patch does apply with -G, without warnings.[/i] Doesn't. [I don't 'like to have an argument, please!'] patchadd -G /export/home/udippel/Sources/120186-15 results in exactly what I wrote in my first message. Which, incidentally, was copied from there. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Googleearth
On Fri, 07 Mar 2008 15:27:28 -0800, Emmanuel De Paepe wrote: Is there a googleearth version available for Solaris 10 or Solaris Express? Last time I checked, it wasn't. Did you see anything different? I am running it with some effort, the Linux version, on brandz/Centos, AthlonX2, reasonably well. Uwe ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Accessing directories
On Sat, 08 Mar 2008 03:01:18 -0800, Emmanuel De Paepe wrote: When trying to access a directory looking like this: 'Los Angeles' I received this error: too many arguments. It is an 'old' thing; in principle the introduction of 'blank' as allowed character in a filename was about the silliest 'invention' by the respective party ever. Here is why, to prove my point: Imagine, you have a directory containing two files, one one two If you wanted to copy the file 'one' to file 'three', the command is cp one three Fine. Next, you type the command cp one two four Huh? *Nobody* in this world can know, if you wanted to copy file 'one' into file 'two four'; *or* if you wanted to copy file 'one two' into file 'four'. The misery is that the blank is defined to distinguish options/parameters. Once those idiots decided that it is also allowed as characters in file names, the matter became ambiguous. You can still use it, though, but you need to indicate the correct association, and use quotes, like cp one two four or cp one two four. In your case: cd Los Angeles will work. Again, FYI, this has nothing to do with Solaris. At times I need to use the quotes on Windows, BSD, Linux as well. Welcome to the club, Uwe ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] SXDE 79a - GNOME won't start
Congrats! I am still hopelessly trying to get rid of that silly language chooser. How did you manage? With respect to GNOME not starting, you didn't describe *how* you couldn't get GNOME to work; what does it do? If it falls back to the login, then that's a known case and discussed in detail on the nvidia-mailing list, only OpenSolaris remains agnostic. (It dies 100% at change of resolution.) Then you'd download and install the last one that works: 100.14.19 and you'll be fine. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] configuring DNS
Easy. Connect to the Internet through your ISP. If it *is* DHCP, /etc/resolv.conf will contain all the details. Actually, I am not clear on what you want to do. If you are connected and everything is fine, just leave it as is. If you think, you could connect with a fixed IP, chances are, you couldn't. Usually for an end user, the IP address(es) of the DNS are just enough. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Problem booting Solaris Express Developer Edition
[i][Try snv_b81/i] Second this. Do try nv81. I had a similar problem with SXDE0108 on two occasions, and on both nv81 installed perfectly well. SXDE0108 seems choosy on which partitions it wants to install. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Upgrade problems (nv81), again, ending at OS/2 - but install is there?
Thanks. Until here, I seem to be able to have no problems seeing my data. I can mount the updated slice (it even shows the nv81) on s4, I can as well mount HOME on s7. So everything seems to be there. It finds the Solaris-grub, and there I typed (instead of the OS/2 - Rootnoverify as above): kernel /boot/platform/i86pc/kernel/unix -s and it will say [Multiboot elf, , entry=.] module /boot/x86.miniroot-safe [Multiboot-module @ , 0xd352000 bytes] And it shows the grub Solaris splash-screen, so almost all files seem to be available But 'boot' will hang. I used your suggestion '/usr/lib/fs/ufs/mboot', but it doesn't. It shows a lot of strange numbers and backslashes, with some text in between: not found-not found-not found- cant read geometryNo active partitionCant: not found I should really start to understand the Solaris boot process, to know what is going wrong, and which file(s) seem missing. Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] Upgrade problems (nv81), again, ending at OS/2 - but install is there?
[Hi, everyone. Let me start saying that I *love* Nevada! Gradually I'll be moving my boxen to it, one by one. Though I have one question: Would I really be the only one to have one problem after the other at anything related to install (except on a fresh, new hard drive); the only one playing and working with it day-in-day-out; or am I the only one too newbie to know my way around??] Next, I was trying another upgrade, new installer. Everything looked good, no error or warning messages at upgrade, reboot. Up came - OS/2!! on the grub menu. I swear I haven't touched OS/2 for 10 years. Also, there is no single such partition in this house. As commands, there is some rootnoverify and chainloader. I had it in the grub of MBR, earlier. No slightest clue what is going on. So another boot with nv81, and another look at 'upgrade', now it shows Solaris Express snv_78 (S0) Solaris Express snv_81 (S4) Where does it get the version from? Has the upgrade been successful? before it was nv70; only screwing up grub? I have already 'Quit'-ed the installer to check lustatus, but it doesn't seem to be available. For me to learn: How can I boot to the freshly upgraded nv81, eventually updating the bootarchive, and removing the nv78? Where could I find a HowTo do this, e.g. with the installer-DVD? Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Sata VT8237 does not work in nv81
Hi, I have a GA-M51GM-S2G myself, and was surprised about the updates until F13 (I think I started with F2). For a GigaByte, it was flaky w.r.t. RAM at earlier versions. But the Gigabyte isn't what I have it about, it has an NVIDIA chipset, and recognises the SATA drive fine. While my question was referring to another mainboard, with VIA-chipset. This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] Sata VT8237 does not work in nv81
[Yes, I searched and read the archives] When I start the installer (new), to my surprise it doesn't find any hard drive (there is only one, a WD 250 Sata). Knoppix found it, so did XP. I have the OnBoard SATA-IDE enabled. No, I don't want RAID or stuff. Just plain install. The BIOS recognises it as well, automatically (displays as potential BOOT DEVICE in the BIOS). It shows as 'Serial_Ch0 Master WDC WD2500JS-00S SATA 232.88 Hdd'. Any help appreciated, Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] Live-Upgrade to SXDE0108 fails / data loss?
Thanks for on- and offline help! The problem was me being an old Linux-person and to me 'init 6' is exactly identical to 'reboot'. What happened next, I don't know. I do know that all data seemed gone, until I started SXDE again, and exit-ed the installer for a command-line and 'format'. After some lengthy fiddling in there, I actually managed to get the partition layout back using 'verify'-'backup'. Grub is back and offers the choices, old and new. Alas, whatever I try, it would reboot immediately. So I'll google for the update of the boot environment next ... . Another note (bug/enhancement): live-upgrade inevitably overwrites the MBR. So keep a super-grub CD handy to get back to the original MBR in case of chainloading. Though this was the least problem here: I have it handy anytime. This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] boot messages
Just give it a full name in /etc/hosts. [I dunno what is so difficult with this, we've had this problem for ages. IMHHO the install ought to do this out of the box; or solve it any other way.] This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] HowTo move a hard disk with an installation on it to another box ?
[i] Now you can in theory perform a reconfiguration Boot which should regenerate /devices and /etc/Path_to_inst You do this with # touch /reconfigure shutdown -y -g0 -i6 This is kind of what I was hoping for. I'll try next. [/i] Tried, and failed. Thanks anyway, Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] HowTo move a hard disk with an installation on it
to anoth In-Reply-To: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Approved: hK3V2p X-OpenSolaris-URL: http://www.opensolaris.org/jive/message.jspa?messageID=201593tstart=0#201593 [i]transfer that installation to multiple machines? If so, read up on Flash archives: (http://docs.sun.com/app/docs/doc/819-2397/flash-24?l=ena=viewq=flash). This technology in Solaris/OpenSolaris allows you to perform an install and then create an archive that you can deploy to other machines (of the same architecture type). This seems a better fit for what you're trying to do (if I understand you correctly).[/i] Yes, you did. I still think it will be kind of a put-off - aside from the great way to deploy software, which I adore - to the general public. Imagine the mainboard of Joe User (me) dies, and I buy a new one. That requires me to reinstall? That's almost worse than 'Product Activation'. I am sure that there is a better, engineering, solution to it. Finally, the installer also finds whatever it needs. Is is asked too much to include a hook that allows the user to make the system detect the hardware another time? 2 sen This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
[osol-help] Live-Upgrade to SXDE0108 fails / data loss?
Finally, I took the plunge on my main machine to upgrade. Taking my earlier problems and others' suggestions, I made a live-upgrade; exactly as pointed out on the website http://developers.sun.com/sxde/upgrade_guide.jsp I followed meticulously (as far as I know, since I have no experience), read all messages, everything went smoothly. At the end, lustatus showed two boot environments, with the old one being inactive, and the new one marked active. Alas, after the next reboot, I was dropped to the grub command; no good sign. It seems all data got lost, because booting to the SXDE0108-DVD, just for curiosity, did not find any Solaris environment; only a Solaris partition to which an 'Install' was proposed. I quit the installer, and format-fdisk would show the partition, and 'partition' display Part 2 backup 37.24 GB Part 8 boot 7.84 MB Part 9 alternates 15.69 BG I'd really love to recover my data :), and I don't believe that they are actually lost: everything was there before the reboot, including the two boot environments. Probably something was screwed up at reboot, with the partition/slice table damaged. So I hope. Explanation, why this happened? I dunno; maybe has to make with /dev/hda1 being a Linux /boot/, and /dev/hda2 being a partition to hold Nevada, /dev/hda3 being a Nexenta partition? and more partitions higher up being dedicated to the Linux install? Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] upgrade 78 to 81 with problems - help needed with Gnome startup
Closed case. Though I had tried everything to get X back, finally needed to swap in Lars' /etc/passwd, for everything to came up. Now I swapped back in my old /etc/passwd, it reads as it always read: offers /root to 'root', and everything still works perfectly well. Somewhere on the way something remembered some parameter until it was reset, my only explanation. Cruft - or as Lars had put it: don't trust upgrades of alphas. Thanks again for everyone's concern and help! Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
Re: [osol-help] upgrade 78 to 81 with problems - help needed with Gnome startup
Hi, Lars, I might try tomorrow, though I seem to understand that you want to truss the X logon. It does work, and I guess it reads HOME from /etc/passwd. When I run an xterm, env is perfectly well and okay. But also, it is vastly different from real console. The problem of the strange HOME only shows on console. It is my uneducated guess, that the problem creeps up elsewhere, before dtlogin can do a proper job. Meaning, I should revert to /root for 'root' (hoping it will still die as it did), chmod 744 /root to confirm that it is a permission problem, and (if it is) truss the console login instead!? Don't forget that I made two changes in that first line of passwd: 1. HOME of 'root' 2. default shell for root The double-blind test would be if you swapped in my old first line for root, mkdir /root, chown root /root, chmod 700 /root, maybe rebooted, and checked how your fresh install handles the matter. If everything was okay, we'd have to assume cruft of the previous installs (70, 78) in my box. Correct? Uwe This message posted from opensolaris.org ___ opensolaris-help mailing list opensolaris-help@opensolaris.org
