Re: [osol-discuss] failure upgrading from snv_131 to snv_134
James Carlson wrote: > On 03/13/10 22:44, Alan Coopersmith wrote: >> James Carlson wrote: >>> I was able to get to 134 by using "bootadm update-archive" but it looks >>> like I'm going back to 131, because there's a lot that just plain >>> doesn't work right in 134. In particular, "less" and "telnet" seem to >>> be terribly broken -- both just appear to hang unless I press ^J. I >>> expect it's some sort of problem in the GNOME terminal emulator. >> Sounds a lot like the ptmx permissions bug in the release notes actually, >> which is fixable with a simple chmod. >> > > Really? > > The comments in that bug (particularly #26) seem to state that this was > fixed in build 127. That was long ago. I was running build 131 and I > tried to upgrade to build 134. > > How is it that a bug fixed back in build 127 didn't affect me in build > 131 but started affecting me in build 134 ... ? The great renaming brought it back to life in 133: http://defect.opensolaris.org/bz/show_bug.cgi?id=14906 -- -Alan Coopersmith- alan.coopersm...@sun.com Oracle Solaris Platform Engineering: X Window System ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] about zfs exported on nfs
Edward Ned Harvey writes: >> Do you have any linux clients to osol nfs server? >> >> If not Matthias, then is there anyone else here who has an osol NFS >> server with a linux client, where you can show a simple `ls -l' (on >> the client) in a directory created on the mounted nfs share, by a >> linux user. > > I still think my original answer is the answer for you. The only > difference between your system and mine is that my NFS server is > Solaris, and yours is OpenSolaris. Since you said you were confused > by my post, let me try to break it down: But yet you were unwilling to show the output of ls -l from the linux client on a mounted NFS directory.. as I requested, preferring to go into lots of detail about auto mounting. Its not the mounting that is a problem for me, and in the light usage scenario of single user machine, auto mount is not a high requirement... it just isn't an issue. Its what I see with unix permissions on the created files. When your linux users create files on a mounted nfs share, do those files have that users uid gid, or something else? Can you show a `ls -l (from linux client) on a mounted NFS share. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] failure upgrading from snv_131 to snv_134
On 03/13/10 10:06 PM, Steven Stallion wrote: On 03/13/10 22:04, James Carlson wrote: On 03/13/10 22:44, Alan Coopersmith wrote: Sounds a lot like the ptmx permissions bug in the release notes actually, which is fixable with a simple chmod. Really? The comments in that bug (particularly #26) seem to state that this was fixed in build 127. That was long ago. I was running build 131 and I tried to upgrade to build 134. Its still around - I just did an upgrade to snv_132 a couple of nights ago and ran into the same problem. In my case, sshd was complaining bitterly. An upgrade to 132 from any build before 127 would experience the issue. The particular case that bug 12380 is believed to be resolved, and I myself have not encountered since I've used a version of pkg with that fix to upgrade. Cheers, -- Shawn Walker ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] failure upgrading from snv_131 to snv_134
On 03/13/10 10:04 PM, James Carlson wrote: On 03/13/10 22:44, Alan Coopersmith wrote: James Carlson wrote: I was able to get to 134 by using "bootadm update-archive" but it looks like I'm going back to 131, because there's a lot that just plain doesn't work right in 134. In particular, "less" and "telnet" seem to be terribly broken -- both just appear to hang unless I press ^J. I expect it's some sort of problem in the GNOME terminal emulator. Sounds a lot like the ptmx permissions bug in the release notes actually, which is fixable with a simple chmod. Really? The comments in that bug (particularly #26) seem to state that this was fixed in build 127. That was long ago. I was running build 131 and I tried to upgrade to build 134. How is it that a bug fixed back in build 127 didn't affect me in build 131 but started affecting me in build 134 ... ? I'll give it another try, but I'm skeptical, to say the least. Is it really fixed as the many comments in that bug seem to say? I believe it is, but the install you did bypassed the normal upgrade process and so wasn't quite right. I've image-updated every build without issue and without using the workaround. If it is the same symptom, I'd suspect a different cause. Again, I'd suggest trying to remove the /contrib packages first and using image-update. Cheers, -- Shawn Walker ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] failure upgrading from snv_131 to snv_134
On 03/13/10 09:40 PM, James Carlson wrote: On 03/13/10 18:44, Shawn Walker wrote: On 03/13/10 03:10 PM, James Carlson wrote: I just attempted to upgrade my OpenSolaris build 131 AMD64 system to build 134, and failed miserably. Here's what happened: First, since this step is normally required, I tried to do "pkg install SUNWipkg". That didn't work. It failed (after downloading well over 1GB) telling me that I had to use an alternate boot environment due to the nature of the update. Do you have packages from /contrib installed? If so, they have incorrect dependencies which caused the solver to incorrectly attempt to upgrade you to a new build. The solver in b134+ doesn't allow that. The solution is to remove /contrib (or /pending) packages and try again. Hmm. I'd removed those once before. I thought the problem was fixed. No, the /contrib packages still haven't been updated. The solver in b134+ is armored against it, but I think you might still have to remove the packages first. ... I next did (as root; I'm still old school in some respects): beadm create opensolaris-8 beadm mount opensolaris-8 /mnt/tmp pkg -R /mnt/tmp install SUNWipkg Err...not quite right. See FAQ B1: http://hub.opensolaris.org/bin/view/Project+pkg/FAQ That link just hangs. I guess I'll read it another day. All of www.opensolaris.org seems unloadable right now :/ Cheers, -- Shawn Walker ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] about zfs exported on nfs
> Do you have any linux clients to osol nfs server? > > If not Matthias, then is there anyone else here who has an osol NFS > server with a linux client, where you can show a simple `ls -l' (on > the client) in a directory created on the mounted nfs share, by a > linux user. I still think my original answer is the answer for you. The only difference between your system and mine is that my NFS server is Solaris, and yours is OpenSolaris. Since you said you were confused by my post, let me try to break it down: On my solaris NFS server, I don't want to export my filesystem to every single IP address on the LAN. I want only specific clients to be able to access the server. In the example below, I'm allowing "someclient" to access the server. These clients must have matching forward and reverse DNS. You could probably set up for exporting NFS to a subnet if you wanted to, but you'd have to read the "man share" command to figure that out. I have exported my NFS filesystem using the following command: share -F nfs -o rw=someclient.domain.com,root=someclient.domain.com,anon=4294967294 /export To make the "share" command persistent across reboots, just stick it into /etc/dfs/dfstab after you've run it manually once. If you like, instead of using "share" and "dfstab" as described above, you can set the sharenfs property on your ZFS filesystem. It has the same effect, according to "man zfs" If you have a RHEL/Centos 5 client, you have autofs5 installed by default. You can configure automount to automatically mount the NFS server upon attempted access. Here's how: Edit /etc/auto.master and stick this line in: /- /etc/auto.direct --timeout=1200 Also edit /etc/auto.direct and stick this line in: /path/to/mountpoint -fstype=nfs,noacl,rw,hard,intr,posix server.domain.com:/export If you have a RHEL/Centos 4 client, you have autofs4 installed by default, and autofs4 doesn't support "direct" automount as described above. "Direct" automount is much better than what they could do in autofs4, so it's worth while to remove autofs4 and install autofs5 instead. Then, you can use the same "auto.master" and "auto.direct" as described above. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] about zfs exported on nfs
> The Linux host needs to be able to MOUNT the NFS-exported files. > > The /etc/auto.master file is using a later "extension" to the NFS > system, name > "automount". This only mounts directories, when they are accessed, > therefore > "auto-mount". > > You could also add the to-be-mounted diretories into /etc/fstab, so > that they > are mounted ALWAYS. I've had bad experience setting NFS mounts in /etc/fstab. The problem is: If the filesystem can't mount for any reason, then the machine doesn't come up. Unless you set it as a "soft" mount, in which case, the slightest little network glitch causes clients to lose their minds. What I wrote in the previous email, about using automount and hard interruptable NFS mounts was very well thought out and based on years of commercial deployment of NFS systems. Like I said, it's rock solid if configured as I described. It's resilient against network failure during boot, or during operation, yet it's force-interruptable by root if necessary, which is extremely rare. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] failure upgrading from snv_131 to snv_134
On 03/13/10 22:04, James Carlson wrote: On 03/13/10 22:44, Alan Coopersmith wrote: Sounds a lot like the ptmx permissions bug in the release notes actually, which is fixable with a simple chmod. Really? The comments in that bug (particularly #26) seem to state that this was fixed in build 127. That was long ago. I was running build 131 and I tried to upgrade to build 134. Its still around - I just did an upgrade to snv_132 a couple of nights ago and ran into the same problem. In my case, sshd was complaining bitterly. HTH, Steve ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] failure upgrading from snv_131 to snv_134
On 03/13/10 22:44, Alan Coopersmith wrote: > James Carlson wrote: >> I was able to get to 134 by using "bootadm update-archive" but it looks >> like I'm going back to 131, because there's a lot that just plain >> doesn't work right in 134. In particular, "less" and "telnet" seem to >> be terribly broken -- both just appear to hang unless I press ^J. I >> expect it's some sort of problem in the GNOME terminal emulator. > > Sounds a lot like the ptmx permissions bug in the release notes actually, > which is fixable with a simple chmod. > Really? The comments in that bug (particularly #26) seem to state that this was fixed in build 127. That was long ago. I was running build 131 and I tried to upgrade to build 134. How is it that a bug fixed back in build 127 didn't affect me in build 131 but started affecting me in build 134 ... ? I'll give it another try, but I'm skeptical, to say the least. Is it really fixed as the many comments in that bug seem to say? -- James Carlson 42.703N 71.076W ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] failure upgrading from snv_131 to snv_134
James Carlson wrote: > I was able to get to 134 by using "bootadm update-archive" but it looks > like I'm going back to 131, because there's a lot that just plain > doesn't work right in 134. In particular, "less" and "telnet" seem to > be terribly broken -- both just appear to hang unless I press ^J. I > expect it's some sort of problem in the GNOME terminal emulator. Sounds a lot like the ptmx permissions bug in the release notes actually, which is fixable with a simple chmod. -- -Alan Coopersmith- alan.coopersm...@sun.com Oracle Solaris Platform Engineering: X Window System ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] failure upgrading from snv_131 to snv_134
On 03/13/10 18:44, Shawn Walker wrote: > On 03/13/10 03:10 PM, James Carlson wrote: >> I just attempted to upgrade my OpenSolaris build 131 AMD64 system to >> build 134, and failed miserably. Here's what happened: >> >> First, since this step is normally required, I tried to do "pkg install >> SUNWipkg". That didn't work. It failed (after downloading well over >> 1GB) telling me that I had to use an alternate boot environment due to >> the nature of the update. > > Do you have packages from /contrib installed? If so, they have > incorrect dependencies which caused the solver to incorrectly attempt to > upgrade you to a new build. The solver in b134+ doesn't allow that. > > The solution is to remove /contrib (or /pending) packages and try again. Hmm. I'd removed those once before. I thought the problem was fixed. Thanks; I'll have to remember that one for next time. It's a bit of a hurdle. >> I tried doing "pkg image-update", and that failed, telling me that I had >> to install a new SUNWipkg first. That was a bit expected, though >> obviously not possible. > > Use the -f option to ignore the SUNWipkg version check (which is > probably wrong anyway due to the packages above). OK. >> I next did (as root; I'm still old school in some respects): >> >> beadm create opensolaris-8 >> beadm mount opensolaris-8 /mnt/tmp >> pkg -R /mnt/tmp install SUNWipkg > > Err...not quite right. See FAQ B1: > > http://hub.opensolaris.org/bin/view/Project+pkg/FAQ That link just hangs. I guess I'll read it another day. I was able to get to 134 by using "bootadm update-archive" but it looks like I'm going back to 131, because there's a lot that just plain doesn't work right in 134. In particular, "less" and "telnet" seem to be terribly broken -- both just appear to hang unless I press ^J. I expect it's some sort of problem in the GNOME terminal emulator. Too bad. I liked the new log-in screen, and GNOME itself seemed *much* snappier once I was logged in. But I can't stand having the system be unusable for long periods of time or having basic things not work at all. -- James Carlson 42.703N 71.076W ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] about zfs exported on nfs
Matthias Pfützner writes: > So, if user "willi" on the Linux client hat UID 4711, then on the SERVER you > should see "4711" as the owner of a file, that had been created by "willi" on > a filesystems that had been mounted from the server. The server does not need > to know, that 4711 is "willi", it will still create the file with the ID > 4711. That's the basice rule... as long, as the UID is NOT 0 or root... Do you have any linux clients to osol nfs server? If not Matthias, then is there anyone else here who has an osol NFS server with a linux client, where you can show a simple `ls -l' (on the client) in a directory created on the mounted nfs share, by a linux user. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Should OS2010.03 stick to the 2010.03 release date?
> Since a copyright protection does not extend to functionality--I am sure we > all know this, > writing a software implementing the QQ client protocol is not a copyright > violation. Actually, > there is even a QQ client written in java. :-) If there is a QQ client written in Java, then the Java bytecode should run fine on Solaris / OpenSolaris without a recompile, so if tencent wants to encourage people to use QQ then why don't they just put the Java version up for download on their web page and then East Asian OpenSolaris users can download it and use it as their IM client? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-help] Interface pcn0 has been removed from kernel.
> I did port the fbsd driver for this (full gldv3 support, etc.) > http://src.opensolaris.org/source/xref/emancipation/driver-gate/pcn/src/ > > It probably needs to be updated to the latest gldv3 bits (I can't > remember if the gldv3 public interface stuff has been putback yet, but > there were a few interface changes). Since I don't ahve the hardware > (I'm in a small apartment, so I keep my computer equipment limited to > a single desktop and a laptop), I never was able to test it. If > there's interest, I can see what I can do about testing it and getting > it put back (though that means probably having to use the dreaded nic > test suite, so might be a while =]) I have the hardware and can give you console access and whatever else you need. Sort of a replay of the old Sparc disassembler project you did from years ago. Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-help] Interface pcn0 has been removed from kernel.
I did port the fbsd driver for this (full gldv3 support, etc.) http://src.opensolaris.org/source/xref/emancipation/driver-gate/pcn/src/ It probably needs to be updated to the latest gldv3 bits (I can't remember if the gldv3 public interface stuff has been putback yet, but there were a few interface changes). Since I don't ahve the hardware (I'm in a small apartment, so I keep my computer equipment limited to a single desktop and a laptop), I never was able to test it. If there's interest, I can see what I can do about testing it and getting it put back (though that means probably having to use the dreaded nic test suite, so might be a while =]) On Sat, Mar 13, 2010 at 7:03 PM, Dennis Clarke wrote: > >>> >>> When I boot OpenSolaris Development snv_134 X86 >>> livecd I see that message >>> over and over. >>> >>> Here is the whole verbose boot script : >>> >>> module /platform/i86pc/kernel//unix: text at >>> [0xfe80, 0xfe8e783b] data >>> at 0xfec0 >>> module /kernel/genunix: text at [0xfe8e7840, >>> 0xfeacfcd7] data at 0xfec501c0 >>> SunOS Release 5.11 Version snv_134 32-bit >>> Copyright 1983-2010 Sun Microsystems, Inc. All >>> rights reserved. >>> Use is subject to license terms. >>> features: >>> 1001fff>> ,msr,tsc,lgpg> >>> mem = 786044K (0x2ff9f000) >>> Using default device instance data >>> SMBIOS not loaded (System does not export an SMBIOS >>> table)initialized >>> model-specific module 'cpu_ms.GenuineIntel' on chip 0 >>> core 0 strand 0 >>> root nexus = i86pc >>> pseudo0 at root >>> pseudo0 is /pseudo >>> scsi_vhci0 at root >>> scsi_vhci0 is /scsi_vhci >>> . >>> . >>> . a pile of lines later >>> . >>> audioemu10k#0: AC'97 codec id TriTech TR28023 >>> (54524103, 2 channels, caps 0) >>> PCI-device: pci1102,2...@13, audioemu10k0 >>> audioemu10k0 is /p...@0,0/pci1102,2...@13 >>> ISA-device: asy1 >>> asy1 is /p...@0,0/i...@7/a...@1,2f8 >>> /p...@0,0/pci1011,2...@11/pci1000,1...@4 (ncrs1): >>> Rev. 6 Symbios 53c875 found. >>> ce: pci1000,1...@4, ncrs1 >>> ncrs1 is /p...@0,0/pci1011,2...@11/pci1000,1...@4 >>> ATAPI device at targ 0, lun 0 lastlun 0x0 >>> model PIONEER DVD-RW DVR-107D >>> ATA/ATAPI-5 supported, majver 0x3c minver 0x0 >>> feature: (0x66,0x0) failed >>> ATAPI device at targ 1, lun 0 lastlun 0x0 >>> model DVD RW DRU-820A >>> ATA/ATAPI-5 supported, majver 0x3c minver 0x0 >>> ce: i...@0, ata0 >>> ata0 is /p...@0,0/pci-...@7,1/i...@0 >>> /p...@0,0/pci1011,2...@10/pci1000,1...@4 (ncrs0): >>> Rev. 6 Symbios 53c875 found. >>> ce: pci1000,1...@4, ncrs0 >>> ncrs0 is /p...@0,0/pci1011,2...@10/pci1000,1...@4 >>> UltraDMA mode 2 selected >>> MultiwordDMA mode 2 selected >>> Ethernet address = 0:60:b0:fc:14:24 >>> PCI-device: pci103c,1...@5, pcn1 >>> pcn1 is /p...@0,0/pci1011,2...@11/pci103c,1...@5 >>> ISA-device: pit_beep0 >>> pit_beep0 is /p...@0,0/i...@7/pit_beep >>> 8042 device: mo...@1, mouse8042 # 0 >>> mouse80420 is /p...@0,0/i...@7/i8...@1,60/mo...@1 >>> PCI-device: pci103c,1...@5, pcn0 >>> pcn0 is /p...@0,0/pci1011,2...@10/pci103c,1...@5 >>> pseudo-device: llc10 >>> llc10 is /pseudo/l...@0 >>> pseudo-device: lofi0 >>> lofi0 is /pseudo/l...@0 >>> sd0 at ata0: target 0 lun 0 >>> sd0 is /p...@0,0/pci-...@7,1/i...@0/s...@0,0 >>> pseudo-device: power0 >>> power0 is /pseudo/po...@0 >>> pseudo-device: ramdisk1024 >>> ramdisk1024 is /pseudo/ramd...@1024 >>> pseudo-device: ucode0 >>> ucode0 is /pseudo/uc...@0 >>> pseudo-device: zfs0 >>> zfs0 is /pseudo/z...@0 >>> 8042 device: keybo...@0, kb8042 # 0 >>> kb80420 is /p...@0,0/i...@7/i8...@1,60/keybo...@0 >>> sd1 at ata0: target 1 lun 0 >>> sd1 is /p...@0,0/pci-...@7,1/i...@0/s...@1,0 >>> pseudo-device: nvidia255 >>> nvidia255 is /pseudo/nvi...@255 >>> pseudo-device: fcp0 >>> fcp0 is /pseudo/f...@0 >>> pseudo-device: fcsm0 >>> fcsm0 is /pseudo/f...@0 >>> pseudo-device: srn0 >>> srn0 is /pseudo/s...@0 >>> pseudo-device: dtrace0 >>> dtrace0 is /pseudo/dtr...@0 >>> pseudo-device: fasttrap0 >>> fasttrap0 is /pseudo/fastt...@0 >>> pseudo-device: fbt0 >>> fbt0 is /pseudo/f...@0 >>> pseudo-device: lockstat0 >>> lockstat0 is /pseudo/locks...@0 >>> pseudo-device: profile0 >>> profile0 is /pseudo/prof...@0 >>> pseudo-device: sdt0 >>> sdt0 is /pseudo/s...@0 >>> pseudo-device: systrace0 >>> systrace0 is /pseudo/systr...@0 >>> sd18 at ncrs1: target 0 lun 0 >>> sd18 is /p...@0,0/pci1011,2...@11/pci1000,1...@4/s...@0,0 >>> sd20 at ncrs1: target 2 lun 0 >>> sd20 is /p...@0,0/pci1011,2...@11/pci1000,1...@4/s...@2,0 >>> Hostname: opensolaris >>> Remounting root read/write >>> Probing for device nodes ... >>> Preparing live image for use >>> Done mounting Live image >>> >>> Default selected: English >>> USB keyboard >>> Configuring devices. >>> WARNING: No randomness provider enabled for >>> /dev/random. Use cryptoadm(1M) >>> to enable a provider. >>> pseudo-device: fssnap0 >>> fssnap0 is /pseudo/fss...@0 >>> pseudo-device: pool0 >>> pool0 is /pseudo/p...@0 >>> pseudo-device: bpf0 >>> bpf0 is /pseudo/b
Re: [osol-discuss] [osol-help] Interface pcn0 has been removed from kernel.
>> >> When I boot OpenSolaris Development snv_134 X86 >> livecd I see that message >> over and over. >> >> Here is the whole verbose boot script : >> >> module /platform/i86pc/kernel//unix: text at >> [0xfe80, 0xfe8e783b] data >> at 0xfec0 >> module /kernel/genunix: text at [0xfe8e7840, >> 0xfeacfcd7] data at 0xfec501c0 >> SunOS Release 5.11 Version snv_134 32-bit >> Copyright 1983-2010 Sun Microsystems, Inc. All >> rights reserved. >> Use is subject to license terms. >> features: >> 1001fff> ,msr,tsc,lgpg> >> mem = 786044K (0x2ff9f000) >> Using default device instance data >> SMBIOS not loaded (System does not export an SMBIOS >> table)initialized >> model-specific module 'cpu_ms.GenuineIntel' on chip 0 >> core 0 strand 0 >> root nexus = i86pc >> pseudo0 at root >> pseudo0 is /pseudo >> scsi_vhci0 at root >> scsi_vhci0 is /scsi_vhci >> . >> . >> . a pile of lines later >> . >> audioemu10k#0: AC'97 codec id TriTech TR28023 >> (54524103, 2 channels, caps 0) >> PCI-device: pci1102,2...@13, audioemu10k0 >> audioemu10k0 is /p...@0,0/pci1102,2...@13 >> ISA-device: asy1 >> asy1 is /p...@0,0/i...@7/a...@1,2f8 >> /p...@0,0/pci1011,2...@11/pci1000,1...@4 (ncrs1): >> Rev. 6 Symbios 53c875 found. >> ce: pci1000,1...@4, ncrs1 >> ncrs1 is /p...@0,0/pci1011,2...@11/pci1000,1...@4 >> ATAPI device at targ 0, lun 0 lastlun 0x0 >> model PIONEER DVD-RW DVR-107D >> ATA/ATAPI-5 supported, majver 0x3c minver 0x0 >> feature: (0x66,0x0) failed >> ATAPI device at targ 1, lun 0 lastlun 0x0 >> model DVD RW DRU-820A >> ATA/ATAPI-5 supported, majver 0x3c minver 0x0 >> ce: i...@0, ata0 >> ata0 is /p...@0,0/pci-...@7,1/i...@0 >> /p...@0,0/pci1011,2...@10/pci1000,1...@4 (ncrs0): >> Rev. 6 Symbios 53c875 found. >> ce: pci1000,1...@4, ncrs0 >> ncrs0 is /p...@0,0/pci1011,2...@10/pci1000,1...@4 >> UltraDMA mode 2 selected >> MultiwordDMA mode 2 selected >> Ethernet address = 0:60:b0:fc:14:24 >> PCI-device: pci103c,1...@5, pcn1 >> pcn1 is /p...@0,0/pci1011,2...@11/pci103c,1...@5 >> ISA-device: pit_beep0 >> pit_beep0 is /p...@0,0/i...@7/pit_beep >> 8042 device: mo...@1, mouse8042 # 0 >> mouse80420 is /p...@0,0/i...@7/i8...@1,60/mo...@1 >> PCI-device: pci103c,1...@5, pcn0 >> pcn0 is /p...@0,0/pci1011,2...@10/pci103c,1...@5 >> pseudo-device: llc10 >> llc10 is /pseudo/l...@0 >> pseudo-device: lofi0 >> lofi0 is /pseudo/l...@0 >> sd0 at ata0: target 0 lun 0 >> sd0 is /p...@0,0/pci-...@7,1/i...@0/s...@0,0 >> pseudo-device: power0 >> power0 is /pseudo/po...@0 >> pseudo-device: ramdisk1024 >> ramdisk1024 is /pseudo/ramd...@1024 >> pseudo-device: ucode0 >> ucode0 is /pseudo/uc...@0 >> pseudo-device: zfs0 >> zfs0 is /pseudo/z...@0 >> 8042 device: keybo...@0, kb8042 # 0 >> kb80420 is /p...@0,0/i...@7/i8...@1,60/keybo...@0 >> sd1 at ata0: target 1 lun 0 >> sd1 is /p...@0,0/pci-...@7,1/i...@0/s...@1,0 >> pseudo-device: nvidia255 >> nvidia255 is /pseudo/nvi...@255 >> pseudo-device: fcp0 >> fcp0 is /pseudo/f...@0 >> pseudo-device: fcsm0 >> fcsm0 is /pseudo/f...@0 >> pseudo-device: srn0 >> srn0 is /pseudo/s...@0 >> pseudo-device: dtrace0 >> dtrace0 is /pseudo/dtr...@0 >> pseudo-device: fasttrap0 >> fasttrap0 is /pseudo/fastt...@0 >> pseudo-device: fbt0 >> fbt0 is /pseudo/f...@0 >> pseudo-device: lockstat0 >> lockstat0 is /pseudo/locks...@0 >> pseudo-device: profile0 >> profile0 is /pseudo/prof...@0 >> pseudo-device: sdt0 >> sdt0 is /pseudo/s...@0 >> pseudo-device: systrace0 >> systrace0 is /pseudo/systr...@0 >> sd18 at ncrs1: target 0 lun 0 >> sd18 is /p...@0,0/pci1011,2...@11/pci1000,1...@4/s...@0,0 >> sd20 at ncrs1: target 2 lun 0 >> sd20 is /p...@0,0/pci1011,2...@11/pci1000,1...@4/s...@2,0 >> Hostname: opensolaris >> Remounting root read/write >> Probing for device nodes ... >> Preparing live image for use >> Done mounting Live image >> >> Default selected: English >> USB keyboard >> Configuring devices. >> WARNING: No randomness provider enabled for >> /dev/random. Use cryptoadm(1M) >> to enable a provider. >> pseudo-device: fssnap0 >> fssnap0 is /pseudo/fss...@0 >> pseudo-device: pool0 >> pool0 is /pseudo/p...@0 >> pseudo-device: bpf0 >> bpf0 is /pseudo/b...@0 >> pseudo-device: lx_systrace0 >> lx_systrace0 is /pseudo/lx_systr...@0 >> pseudo-device: winlock0 >> winlock0 is /pseudo/winl...@0 >> pseudo-device: nsmb0 >> nsmb0 is /pseudo/n...@0 >> pseudo-device: pm0 >> pm0 is /pseudo/p...@0 >> Reading ZFS config: done. >> >> opensolaris console login: Mar 12 05:02:43 >> opensolaris pseudo: >> pseudo-device: devinfo0 >> Mar 12 05:02:43 opensolaris genunix: devinfo0 is >> /pseudo/devi...@0 >> Mar 12 05:02:43 opensolaris rootnex: xsvc0 at root: >> space 0 offset 0 >> Mar 12 05:02:43 opensolaris genunix: xsvc0 is >> /x...@0,0 >> Mar 12 05:02:44 opensolaris pseudo: pseudo-device: >> srn0 >> Mar 12 05:02:44 opensolaris genunix: srn0 is >> /pseudo/s...@0 >> Mar 12 05:02:48 opensolaris in.ndpd[1457]: Interface >> pcn0 has been removed >> from kernel. in.ndpd will no longer use it >> >> opensola
Re: [osol-discuss] Question about Kernel Debugger Mode
On Sat, Mar 13, 2010 at 5:07 PM, Jeff Freeman wrote: > Wondering is there a way to create a pool from the debugger mode? I deleted > my /dev/zvol/rdsk/rpool/dump directory and the server won't complete the boot > - just keeps rebooting. I also don't have access to a live cd at our NOC as > of yet - jus trying to see if there was a way before the cd gets there. I'm > using opensolaris 2009.06 Perhaps you can change your boot arguments in grub to include "-m milestone=none", then move /etc/dumpadm.conf aside. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] failure upgrading from snv_131 to snv_134
On 03/13/10 03:10 PM, James Carlson wrote: I just attempted to upgrade my OpenSolaris build 131 AMD64 system to build 134, and failed miserably. Here's what happened: First, since this step is normally required, I tried to do "pkg install SUNWipkg". That didn't work. It failed (after downloading well over 1GB) telling me that I had to use an alternate boot environment due to the nature of the update. Do you have packages from /contrib installed? If so, they have incorrect dependencies which caused the solver to incorrectly attempt to upgrade you to a new build. The solver in b134+ doesn't allow that. The solution is to remove /contrib (or /pending) packages and try again. I tried doing "pkg image-update", and that failed, telling me that I had to install a new SUNWipkg first. That was a bit expected, though obviously not possible. Use the -f option to ignore the SUNWipkg version check (which is probably wrong anyway due to the packages above). I next did (as root; I'm still old school in some respects): beadm create opensolaris-8 beadm mount opensolaris-8 /mnt/tmp pkg -R /mnt/tmp install SUNWipkg Err...not quite right. See FAQ B1: http://hub.opensolaris.org/bin/view/Project+pkg/FAQ Is this a known problem? Did I do something wrong during the upgrade? What should I have done to recover? Should I file a bug? If so, what sort of information would be helpful in diagnosing the failure? See above. Cheers, -- Shawn Walker ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Question about Kernel Debugger Mode
Wondering is there a way to create a pool from the debugger mode? I deleted my /dev/zvol/rdsk/rpool/dump directory and the server won't complete the boot - just keeps rebooting. I also don't have access to a live cd at our NOC as of yet - jus trying to see if there was a way before the cd gets there. I'm using opensolaris 2009.06 -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] When system crashes, how to get log / crash info for troubleshooting
On 03/14/10 11:01 AM, Jeff Freeman wrote: Hi there - I have an almost similar situation in that I did have a panic - I thought that in /dev/zvol/rdsk the dump directory want empty so I deleted it. My system now reboots - I am trying to get a Live CD inserted so I can get back into the system. My question is - is it just a matter of recreating this /dev/zvold/rdsk/rpool/dump directory again? The dump volume would have been a ZFS volume: zfs list -r -t volume rpool NAME USED AVAIL REFER MOUNTPOINT rpool/dump 3.00G 571G 3.00G - rpool/swap 3.18G 575G 110M - So you should try and delete it and then recreate it: pfexec zfs destroy rpool/dump pfexec zfs create -V 4G rpool/dump -- Ian. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] When system crashes, how to get log / crash info for troubleshooting
Hi there - I have an almost similar situation in that I did have a panic - I thought that in /dev/zvol/rdsk the dump directory want empty so I deleted it. My system now reboots - I am trying to get a Live CD inserted so I can get back into the system. My question is - is it just a matter of recreating this /dev/zvold/rdsk/rpool/dump directory again? I'm using OpenSolaris 2009.06 -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Marvell 9128
Hi... is the Marvell 9128 chip supported in OpenSolaris? I looked around the HCL but didn't find any instance of it. Matt -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] failure upgrading from snv_131 to snv_134
I just attempted to upgrade my OpenSolaris build 131 AMD64 system to build 134, and failed miserably. Here's what happened: First, since this step is normally required, I tried to do "pkg install SUNWipkg". That didn't work. It failed (after downloading well over 1GB) telling me that I had to use an alternate boot environment due to the nature of the update. I tried doing "pkg image-update", and that failed, telling me that I had to install a new SUNWipkg first. That was a bit expected, though obviously not possible. I next did (as root; I'm still old school in some respects): beadm create opensolaris-8 beadm mount opensolaris-8 /mnt/tmp pkg -R /mnt/tmp install SUNWipkg That more or less worked, with a lot of errors about trouble installing "(clone)" drivers -- something that's apparently a known problem and can be safely ignored. No other errors were seen. I next did: beadm unmount opensolaris-8 beadm activate opensolaris-8 reboot That was a bad idea. This is a picture of the screen that greeted me after a fast reboot: http://www.workingcode.com/p1030100.jpg I rebooted a couple more times, hoping that a slow reboot would get it. No dice. It wouldn't boot. And OpenSolaris has no "failsafe" option, so I didn't know what to do. I ended up going back to the previous (build 131) BE. That's where I'm stuck now. I googled the messages, and come up with a few postings by other folks who'd seen this problem, but all were old (build 128 or older) and didn't seem to address this scenario. Is this a known problem? Did I do something wrong during the upgrade? What should I have done to recover? Should I file a bug? If so, what sort of information would be helpful in diagnosing the failure? -- James Carlson 42.703N 71.076W ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris 2010.03 improvements?
I think that I read somewhere that Firefox 3.6 will be included in a branch after 2010.03 is released but not before, because I think that 3.6.2 is about to be released. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris 2010.03 improvements?
Other question I'll leave to others, but certainly on b134 I see Firefix 3.5.8 and Thunderbird 3.0.x. Karel -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] about zfs exported on nfs
You (Harry Putnam) wrote: > Matthias Pfützner > writes: > > > Harry, > > > > all very bizarre... ;-) > > Probably do to ill informed bumbling on my part. > > [...] > > >> > What's the output of: > >> > > >> > ls -ld /export/home/reader > >> > > >> > Does that resolve and list the user-name and group-name? > >> > >> yes, well no. > >> > >> I've found what may explain some of this... it appears somewhere in > >> the last few updates on client... my carefully hand edited gid has > >> disappeared. > > > > Strange! I don't know of any automated tool, that would edit either > > /etc/passwd or /etc/group... > > I should have said `reinstall' instead of `upgrade' (on client). There > was a full `from scratch' reinstall, so basic stuff was reset to > default and haven't gotten it all back together yet. Still finding > things I had setup but forgotten about. > > Somewhere on these opensolaris lists (mnths ago), I was told that I > needed a user with same uid gid on both server and client for NFS to > work well but I'm not seeing that anywhere in share_nfs. You need the SAME entries on Client and Server in "/etc/passwd" and "/etc/group" so, that it works "correctly" (meaning, the way you want it). Still, EVEN without the entries on the server, sou should at least see the correct UIG and GID when doing an ls -al on the SERVER. No need to have the "strings" in /etc/passwd or /etc/group, the NFS server does not need to KNOW about those... share_nfs does not need to and will not show these user ids... So, if user "willi" on the Linux client hat UID 4711, then on the SERVER you should see "4711" as the owner of a file, that had been created by "willi" on a filesystems that had been mounted from the server. The server does not need to know, that 4711 is "willi", it will still create the file with the ID 4711. That's the basice rule... as long, as the UID is NOT 0 or root... > [...] > > > Back to NVS v4 vs. v3. I've no idea, on how Linux does define the > > version, you mentioned, it's been done in a config file, and that > > you did set that to be v3. > > Thanks again for your patience. You're welcome! > I'm not sure either (about nfs on linux) but am checking into that > now. Matthias -- Matthias Pfützner | Tel.: +49 700 PFUETZNER | Wenn die Materie nichts Lichtenbergstr.73 | mailto:matth...@pfuetzner.de | ist, dann sind wir D-64289 Darmstadt | AIM: pfuetz, ICQ: 300967487 | Materialisten. Germany | http://www.pfuetzner.de/matthias/ | Pier Paolo Pasolini ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] about zfs exported on nfs
Matthias Pfützner writes: > Harry, > > all very bizarre... ;-) Probably do to ill informed bumbling on my part. [...] >> > What's the output of: >> > >> > ls -ld /export/home/reader >> > >> > Does that resolve and list the user-name and group-name? >> >> yes, well no. >> >> I've found what may explain some of this... it appears somewhere in >> the last few updates on client... my carefully hand edited gid has >> disappeared. > > Strange! I don't know of any automated tool, that would edit either > /etc/passwd or /etc/group... I should have said `reinstall' instead of `upgrade' (on client). There was a full `from scratch' reinstall, so basic stuff was reset to default and haven't gotten it all back together yet. Still finding things I had setup but forgotten about. Somewhere on these opensolaris lists (mnths ago), I was told that I needed a user with same uid gid on both server and client for NFS to work well but I'm not seeing that anywhere in share_nfs. [...] > Back to NVS v4 vs. v3. I've no idea, on how Linux does define the > version, you mentioned, it's been done in a config file, and that > you did set that to be v3. Thanks again for your patience. I'm not sure either (about nfs on linux) but am checking into that now. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] More about sharenfs - how to designate options
Simply put: You don't need the "on" option, if you specify any other options, the other options implicitly then assume "on", so simply remove the "on" option... You (Harry Putnam) wrote: > I'm not coming up with the right syntax after looking at share_nfs man > page, to give options to sharenfs besides `on' > > The man page claims options are delineated by a comma. > > -o specific_options > > Specify specific_options in a comma-separated list of > keywords and attribute-value-assertions for interpreta- > tion by the file-system-type-specific command. If > specific_options is not specified, then by default shar- > ing is read-write to all clients. specific_options can > be any combination of the following: > > But using zfs set it seems not to work. > > For example these fail: > > zfs set sharenfs=on,r...@somehost.xxx.xxx.xxx z3/projects > zfs set sharenfs=on=r...@somehost.xxx.xxx.xxx z3/projects > zfs set sharenfs=on,root=SOMEHOST.xxx.xxx.xxx z3/projects > > All give the error: > `cannot set property for 'z3/projects': 'sharenfs' cannot be set to > invalid options' > > Whats the gimmick here... its being discussed elsewhere about how the > the fqdn is required, but I haven't actually seen a full example > `zfs set' cmd showing the syntax for giving more options to > `sharenfs=on'. > > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > -- Matthias Pfützner | Tel.: +49 700 PFUETZNER | I'm not holding my breath Lichtenbergstr.73 | mailto:matth...@pfuetzner.de | for reliable voice D-64289 Darmstadt | AIM: pfuetz, ICQ: 300967487 | recognition. Germany | http://www.pfuetzner.de/matthias/ | Ted Nelson ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] about zfs exported on nfs
Harry, all very bizarre... ;-) You (Harry Putnam) wrote: > Matthias Pfützner > writes: > > > Harry, > > > > sorry for my first answer, now that you rephrased some of the > > original post, I now remember, what your initial problam really > > was... More inline below... > > It may not have been or still may not be much of a clear exposition on > my part either... > > [...] > > > OK, so that ROOT can chnage things, you need to add options to the > > EXPORT side (aka, the ZFS server) > > [...] > > > zfs set sharenfs=ro...@192.168.2 pfuetz/smb-share > > Thanks for that. You're welcome! > > So, with that knowledge, we need to consult "man share_nfs": > > > > The things interesting to you might be the following options: > > > > anon=uidSet uid to be the effective user ID > > of unknown users. By default, > > unknown users are given the effec- > > tive user ID UID_NOBODY. If uid is > > set to -1, access is denied. > > > > root=access_listOnly root users from the hosts > > specified in access_list have root > > access. See access_list below. By > > default, no host has root access, so > > root users are mapped to an > > anonymous user ID (see the anon=uid > > option described above). Netgroups > > can be used if the file system > > shared is using UNIX authentication > > ( AUTH_SYS). > > Not really. After more careful reading of share_nfs, mainly as an aid > to working with your posts and info, I'm thinking the defaults should > do just about all I need. Agreed! Accept, possibly, if needed, the "root" option might be handy... > I brought up roots inability on client, to change uid:gid but only > because the defaults appear not to be working. For example: > > nosuid > >=> By default, clients are allowed to create files on >=> the shared file system with the setuid or setgid >=> mode enabled. Specifying nosuid causes the server >file system to silently ignore any attempt to enable >the setuid or setgid mode bits. > > With emphasis on the arrowed lines (not on `nosuid'). Right! > Its very possible I'm reading that wrong but it appears to be saying > the client machine users will be able to write files with there own > uid:gid. Right! > That does not occur here. All files are written nobody:nobody Strange! > [...] > > >> And again, the USER:GID exists on both server and client with > >> the same numeric uid:gid: > >> > >> osol (server) host: > >> > >> uname -a > >> SunOS zfs 5.11 snv_133 i86pc i386 i86pc Solaris > >> > >> root # ls -lnd /export/home/reader > >> drwxr-xr-x 60 1000 10 173 2010-03-11 12:13 /export/home/reader > > On closer checking I see the above info is erroneous/. Even stranger... ;-) > > Which "ls" command? /usr/gnu/bin/ls, or /usr/bin/ls? Still: Here we see, > > that > > the file had been created by a user with User-ID: 1000 and Group-ID: 10. > > A default osol install leaves gnu tools first in the path so it was > gnu `ls' I posted. Right! I only asked, because, if you would be using "sharesmb" also, then files created via Windows Servers will be nobody:nobody regardless, and all "access info" is captured in ACLs, and gnu ls simply does not show these ACLs... You need the Solaris native "ls" to see them... > > What's the output of: > > > > ls -ld /export/home/reader > > > > Does that resolve and list the user-name and group-name? > > yes, well no. > > I've found what may explain some of this... it appears somewhere in > the last few updates on client... my carefully hand edited gid has > disappeared. Strange! I don't know of any automated tool, that would edit either /etc/passwd or /etc/group... > There was a point whereas neither users default gid matched but each > belonged to group `wheel', which had been hand edited to match. > > So there was a shared gid on both ends. That is no longer the case. > Not sure why. > > But even then the share_nfs man page seems to indicate that the client > users will write files to there own gid (there is no mention of > matching gid on both ends) You're right again! Back to NVS v4 vs. v3. I've no idea, on how Linux does define the version, you mentioned, it's been done in a config file, and that you did set that to be v3. Are you sure, that the Linux box does HONOUR that setting? Or might it be the case, that that is ignored, (perhaps root or daemon or ... can't read it at boot time) On Solaris, you would force that in /etc/default/nfs (see "man nfs"), still, that file needs to be readable at boot
[osol-discuss] OpenSolaris 2010.03 improvements?
Can anyone please tell me what the main improvements are for the upcoming OpenSolaris 2010.03, I don't just mean actual features but also updated programs. For example, what version of Firefox/Thunderbird, OpenOffice.org and VLC will be included? I know I can download developer snapshots but I'd rather wait for the GA release since it's scheduled for the 26th of this month. Thanks on advance :) -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
