Re: [OpenIndiana-discuss] virtio
I'll check this ;) Virtio is a paravirtual driver that allows you to run network at higher speed inside a VirtualBox. Instead of emulating a real network card, you can instruct VirtualBox to use virtio and the VM will use that driver. I tested on a Linux VM (that has virtio as default) and it performs almost 10 times faster. Thanks for the suggestion, I'll check it! Gabriele. -- Da: Paolo Marcheschi A: Discussion list for OpenIndiana Data: 27 ottobre 2011 17.30.12 CEST Oggetto: Re: [OpenIndiana-discuss] virtio Hi first I do not know what virtio is, but, if you download the source it compiles fine inside openindiana oi_151a just : sudo pkg install pkg:/SUNWonbld and do a gmake inside the three folders. After that I do not know, how to make it work. ;-( Paolo On October 27, 2011 04:34:27 PM CEST, Gabriele Bulfon wrote: Hi, I've seen a virtio conversion for IllumOS here: https://github.com/xl0/illumos-virtio compiling sources is based on onbld, so I was looking for a precompiled binary. Where can I find it? Is it safe to use it already? Will it work on OpenIndiana? Gabriele. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] e2fsprogs header file bug
Good day.
In which bug tracker I must create a bug report for this issue?
(Cite from: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=45491)
The problem is that on OI-151 EXT2_IOC_GETFLAGS is defined as
_IOR('f', 1, long)
where _IOR is defined in drm/drm.h which is not included.
To me this looks like a bug in OpenIndiana.
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] About auto snapshots
On 10/27/11 18:17, Harry Putnam wrote: > I couldn't find any better way to capture those messages (taking place > on a Virtualbox install of oi 151) than a screen shot so have attached > it below, I hope it is visible enough to read: The messages say that you should run "svcs -xv", and then examine the log files that the system tells you about in the svcs output. What happened when you did that? -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] log messages from failed time-slider daemon
On 10/27/11 18:34, Harry Putnam wrote: > Note that top line about `crontab'. Is that the reason for the > subsequent failures? It appears to be. > What is going on that requires crontab to be read? And what might make > it not open.. permissions? The script this service runs modifies crontab entries (yecch!). Not opening could be due to user modification of the time-slider service itself, bad permissions somewhere, or a read-only file system. Try: ls -ld /var/spool/cron/crontabs df /var/spool/cron/crontabs > Is this the root crontab, or would it be a user crontab?... there is > so little information in the log output its not really possible to > figure much from it. It looks like the root crontab. Something is definitely strange on your system. If you do this: pfexec su - root crontab -l > /tmp/root.cron crontab /tmp/root.cron what happens? -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
On 10/28/11 06:45, Andrey N. Oktyabrski wrote:
> Good day.
>
> In which bug tracker I must create a bug report for this issue?
>
> (Cite from:
> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=45491)
>
> The problem is that on OI-151 EXT2_IOC_GETFLAGS is defined as
>
>
> _IOR('f', 1, long)
>
>
> where _IOR is defined in drm/drm.h which is not included.
> To me this looks like a bug in OpenIndiana.
At a guess, I suspect that what's going on here is that you have a
/usr/include/ext2/fs.h that's delivered by libparted, and this other
software is "assuming" that if this file is present, then all things in
it must work and it must correspond to a kernel feature.
I think that's a bit of a brash assumption on the part of the author of
that libarchive software. Just because you troll through /usr/include
and find a file there does not automatically mean it'll do what you
think it does -- basically, any package can add a file to that directory
for any reason, not just bona fide parts of the OS.
One thing you could do would be to find out what installed that file,
and then go ask the author of that package whether he thinks he should
be delivering the file:
pkg search -lp /usr/include/ext2/fs.h
My guess, though, is that he's really not at fault here, and that the
fault really lies with the software that is making assumptions about
what those files represent. Writing portable software is harder than
that. Reading through that problem report, though, makes it sound like
those other developers aren't going to agree with me. :-/
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] heavy cpu usage inside VirtualBox on linux
I wondered if anyone can verify if its normal to see such high cpu usage in these situtations. Running b 151 inside VirtualBox on a linux OS (debian). The hardware is older P4 with Celeron 3.06 Ghz CPU and 2gb of ram. The VM is assigned 888 MB of the available 2025. I'm not sure how much is Virtual Box itself and how much is due to OI Maybe someone here knows what VB it self might be pulling ans so how much of it is OI 1) During startup In the application `top' I see (During startup of oi) 96 % of cpu going to Virtual box. 2) Idling after startup is complete Once started and just idling, I see in `top': PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 11431 reader20 0 622m 520m 479m S 11.9 25.7 8:37.70 VirtualBox So still, a rather hefty chunk of available cpu and ram. I have only 2 (small) zpools, and 2 zfs filesystems. The VM is not running any service like nfs server or the like. Only what would normally be running in a default install with above mentioned zpool and zfs fs setup. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
On 28.10.11 16:29, James Carlson wrote:
In which bug tracker I must create a bug report for this issue?
The problem is that on OI-151 EXT2_IOC_GETFLAGS is defined as
_IOR('f', 1, long)
where _IOR is defined in drm/drm.h which is not included.
To me this looks like a bug in OpenIndiana.
At a guess, I suspect that what's going on here is that you have a
/usr/include/ext2/fs.h that's delivered by libparted, and this other
software is "assuming" that if this file is present, then all things in
it must work and it must correspond to a kernel feature.
Where you see the "fs.h"? ext2fs/ext2fs.h
I think that's a bit of a brash assumption on the part of the author of
that libarchive software. Just because you troll through /usr/include
and find a file there does not automatically mean it'll do what you
think it does -- basically, any package can add a file to that directory
for any reason, not just bona fide parts of the OS.
Yes, I agree, but this is a separate bug :-) And this bug is not IO-related.
One thing you could do would be to find out what installed that file,
and then go ask the author of that package whether he thinks he should
be delivering the file:
pkg search -lp /usr/include/ext2/fs.h
$ pkg search -lp /usr/include/ext2fs/ext2fs.h
PACKAGE PUBLISHER
pkg:/system/file-system/e2fsprogs@1.41.14-0.151.1
My guess, though, is that he's really not at fault here, and that the
fault really lies with the software that is making assumptions about
what those files represent. Writing portable software is harder than
that. Reading through that problem report, though, makes it sound like
those other developers aren't going to agree with me. :-/
I think, if any header file uses some macro, it must include header file
with definition for this macro. Am I wrong?
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
On 10/28/11 03:45, Andrey N. Oktyabrski wrote:
Good day.
In which bug tracker I must create a bug report for this issue?
(Cite from: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=45491)
The problem is that on OI-151 EXT2_IOC_GETFLAGS is defined as
_IOR('f', 1, long)
where _IOR is defined in drm/drm.h which is not included.
drm.h defines it only as a compatibility workaround for the drm ioctl
definitions from other platforms that use it - it's not intended to be
used for anything else, and certainly wouldn't help in this case, since
if the kernel & userland don't have a working common definition of the
ioctl, then the ioctl effectively doesn't exist.
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
Andrey N. Oktyabrski wrote:
> On 28.10.11 16:29, James Carlson wrote:
>>> In which bug tracker I must create a bug report for this issue?
>>>
>>> The problem is that on OI-151 EXT2_IOC_GETFLAGS is defined as
>>> _IOR('f', 1, long)
>>> where _IOR is defined in drm/drm.h which is not included.
>>> To me this looks like a bug in OpenIndiana.
>>
>> At a guess, I suspect that what's going on here is that you have a
>> /usr/include/ext2/fs.h that's delivered by libparted, and this other
>> software is "assuming" that if this file is present, then all things in
>> it must work and it must correspond to a kernel feature.
> Where you see the "fs.h"? ext2fs/ext2fs.h
I was diving in libparted because I didn't have ext2fs/ext2fs.h on my
OpenIndiana system. :-/
>> I think that's a bit of a brash assumption on the part of the author of
>> that libarchive software. Just because you troll through /usr/include
>> and find a file there does not automatically mean it'll do what you
>> think it does -- basically, any package can add a file to that directory
>> for any reason, not just bona fide parts of the OS.
> Yes, I agree, but this is a separate bug :-) And this bug is not
> IO-related.
I still disagree that depending purely on the existence of a header file
is the right way to build portable software -- it's likely necessary,
but almost certainly not sufficient. Good luck to the users of that
software, I guess.
>> One thing you could do would be to find out what installed that file,
>> and then go ask the author of that package whether he thinks he should
>> be delivering the file:
>>
>> pkg search -lp /usr/include/ext2/fs.h
> $ pkg search -lp /usr/include/ext2fs/ext2fs.h
> PACKAGE PUBLISHER
> pkg:/system/file-system/e2fsprogs@1.41.14-0.151.1
That doesn't come with the system. It's part of OI-SFE.
Looking over the software, it doesn't look to me like anyone should
assume that if the header files are present, then the kernel bits are
present as well. These programs are for "compatibility" -- specifically
on systems that lack those Linux-specific file systems.
>> My guess, though, is that he's really not at fault here, and that the
>> fault really lies with the software that is making assumptions about
>> what those files represent. Writing portable software is harder than
>> that. Reading through that problem report, though, makes it sound like
>> those other developers aren't going to agree with me. :-/
> I think, if any header file uses some macro, it must include header file
> with definition for this macro. Am I wrong?
To that last question, I'd say "yes."
I can see no need for any requirement that all of the macros defined in
a header file must be usable in all contexts. There are cases where the
macros defined are usable only in certain contexts -- such as when
building a kernel module or when compiling for debug or with certain
optional features.
Yes, I do think that, as a design point, it's a good thing for header
files shipped with the system to be stand-alone, meaning that they can
be compiled successfully without needing prior includes.
But, aside from that, I don't believe it's a requirement that anything
inside is usable by anyone, unless it's actually _documented_ to be
useful. In this case, I can see no documentation related to e2fsprogs
that suggests that including this header file will somehow get you
EXT2FS-related kernel ioctl support.
You might have an argument that e2fsprogs shouldn't include this header
file. Most projects (for what it's worth) just toss in the kitchen sink
-- anything that's built is shipped, even if it's not normally useful
for anyone outside of the project.
Perhaps Ken Mays might have something to say about it.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] About auto snapshots
On 10/28/2011 12:17 AM, Harry Putnam wrote: Per Sjoholm writes: [...] Works for me Well, that is good news... its probably some configuration not completed on my end then. Did you guys do anything more than enable the timeslider with the checkbox on the desktop timeslider tool? I see that the service attempts to start at boot up but fails. I couldn't find any better way to capture those messages (taking place on a Virtualbox install of oi 151) than a screen shot so have attached it below, I hope it is visible enough to read: Not sure what i did. ( I was more focused on getting oi-build running in a zone) Presume under user and group amend roles (zfs snapshot) Starting/opening graphical timeslider in gnome -- Per Sjöholm Spanga, Stockholm, Sweden ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
On 28.10.11 18:29, James Carlson wrote: pkg:/system/file-system/e2fsprogs@1.41.14-0.151.1 That doesn't come with the system. It's part of OI-SFE. Looking over the software, it doesn't look to me like anyone should assume that if the header files are present, then the kernel bits are present as well. These programs are for "compatibility" -- specifically on systems that lack those Linux-specific file systems. My guess, though, is that he's really not at fault here, and that the fault really lies with the software that is making assumptions about what those files represent. Writing portable software is harder than that. Reading through that problem report, though, makes it sound like those other developers aren't going to agree with me. :-/ I think, if any header file uses some macro, it must include header file with definition for this macro. Am I wrong? To that last question, I'd say "yes." I can see no need for any requirement that all of the macros defined in a header file must be usable in all contexts. There are cases where the macros defined are usable only in certain contexts -- such as when building a kernel module or when compiling for debug or with certain optional features. Yes, I do think that, as a design point, it's a good thing for header files shipped with the system to be stand-alone, meaning that they can be compiled successfully without needing prior includes. But, aside from that, I don't believe it's a requirement that anything inside is usable by anyone, unless it's actually _documented_ to be useful. In this case, I can see no documentation related to e2fsprogs that suggests that including this header file will somehow get you EXT2FS-related kernel ioctl support. You might have an argument that e2fsprogs shouldn't include this header file. Most projects (for what it's worth) just toss in the kitchen sink -- anything that's built is shipped, even if it's not normally useful for anyone outside of the project. Thanks for detailed explanation, you are right. But if you don't want to give someone something, don't give it. Otherwise it is a cheese in a mousetrap. Perhaps, it is necessary to remove unusable headers from system? Perhaps Ken Mays might have something to say about it. I would be glad to hear his opinion. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
Andrey N. Oktyabrski wrote: > On 28.10.11 18:29, James Carlson wrote: >> You might have an argument that e2fsprogs shouldn't include this header >> file. Most projects (for what it's worth) just toss in the kitchen sink >> -- anything that's built is shipped, even if it's not normally useful >> for anyone outside of the project. > Thanks for detailed explanation, you are right. But if you don't want to > give someone something, don't give it. Otherwise it is a cheese in a > mousetrap. If one were malicious, it'd be a way to catch people who write code without reading the documentation. :-/ > Perhaps, it is necessary to remove unusable headers from system? Well, much luck in that. Years ago at Sun, I filed a bug on it, and I had lengthy discussions with some of the senior architects while trying to find a way to address it. I never really did get much agreement on the issue. What I wanted to do was to segregate the documented interfaces (i.e., the things people in other projects _should_ be #including) from the undocumented ones (the things they should never #include) via packaging. That is, you'd have a "normal" /usr/include that gets installed, and a set of "extra" packages containing /usr/include files that you "should not" be using, but that have historically been shipped with the system. It seems like a simple idea, and possibly helpful to keep users on the straight-and-narrow, but: - Many system headers have a wild mix of documented/public interfaces and undocumented/unusable ones. You'd have to separate out these bits first into separate files, likely involving tens of thousands of lines of code churn. - At least at Sun, there were hundreds of obscure groups contributing code to ON all the time. There was simply no feasible way to get all of them to stop contributing unusable bits to /usr/include, so even if you could do this, it'd be a one-off hack. Eventually, new trash would appear. There's no way to make it stay fixed. - Some third-party software (unfortunately!) relies on undocumented and only partially usable bits from /usr/include. Since a lot of people rely on that code, cleansing /usr/include would have little effect -- real users will have to install the "naughty" package containing the "unusable" headers so that they can continue building the software they really want. If everybody installs that, then the work of separating the bits was wasted. I also tried removing headers that were utterly without merit, such as /usr/include/net/af.h. That doesn't do anything on Solaris, and never did. You'd be surprised and dismayed how much crapola like that is strewn in /usr/include. I spent months categorizing stuff, removing garbage, and rewriting mistaken code throughout the system that actually _used_ these _unusable_ headers, but never got to the point of integrating the work. I still have the diffs somewhere if someone wants them. I like cleanliness, so I wouldn't argue against someone making improvements here, but I've been beaten down enough myself. ;-} -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
On 28.10.11 18:26, Alan Coopersmith wrote:
(Cite from:
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=45491)
The problem is that on OI-151 EXT2_IOC_GETFLAGS is defined as
_IOR('f', 1, long)
where _IOR is defined in drm/drm.h which is not included.
drm.h defines it only as a compatibility workaround for the drm ioctl
definitions from other platforms that use it - it's not intended to be
used for anything else, and certainly wouldn't help in this case, since
if the kernel & userland don't have a working common definition of the
ioctl, then the ioctl effectively doesn't exist.
Thank you for the clarification.
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Anyone using Micron C300 SSDs?
Hi Tommy, > It caused a total I/O outage for something like 20 minutes before it was > finally failed by ZFS. > When asking Nexenta about it, they said they'd seen similar "ungraceful" > fails from C300 devices before, so I quickly yanked the other ones I had in > production and replaced them with Intels :) Thank you very much for letting me know. You went to X25-Es? -J ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
James Carlson writes: > If one were malicious, it'd be a way to catch people who write code > without reading the documentation. :-/ You mean, like the stupid passcode you need to specify when you want to apply the Recommended patch cluster? :-( > I also tried removing headers that were utterly without merit, such as > /usr/include/net/af.h. /* af.h 1.10 88/08/19 SMI; from UCB 7.1 */ Oh come on, it's not much older than 23 years. :-) > That doesn't do anything on Solaris, and never > did. You'd be surprised and dismayed how much crapola like that is > strewn in /usr/include. I spent months categorizing stuff, removing > garbage, and rewriting mistaken code throughout the system that actually > _used_ these _unusable_ headers, but never got to the point of > integrating the work. I still have the diffs somewhere if someone wants > them. It certainly would be interesting to see how much in /usr/include would need to be touched. > I like cleanliness, so I wouldn't argue against someone making > improvements here, but I've been beaten down enough myself. ;-} We feel with you. Don't give up! Regards -- Volker -- Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46 Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] e2fsprogs header file bug
On 28.10.11 23:11, James Carlson wrote: Perhaps, it is necessary to remove unusable headers from system? Well, much luck in that. Years ago at Sun, I filed a bug on it, and I had lengthy discussions with some of the senior architects while trying to find a way to address it. I never really did get much agreement on the issue. What I wanted to do was to segregate the documented interfaces (i.e., the things people in other projects _should_ be #including) from the undocumented ones (the things they should never #include) via packaging. That is, you'd have a "normal" /usr/include that gets installed, and a set of "extra" packages containing /usr/include files that you "should not" be using, but that have historically been shipped with the system. It seems like a simple idea, and possibly helpful to keep users on the straight-and-narrow, but: - Many system headers have a wild mix of documented/public interfaces and undocumented/unusable ones. You'd have to separate out these bits first into separate files, likely involving tens of thousands of lines of code churn. - At least at Sun, there were hundreds of obscure groups contributing code to ON all the time. There was simply no feasible way to get all of them to stop contributing unusable bits to /usr/include, so even if you could do this, it'd be a one-off hack. Eventually, new trash would appear. There's no way to make it stay fixed. - Some third-party software (unfortunately!) relies on undocumented and only partially usable bits from /usr/include. Since a lot of people rely on that code, cleansing /usr/include would have little effect -- real users will have to install the "naughty" package containing the "unusable" headers so that they can continue building the software they really want. If everybody installs that, then the work of separating the bits was wasted. I also tried removing headers that were utterly without merit, such as /usr/include/net/af.h. That doesn't do anything on Solaris, and never did. You'd be surprised and dismayed how much crapola like that is strewn in /usr/include. I spent months categorizing stuff, removing garbage, and rewriting mistaken code throughout the system that actually _used_ these _unusable_ headers, but never got to the point of integrating the work. I still have the diffs somewhere if someone wants them. I like cleanliness, so I wouldn't argue against someone making improvements here, but I've been beaten down enough myself. ;-} Sad story :-( But it is necessary to do something. The circumstances, given to themselves, goes from bad to the worst. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Chrooting Bind9 under oi_151a
Hi all,
I am installing an oi_151a server to use as a bind9 caching name
server. I am searching docs about howto do this under openindiana
without luck.
Please any site that explains how to do this??
Thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Chrooting Bind9 under oi_151a
carlopm...@gmail.com said: > I am installing an oi_151a server to use as a bind9 caching name server. I > am searching docs about howto do this under openindiana without luck. > > Please any site that explains how to do this?? Run it in a non-global zone. If/when OI gets read-only sparce zones like Solaris-10 has, it would be even more secure. Here are some other references if you want to go farther than the above: http://groups.google.com/group/comp.protocols.dns.bind/browse_thread/thread/832 95dd027cc4b67 http://www.geekride.com/how-to-configure-chroot-jailed-dns-server-solaris-10/ Regards, Marion ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] log messages from failed time-slider daemon
James Carlson writes: > On 10/27/11 18:34, Harry Putnam wrote: >> Note that top line about `crontab'. Is that the reason for the >> subsequent failures? > > It appears to be. > >> What is going on that requires crontab to be read? And what might make >> it not open.. permissions? > > The script this service runs modifies crontab entries (yecch!). Not > opening could be due to user modification of the time-slider service > itself, bad permissions somewhere, or a read-only file system. > > Try: > > ls -ld /var/spool/cron/crontabs > df /var/spool/cron/crontabs > # ls -ld cron drwxr-xr-x 4 root sys 4 2011-09-12 06:47 cron ---- ---=--- - # ls -ld cron/crontabs drwxr-xr-x 2 root sys 7 2011-10-28 22:13 cron/crontabs ---- ---=--- - # df /var/spool/cron/crontabs Filesystem 1K-blocks Used Available Use% Mounted on rpool/ROOT/openindiana 27524993 16362570 11162423 60% / ---- ---=--- - # /bin/df /var/spool/cron/crontabs / (rpool/ROOT/openindiana):22324845 blocks 22324845 files ---- ---=--- - # crontab -l > newcrontab # crontab newcrontab (no errors or warnings) To my inexperienced eye, this all looks pretty normal... is it? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] log messages from failed time-slider daemon
James Carlson writes: >> What is going on that requires crontab to be read? And what might make >> it not open.. permissions? > > The script this service runs modifies crontab entries (yecch!). Not > opening could be due to user modification of the time-slider service > itself, bad permissions somewhere, or a read-only file system. I forgot to mention this: In the gui I started the timeslider and it appeared to be off by default so I checked the `enable' box. Next bootup is when I first noticed the failures. So unless checking `enable' counts as a user modification then there should be none. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Checking procedure to move to new machine
I kind of know the commands and what they are supposed to do, but have no actual experience with moving zpools from one machine to another. Or in this case from vbox guest on a debian linux host OS, to vbox guest on a win7 host OS. (The linux box doesn't really have enough ram) So, is this the best plan: Install oi guest on win7 vbox. Create a zpool of appropriate size. use zfs send to send over the zfs filesystem and zfs receive to populate the new zpool with the old zfs fs. Some examples I see seem to show user creating a current snapshot on sending machine first then using commands like this: mach1 pfexec zfs send mypool/myfs@current | ssh mach2 zfs receive mypool/myfs Is there some reason why one would send a current snapshot rather than sending the file system itself like: mach1 pfexec zfs send mypool/myfs | ssh mach2 zfs receive mypool/myfs I don't just want to start experimenting without some pretty good notion I'm doing things right since I'm too inexperienced to know how to recover quickly and easily if I jack something up. So is the above a workable plan? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
