José Romildo Malaquias j.romi...@gmail.com wrote:
To find the reason for the following Impossible because
illegal error situation:
Executing 'test unit ready' command on Bus 0 Target 6, Lun 0 timeout 40s
CDB: 00 00 00 00 00 00
cdrecord: Input/output error. test unit ready: scsi sendcmd: fatal
Does anyone of you use the bareos backup suite with gentoo?
I will start to test it and learn the basics as I need some
hands-on-experience for a job at a customer.
Quick installation went fine, aside from the missing systemd-unit-files
(yes, we know ...). I will grab some unit-files from
On Mon, Nov 16, 2009 at 03:43:12PM +0100, Joerg Schilling wrote:
José Romildo Malaquias j.romi...@gmail.com wrote:
To find the reason for the following Impossible because
illegal error situation:
Executing 'test unit ready' command on Bus 0 Target 6, Lun 0 timeout 40s
CDB: 00 00 00 00 00
maxim wexler wrote:
Only 2.8mins left? The UPS unit, fairly common I suspect, is a Back-UPS ES
350 and less than a year old. It only saw service once last year during an
electric storm when the house power failed for a few minutes. Why isn't it
charging. Or is it? It says BATTDATE 2000-00
power off, i suspect the power supply
to be on its way. I'm going to borrow one from another PC to test it
with, see if the problme repeats with a different unit.
Tim
--
gentoo-user@gentoo.org mailing list
Am 29.01.2013 20:23, schrieb Canek Peláez Valdés:
I really believe the most important thing abount systemd unit files is
that they are small and simple. You can also check the exit status
from each command in the script, or even better, you can do a test
after all the commands are done
people to reach it, ie I'll test.
This already went before the Council, and the decision was that
INSTALL_MASK IS the working solution for opting out. If somebody
wants to come up with a better one and propose it they're of course
welcome to, but in the meantime, INSTALL_MASK is the official
Failure total: 2 Failures: 2 Errors: 0
Error: a unit test failed, please do one of:
export DEBUGCPPUNIT=TRUE# for exception catching
export GDBCPPUNITTRACE=gdb --args # for interactive debugging
export VALGRIND=memcheck# for memory checking
and retry.
### Quote
kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery
>> directory
>>
>> I will test shortly and report back - thanks!
>
> Confirmed - this fixes the 30 second delay.
Good.
> Should i log a bug for these issues?
If I were you, I'd definitely file a
José Romildo Malaquias j.romi...@gmail.com wrote:
On Mon, Nov 16, 2009 at 03:43:12PM +0100, Joerg Schilling wrote:
José Romildo Malaquias j.romi...@gmail.com wrote:
To find the reason for the following Impossible because
illegal error situation:
Executing 'test unit ready' command
the power supply
unit (if you do not have the necessary equipment to test it thoroughly).
I wish I had :) The RAM is okay, I think, I cannot imagine different
memory modules to suddenly go bad all at once. And memtest86 found one
error only after an hour, while the crashes happen after a few
} /bin/ip route add default via
${gateway}
ExecStart=-/bin/bash -c test -f /etc/conf.d/postup@%i.sh/bin/bash -c
/etc/conf.d/postup@%i.sh
ExecStop=/bin/ip addr flush dev %i
ExecStop=/bin/ip link set dev %i down
[Install]
WantedBy=multi-user.target
and here is my ntpdate service file:
[Unit
can find anything unexpected in it.
OK, the drive does not support the read buffer command, this is why cdrecord
cannot do a DMA speed test.
But you have a massive problem in the linux kernel that needs to be
investigated. The test unit ready command _cannot_ return a fatal
SCSI transport error
rs has dropped off to almost nothing.
>> Can you verify its not an artefact within munin (how?)
>
> In theory, a misconfigured graph can do this. Munin can draw many
> different types of graph, including cumulative values. Even for a data
> type like this which is X events
1
> Can you verify its not an artefact within munin (how?)
In theory, a misconfigured graph can do this. Munin can draw many
different types of graph, including cumulative values. Even for a data
type like this which is X events per unit time, if you tell munin to add
them all up, it will do
by other devices.
I set the device up on its own network at 192.168.3.1 by using the
following unit file:
[Unit]
Description=Network Connectivity for %i
Documentation=man:ip
Before=network.target
Wants=network.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices
to be
investigated. The test unit ready command _cannot_ return a fatal
SCSI transport error as long as there is a drive connected.
Please start with running the scgcheck command to get some informations
on the compliance problems in your linux kernel.
The output of scgcheck is attached
in the script, or even better, you can do a test
after all the commands are done to check the status of the bridge and
see if it was created correctly.
None of this belongs in the unit service, IMO. Otherwise, you end
creating ssh keys and user groups in unit files, and none of this
belongs there. Clear
2009/2/3 James wirel...@tampabay.rr.com:
Hello
SATA or Eide on DVD rw choices (internal unit).
Any cheap DVD rw that have success writing to
the many forms of rw DVDS, that one
would recommend?
Any bands (plextor?) to avoid on gentoo?
James
Hi James!
I use LG burners for every
. Which is
wierd; what happened to all that charge? I haven't had to use it for 6-7 mons.
Isn't the unit supposed to stay topped-up?
Another thing: When I do the remove-the-usb-cable test I don't see the
communication lost error in apcupsd.events until I switch the dial-up off and
on quickly
You have to hold down Alt, hold down Fn, hold down PrtSc, release Fn then
press the command keys. If you keep Fn held down, U is seen as 4 etc.
How do I test it out? Must I induce a freeze somehow or can I just
apply it to a working rig?
Press Ctrl-Alt-F1 to get to the first VC then press
-update and eix-update-remote after my daily
sync.I run eix-test-obsolete from the weekly cron script.
I should have said that I'm emailed the results of the first set of
commands so the first depclean is there to let me know what would be
removed after yesterday's update.
But you ran depclean
Am 13.09.2013 15:33, schrieb Stefan G. Weichinger:
Am 13.09.2013 14:54, schrieb Stefan G. Weichinger:
new info here (for me):
https://bugs.gentoo.org/show_bug.cgi?id=480066#c19
gotta test ... right now I don't have the time.
first tests with genkernel --udev ... : negative.
More
On 04/04/2017 02:56 PM, Kai Krakow wrote:
> Am Tue, 4 Apr 2017 14:28:23 -0600
> schrieb the...@sys-concept.com:
>
[snip]
>>
>> I have reconnected another cable and the unit in remote location
>> works. Both cable have a good pinout but one is working and the
* should work,
but timers are not a replacement for cron.
Thanks for all the hints, I'll test them in the next weeks.
I used cron mainly for backup scripts and log rotation, it should be fairly easy to
convert to one of the above (cron session vs. timer) once I fully digest the implications
t don't, tho). Cron spawns a session in the system
> > context. Both is not the same, so you should carefully decide which
> > cronjob to convert to a timer. Everything in /etc/cron* should work,
> > but timers are not a replacement for cron.
> >
>
> Thanks for all t
replace the memory with a 100%
working module, and if it does not help - replace the power supply
unit (if you do not have the necessary equipment to test it thoroughly).
And one more simple test: turn on the PC, enter the BIOS setup
utility and keep it running in this state. If it runs ok
service and my ntpdate service file, and I
would like to know how to get the ntpdate service file to wait till the
network is up before trying to start.
Thanks in advance for any suggestions.
Network service file:
[Unit]
Description=Network Connectivity for %i
Documentation= nam ip
Before
subsequent_filters-test.cxx:740:Assertion
Test name: ScFiltersTest::testPasswordNew
assertion failed
- Expression: xDocSh.Is()
- Failed to load password.ods
Failures !!!
Run: 18 Failure total: 2 Failures: 2 Errors: 0
Error: a unit test failed, please do one of:
export DEBUGCPPUNIT=TRUE
'TEST UNIT READY' operations.
Time total: 0.296sec
Doing 1000 'SEEK_G1 (0)' operations.
Time total: 418.463sec
0:read 1:veri 2:erase 3:read buffer 4:cache 5:ovtime 6:cap
7:wne 8:floppy 9:verify 10:checkcmds 11:read disk 12:write disk
13:scsireset 14:seektest 15: readda 16: reada 17: c2err
18
going stable).
There are a number of generic PSs that come with not enough power
for today's hardware requirment, it doesn't matter if it matches your
MOBO specs, if the DVD (or another device, even USB ones, mostly video
cards) sucks power, its gone.
PSU - as in Power Supply Unit.
You
for
what you are running.
http://www.jonnyguru.com/modules.php?name=NDReviewsop=Review_Catrecatnum=13
This site below lists them by wattage. They test them pretty hard too.
If it isn't a well built unit, they'll find the problem.
http://www.overclockers.com/forums/showthread.php/589708
t;>> past month. That seems strange to me. Munin doesn't show any other
>>>> data point increasing like this over the time period. Any ideas?
>>>>
>>>> - Grant
>>>>
>>>
>>> weird - does it reset on an interface restart or
prefer
Stefan's version.
I really believe the most important thing abount systemd unit files is
that they are small and simple. You can also check the exit status
from each command in the script, or even better, you can do a test
after all the commands are done to check the status of the bridge
nsole-setup
However, as a little test / possible workaround, I decided to create
my own systemd unit file that does nothing more but execute
/lib/systemd/systemd-vconsole-setup, only at a (hopefully) later stage
during the boot process:
# cat /etc/systemd/system/vconsole-fix.service
[Unit]
Des
answer, and you're purposely only examining a tiny
piece of the testing surface. Hindsight is 20/20, though only if
you're lucky.
Perhaps they've never seen this type of failure before, and they could
add a single test to whatever unit test suite they may be using.
Perhaps that's an improvement
: Tue Apr 28 19:27:34 MDT 2009
Only 2.8mins left? The UPS unit, fairly common I suspect, is a Back-UPS ES 350
and less than a year old. It only saw service once last year during an electric
storm when the house power failed for a few minutes. Why isn't it charging. Or
is it? It says BATTDATE
it won't
last all
that long.
Gave ~5 mins. So I let it charge for 24 hrs now it gives me 36 mins. Which
is wierd; what happened to all that charge? I haven't had to use it for 6-7
mons. Isn't the unit supposed to stay topped-up?
Well, assuming it was a 100 Watt incandescent
the car is cold. Turning the car off
and on won't kick it back on. It has to cool off.
Luther
Peter Frederick wrote:
in cool weather, that's about right.
You will have to check out the speed sensor, the wiring, and the
pushbutton unit, sadly.
The wires for the speed sensor can break
current actually works
just fine
Test your code under realistic conditions. Unit tests exist for a reason, read
'em
Read flameeyes's blog. You might not agree with everything he says, but
consider it all carefully as a technical position. He makes good points.
Don't try and re-invent
testing, on the other hand, is something a team should do.
Sure, the lone programmer can write you some unit tests and conduct a
system test, but testing itself is a profession of its own and should be
done by a second person with the relevant training.
But in the end, these issues a minor. It really
get its file as well ...).
No; the unit files should be installed by default by their respective
packages. No systemd USE flag, the same way there is no need for an
openrc USE flag to install init scripts in /etc/init.d
For sure this migration wasn't really *necessary* for me but kind
Am 15.05.2014 11:39, schrieb cov...@ccs.covici.com:
I did not try the -H, I may test with that later.
I did look at the --print-cmdline and copied the volumes they mentioned,
but I have other lvm volumes in my fstab and none of them were activated,
only the ones I specified in the command
Have you been through them and in particular the Full Power Down Test? If
yes, did you wait long enough after the PC has powered down, for the UPS to
also switch off (you can affect the overall waiting time by setting a shorter
TIMEOUT value, rather than waiting for the batteries to go flat
#arranging-for-reboot-on-power-up
On the same page it lists a number of tests you can perform:
http://www.apcupsd.com/manual/manual.html#testing-apcupsd
Have you been through them and in particular the Full Power Down Test? If
yes, did you wait long enough after the PC has powered down, for the UPS
On Saturday 15 Nov 2014 16:54:26 Thanasis wrote:
on 11/15/2014 04:59 PM Mick wrote the following:
Have you been through them and in particular the Full Power Down Test?
If yes, did you wait long enough after the PC has powered down, for the
UPS to also switch off (you can affect
=Review_Catrecatnum=13
This one just reviewed had a perfect score, if it has enough power for
what you are running.
http://www.jonnyguru.com/modules.php?name=NDReviewsop=Review_Catrecatnum=13
This site below lists them by wattage. They test them pretty hard too.
If it isn't a well built unit
=Review_Catrecatnum=13
This one just reviewed had a perfect score, if it has enough power for
what you are running.
http://www.jonnyguru.com/modules.php?name=NDReviewsop=Review_Catrecatnum=13
This site below lists them by wattage. They test them pretty hard too.
If it isn't a well built unit, they'll
d
> samples is only to be expected. Dishing a company just because you happened
> to get one of them is a bit lame.
> Better complain about the shop you got it from for not testing every single
> unit they sell.
> Or about the person who decided to use it without testing before RMA'
On 04/04/2017 10:02 AM, Mick wrote:
> On Tuesday 04 Apr 2017 09:12:16 the...@sys-concept.com wrote:
>> On 04/04/2017 01:26 AM, Mick wrote:
>>> On Monday 03 Apr 2017 20:21:28 the...@sys-concept.com wrote:
>
>>>> The Cat5 is about 15-20meter long, I test it with a c
s
[ebuild R]dev-ruby/test-unit-3.1.9 RUBY_TARGETS="(-ruby21%*)"
[ebuild R]dev-ruby/rdoc-4.2.0 RUBY_TARGETS="(-ruby21%*)"
[ebuild R]dev-ruby/minitest-5.8.4 RUBY_TARGETS="(-ruby21%*)"
RUBY_TARGETS is set in the profiles
quires dev-
> lang/ruby:2.1
> dev-ruby/rubygems-2.6.12 requires
> dev-lang/ruby:2.1
> dev-ruby/test-unit-3.2.5 requires dev-lang/ruby:2.1
>dev-ruby/yard-0.9.8 requires dev-lang/ruby:2.1
> virtual/rubygems-13
Hi all,
I am looking for info on usb3 to mini-pcie wifi modules - some kind
of adaptor? There are a lot of mini-pcie to M.2 on ebay but reading up
on mini-pcie it seems they may not be compatible. Does anybody have an
idea of one that would work - they are cheap enough to buy and
test/throw
. You might need to be added to the
hosts.allow.
snip
I should have said before . The machine is not a machine as such it is a
Network Storage Link for USB 2.0 disk drives. The disks are formatted ext3
and windows identifies the unit as a windows NT 4.9 server !!!
All I want to do is copy files
. There is no
rush for them to implement/incorporate this NVBackgroundDetect code as
they are trying to push their own cards. I'm not in favor of the
internal cards and prefer ATA unit.
No, not everybody needs it; but for me and many like me it would allow
us to move fax on an internal
to apply to the
problem than I can ever raise. The odds favour RedHat often getting
this right and me often getting it wrong, simply because I don't
have the unit testing facilities required and my employer doesn't
employ OS builders.
I won't permit Gentoo to be used in production here
Correction: the *s6_service_path* parameter in the parent init.d service,
/etc/init.d/container, needs to be changed from
/run/openrc/s6-scan/${INSTANCE} to /var/svc.d/${INSTANCE}
*#!/sbin/openrc-rundescription="A supervised test service with a
logger"supervisor=s6**s6_service_path=
*FLUSH_CACHE_EXT
*SMART error logging
*SMART self-test
*General Purpose Logging feature set
*64-bit World wide name
*{READ,WRITE}_DMA_EXT_GPL commands
*Segmented DOWNLOAD_MICROCODE
*Gen1
of this discussion.
I'm sorry, but you are (IMO) wrong: critical components should be
thoroughly tested and debugged, and have integrated unit testing, and
a large enough group of volunteers to test new releases before they go
into the general public.
You're pointing to valid issues
a good RAID unit, and what makes a terrible RAID unit?
Unless we're talking rapid failure, I'd think anything striped would
be faster than the bare drive alone.
2) Second lesson - prepare to build a few RAID configurations and
TEST, TEST, TEST __BEFORE__ (BEFORE!!!) you make _ANY_ decision about
: The related Linux kernel interface code seems to be
unmaintained.
Warning: There is absolutely NO DMA, operations thus are slow.
Using libscg version 'schily-0.8'.
SCSI buffer size: 64512
atapi: -1
cdrecord: Cannot do inquiry for CD/DVD-Recorder.
cdrecord: Input/output error. test unit ready: scsi sendcmd
y increasing over the
>>>>>> past month. That seems strange to me. Munin doesn't show any other
>>>>>> data point increasing like this over the time period. Any ideas?
>>>>>>
>>>>>> - Grant
>>>>>>
>>&
ily increasing over the
>>>>>> past month. That seems strange to me. Munin doesn't show any other
>>>>>> data point increasing like this over the time period. Any ideas?
>>>>>>
>>>>>> - Grant
>>>>>>
>>&
gt;
> I was definitely going to suggest making sure that a windows firewall
> wasn't blocking the inbound connections. That's fairly default
> behavior on windows.
hmmm, but what should I use for the source ip, I only assign those
when I bring the interface up when I start the inter
large, should I send it to you privately?
I don't think is necessary, I may have found the real problem (see below).
Some units did start, but most did not. Whenever I tried to
start one manually, I got a message like the following:
[snip]
No matter what unit I tried to start I would get
the following:
[snip]
No matter what unit I tried to start I would get such a message about
the service.mount.
That sounds like a problem with the cgroups hierarchy (which uses a
virtual filesystem). I don't remember seeing a problem like that
before.
Also, even though my network names
tried to
start one manually, I got a message like the following:
[snip]
No matter what unit I tried to start I would get such a message about
the service.mount.
That sounds like a problem with the cgroups hierarchy (which uses a
virtual filesystem). I don't remember seeing a problem
problem (see below).
Some units did start, but most did not. Whenever I tried to
start one manually, I got a message like the following:
[snip]
No matter what unit I tried to start I would get such a message about
the service.mount.
That sounds like a problem with the cgroups
indefinitely. I seeded all 92 gentoo torrents for a month
once to test this out. :-) Here in Utah, USA we have the largest
community fiber network in the country called UTOPIA. I'm only on
iProvo, but on UTOPIA they can get 50 Mib for a residential link.
Justin
I wish I lived in Utopia
: 3B0742X02836
BATTDATE : 2000-00-00
NOMBATTV : 12.0
FIRMWARE : 23.B1.D USB FW:B1
APCMODEL : Back-UPS ES 350
END APC : Tue Apr 28 19:27:34 MDT 2009
Only 2.8mins left? The UPS unit, fairly common I suspect, is a Back-UPS ES
350 and less than a year old. It only saw service once last year during
for C/C++) and documentation for everything else.
Then the devs will be able to run the software but no one will
have all the source code.
2. Do not give working code to anyone. Define specs, test cases,
prototypes and mock-ups. Then tell your devs to develop against these.
When
doesn't really
scale well with the number of devs).
That's a really good point.
Extensive testing, on the other hand, is something a team should do.
Sure, the lone programmer can write you some unit tests and conduct a
system test, but testing itself is a profession of its own and should
getting this right
and me often getting it wrong, simply because I don't have the unit
testing facilities required and my employer doesn't employ OS builders.
I won't permit Gentoo to be used in production here for precisely that
reason - I can't provide the test guarantees the business and
shareholders
Stefan G. Weichinger li...@xunil.at wrote:
Am 15.05.2014 11:39, schrieb cov...@ccs.covici.com:
I did not try the -H, I may test with that later.
I did look at the --print-cmdline and copied the volumes they mentioned,
but I have other lvm volumes in my fstab and none of them were
1164 MB in 3.00 seconds = 387.66 MB/sec
> olympus ~ # hdparm -tT /dev/sdb
>
> /dev/sdb:
> Timing cached reads: 20320 MB in 1.99 seconds = 10218.13 MB/sec
> Timing buffered disk reads: 300 MB in 3.00 seconds = 99.88 MB/sec
> olympus ~ #
>
>
> Something is not right w
fs-utils" environment file that's sourced
> >> by the nfs-server.service unit.
> >
> > In /usr/lib/systemd/system/nfs-server.service
> > [Service]
> > EnvironmentFile=/etc/conf.d/nfs
>
> Sorry. Looking at the ebuild, there's:
>
>
> rm "${D}$(syst
dev-ruby/rake-12.0.0 requires dev-lang/ruby:2.1
dev-ruby/rdoc-5.1.0 requires dev-lang/ruby:2.1
dev-ruby/rubygems-2.6.12 requires
dev-lang/ruby:2.1
dev-ruby/test-unit-3.2.5 requires dev-lang/ruby:2.1
dev-ruby/yard-0.9.8
dev-ruby/racc-1.4.14 requires dev-lang/ruby:2.1
> > dev-ruby/rake-12.0.0 requires dev-lang/ruby:2.1
> >dev-ruby/rdoc-5.1.0 requires dev-
> > lang/ruby:2.1
> > dev-ruby/rubygems-2.6.12 requires
> > dev-lang
ssert-1.0.2 requires dev-lang/ruby:2.1
> > dev-ruby/racc-1.4.14 requires dev-lang/ruby:2.1
> > dev-ruby/rake-12.0.0 requires dev-lang/ruby:2.1
> > dev-ruby/rdoc-5.1.0 requires dev-lang/ruby:2.1
> > dev-ruby/rubygems-2.6.12 requires
> > dev-lang/r
don't think so. But maybe you'r right. No sdd in fstab or in the
>> mounts at all and ...
>
> See next item, make sure you do NOT mount both at the same time.
I understand and agree ;-)
>> # /usr/bin/sg_vpd --page=di /dev/sdb
>> Device Identification VPD page:
>&g
inux does not borrow the parents address space description but copies it.
>
> Is that also true of clone(CLONE_VM|CLONE_VFORK)? Recent versions of
> glibc use this to implement the posix_spawn() function.
I guess... from reading the man page.
There is a simple test to verify my
't think my RAM is unstable
> >
> > (though
> >
> > > it's been a long time since I've run that RAM checking program).
> >
> > I ran memory checking overnight on my unstable (segfaults) AMD 8350
> > system, but no issues were found. Underclock
ut to much info,
> most of it useless or confusing at that. This is the first time that
> I've got so little and not be able to figure out a workaround.
>
> When the KDE packages get done, I'll try again and post what it spits
> out. Maybe it will give us more info or emerge will find a wa
maxim wexler blissfix at yahoo.com writes:
group,
Only 2.8mins left? The UPS unit, fairly common I suspect, is a Back-UPS ES 350
and less than a year old. It only
saw service once last year during an electric storm when the house power
failed for a few minutes. Why isn't
it charging
quot; or "RUBY" anywhere in the tree rooted
at /etc/portage
3. emerge did not offer to upgrade RUBY_TARGETS does
not seem happy with ruby21 since the emerge output includes
[ebuild R]dev-ruby/test-unit-3.1.9 RUBY_TARGETS="(-ruby21%*)"
[ebuild R]
just a single function box. Although the
first unit has a DVD drive in it since I had to build Gentoo from a
universal CD I figure that long term I don't even need that since the
picture playing a DVD from Myth is nowhere near as good as playing for
our DVD players.
The only time I'd possibly do
? You call that simple?
I'm sorry, but you are (IMO) wrong: critical components should be
thoroughly tested and debugged, and have integrated unit testing, and
a large enough group of volunteers to test new releases before they go
into the general public.
SysVinit code size is about 10 000 lines
selection: 4 (0 - 20)/cr:5==Not sure if I entered the correct No.
Doing 1000 'TEST UNIT READY' operations.
Time total: 0.296sec
Doing 1000 'SEEK_G1 (0)' operations.
Time total: 418.463sec
0:read 1:veri 2:erase 3:read buffer 4:cache 5:ovtime 6:cap
7:wne 8:floppy 9:verify 10:checkcmds 11
xec docker start -a whoami
The "finish" script, /var/svc.d/whoami/finish
*#!/bin/execlineb -Ps6-permafailon 60 1 2 exit*
The init.d, conf.d. Cat /etc/conf.d/container.whoami:
*INSTANCE=whoami*
Cat /etc/init.d/container:
*#!/sbin/openrc-rundescription="A supervised t
Am Tue, 4 Apr 2017 15:05:13 -0600
schrieb the...@sys-concept.com:
> On 04/04/2017 02:56 PM, Kai Krakow wrote:
> > Am Tue, 4 Apr 2017 14:28:23 -0600
> > schrieb the...@sys-concept.com:
> >
> [snip]
> >>
> >> I have reconnected another cable and the unit
that critical components
don't need to be simple; they need to be *reliable*.
I'm sorry, but you are (IMO) wrong: critical components should be
thoroughly tested and debugged, and have integrated unit testing, and
a large enough group of volunteers to test new releases before they go
into the general
;>>>
>>>> I rebooted and the rate of errors has dropped off to almost nothing.
>>>>
>>>>
>>>>>> Can you verify its not an artefact within munin (how?)
>>>>>
>>>>> In theory, a misconf
.
Gave ~5 mins. So I let it charge for 24 hrs now it gives me 36 mins. Which is
wierd; what happened to all that charge? I haven't had to use it for 6-7
mons. Isn't the unit supposed to stay topped-up?
Well, assuming it was a 100 Watt incandescent that really draws 100
Watts, then that's
wireless mouse ? (coz of the batteries). If so, monitor the
syslog while adding or removing the usb plug. If its recognised, you
will see messages. I doubt the batteries are the problem as with a
wireless mouse, its the base unit that when plugged in will cause
the /dev node to be created and you dont
are the problem as with a
wireless mouse, its the base unit that when plugged in will cause
the /dev node to be created and you dont have them.
Kind of. It's a Logitech wireless mouse/keyboard combo. One of the
outputs (I think it's the mouse) is USB but I have it plugged into one
of those converter
is deprecated and will be removed soon and select the
appropriate SCSI drivers for your drives. There's been a few messages on
this
list explaining how to go about it.
Done. Works both for cdrom unit and old IDE disk, whch now are know as sr0 (ex
hda) and sdc (wax hdc). cdrecord --checkdrive says
-shutdown.service have auditd.service in their
After= field; several others have plymouth services. After= is just
for ordering of units, is not a requirement; systemd detects that
auditd.service doesn't exists, and it starts the units that have it in
ther After= field anyway. To make a unit depend on another, you
econds = 10278.90 MB/sec
> > Timing buffered disk reads: 1164 MB in 3.00 seconds = 387.66 MB/sec
> >
> > olympus ~ # hdparm -tT /dev/sdb
> >
> > /dev/sdb:
> > Timing cached reads: 20320 MB in 1.99 seconds = 10218.13 MB/sec
> > Timing buffered
/power_assert-1.0.2 requires dev-lang/ruby:2.1
> dev-ruby/racc-1.4.14 requires dev-lang/ruby:2.1
> dev-ruby/rake-12.0.0 requires dev-lang/ruby:2.1
> dev-ruby/rdoc-5.1.0 requires dev-lang/ruby:2.1
>
1
> dev-ruby/rake-12.0.0 requires dev-lang/ruby:2.1
> dev-ruby/rdoc-5.1.0 requires dev-lang/ruby:2.1
> dev-ruby/rubygems-2.6.12 requires
> dev-lang/ruby:2.1
> dev-ruby/test-unit-3.2.5 requires dev-lang/ruby:2.1
> dev-ruby/yard-0.9.8 req
1 - 100 of 144 matches
Mail list logo
