Re: [gentoo-user] Its ground hog day... how to escape the syndrome?

[Alan McKinnon]

On 02/03/2017 06:33, Harry Putnam wrote:
> Setup: VBox vm running gentoo(amd64) guest on a win-10 (64bit) host
>  Hardware: HP xw8600 - 2x Xeon  CPU X5450 @ 3.00GHz - 32 GB ram
> 
> I've seen a few other mentions of the phenomena I'm about to describe.
> It is not clear to me why something like this would happen. Or what is
> to be done to prevent it.
> 
> After going thru install and bulding of X based lxde desktop gentoo
> OS, I'm at the stage where I would do another emerge world followed by
> --depclean  or something similar.
> 
> Decided to take the @world in the two available bites; @system then
> @world
> 
> My cmdline was `emerge -vaDt @system'

Add -u to the options, it activates update behaviour

Without it, emerge takes you literally at your word and emerges
everything in the system set.

> 
> Showed 44 pkgs only 2 were updates and 42 were reinstalls.
> 
> Already it seemed like something might be off to have that many
> reinstalls with no --newuse or --changed-use involved.
> 
> I let it run thinking it might have to do with a small list of
> packages causing reinstalls.
> 
> Once that finished I ran `emerge -vaDt @world'
> 
> It showed 76 packages 2 updates 1 N in new slot and 73 reinstalls.
> 
> Further, very many of the reinstalls were packages that had just been
> reinstalled during @system  Same versions, same use flags.
> 
> At a glance I could see that nearly all or all of the packages rebuilt
> during During the @system run were to be done over again under a @world
> run,

@world includes @system

> 
> Surely there can be no reason for this absent some other factor like
> new or changed use flags.
> 
> So what causes this Groundhog day syndrome and how does one break out
> of it?

emerge -avuND 


-- 
Alan McKinnon
alan.mckin...@gmail.com

[gentoo-user] lxde no Desktop Preferences can be set

[Harry Putnam]

Setup: VBox vm running gentoo(amd64) guest on a win-10 (64bit) host
 Hardware: HP xw8600 - 2x Xeon  CPU X5450 @ 3.00GHz - 32 GB ram

LXDE on the menu item Preferences ===> Desktop Preferences
Nothing can be set there and it does not even show a dialog
box... just an error messages that says:

Desktop manager is not active

All the lxde-base pkgs contained in lxde-meta are installed.

Openbox wm is installed.

Anyone know what that error message means or how to get around or fix
it?

[gentoo-user] VIDEO_CARDS= apparently ignored and new pkgs assigned

[Harry Putnam]

Setup: VBox vm running gentoo(amd64) guest on a win-10 (64bit) host
 Hardware: HP xw8600 - 2x Xeon  CPU X5450 @ 3.00GHz - 32 GB ram

I'm having a situation where way too many packages are coming up
needing rebuilt during emerge world.

Decided to see what `emerge @preserved-rebuild would bring me.

ran `emerge -va @preserved-rebuild' and I notice that it appears my
setting in /etc/portage/make.conf for VIDEO_CARDS="virtualbox" is
being ignored... the output of above command shows:

  Calculating dependencies... done!
  
  [ebuild R ] x11-libs/libdrm-2.4.75::gentoo USE="-libkms -static-libs
 -valgrind" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="amdgpu* nouveau*
   radeon* (-exynos) (-freedreno) -intel (-omap) (-tegra) (-vc4)
 (-vivante) -vmware" 0 KiB
  
  [ebuild   R] mail-mta/sendmail-8.14.9-r1::gentoo  USE="mbox ssl
  tcpd -ipv6 -ldap -libressl -nis -sasl -sockets" 0 KiB
  
  [ebuild   R] x11-drivers/xf86-video-amdgpu-1.2.0::gentoo  USE="-glamor" 0 
KiB
  [ebuild   R] x11-drivers/xf86-video-ati-7.8.0::gentoo  USE="glamor -udev" 
0 KiB
  [ebuild   R] x11-drivers/xf86-video-nouveau-1.0.13::gentoo  0 KiB

Note how VIDEO_CARDS="amdgpu* nouveau* radeon* [...]"
is being assigned.

And the already installed (probably unneeded pkgs are being
reinstalled)

I considered ummerging those pkgs but checked `qdepends' on them and
that swears they are required by xorg-server not to mention this whole
string of other pkgs:

 qdepends x11-drivers/xf86-video-nouveau

x11-drivers/xf86-video-nouveau-1.0.13:
>=x11-libs/libdrm-2.4.60[video_cards_nouveau]
>=x11-libs/libpciaccess-0.10 !=sys-devel/automake-1.15:1.15 >=sys-devel/autoconf-2.69
>=sys-devel/libtool-2.4 virtual/pkgconfig x11-proto/xf86driproto
x11-proto/glproto x11-proto/dri2proto x11-proto/fontsproto
x11-proto/randrproto x11-proto/renderproto x11-proto/videoproto
x11-proto/xextproto x11-proto/xineramaproto x11-proto/xproto
x11-base/xorg-server[-minimal] x11-libs/libdrm
x11-base/xorg-server[xorg] x11-libs/libpciaccess

The other pkgs get similar output

This was not the first time I checked qdepends on this.

I did notice back when some of those driver pkgs were initially
installed and wondered then why I needed them... I checked then with
qdepends too and found that they are required by xorg-server and a
similar string of other pkgs as shown above for each.

Can anyone say what is going on here...?  Is this normal?
Should I really be needing drivers for ati, nouveau etc?
Any ideas about what needs to be done if anything?

[gentoo-user] Its ground hog day... how to escape the syndrome?

[Harry Putnam]

Setup: VBox vm running gentoo(amd64) guest on a win-10 (64bit) host
 Hardware: HP xw8600 - 2x Xeon  CPU X5450 @ 3.00GHz - 32 GB ram

I've seen a few other mentions of the phenomena I'm about to describe.
It is not clear to me why something like this would happen. Or what is
to be done to prevent it.

After going thru install and bulding of X based lxde desktop gentoo
OS, I'm at the stage where I would do another emerge world followed by
--depclean  or something similar.

Decided to take the @world in the two available bites; @system then
@world

My cmdline was `emerge -vaDt @system'

Showed 44 pkgs only 2 were updates and 42 were reinstalls.

Already it seemed like something might be off to have that many
reinstalls with no --newuse or --changed-use involved.

I let it run thinking it might have to do with a small list of
packages causing reinstalls.

Once that finished I ran `emerge -vaDt @world'

It showed 76 packages 2 updates 1 N in new slot and 73 reinstalls.

Further, very many of the reinstalls were packages that had just been
reinstalled during @system  Same versions, same use flags.

At a glance I could see that nearly all or all of the packages rebuilt
during During the @system run were to be done over again under a @world
run,

Surely there can be no reason for this absent some other factor like
new or changed use flags.

So what causes this Groundhog day syndrome and how does one break out
of it?

Re: [gentoo-user] sg_map etc

[Bill Kenworthy]

On 01/03/17 23:05, Stefan G. Weichinger wrote:
> Am 2017-03-01 um 15:42 schrieb Neil Bothwick:
> 
>> Never hurts to try the low hanging fruit first :)
>>
>> Have you tried lshw?
> 
> did so right now:
> 
> 
> 
>  *-disk:2
>   description: SCSI Disk
>   physical id: 0.2.0
>   bus info: scsi@1:0.2.0
>   logical name: /dev/sdc
>   size: 697GiB (749GB)
>   capabilities: partitioned partitioned:dos
>   configuration: sectorsize=512
> *-volume
>  description: Linux raid autodetect partition
>  physical id: 1
>  bus info: scsi@1:0.2.0,1
>  logical name: /dev/sdc1
>  capacity: 697GiB
>  capabilities: primary multi
> 
> 
> no clear connection between /dev/sdX and any hw-serial number
> 
> 

Is there actually a disk on that interface? - I have a system where one
sdx allocated to an unused sata port with nothing attached - it returns
similar information to yours above - check the other entries.

BillK

Re: [gentoo-user] sg_map etc

[Daniel Frey]

On 03/01/2017 08:31 AM, Stefan G. Weichinger wrote:
> Am 2017-03-01 um 16:49 schrieb Daniel Frey:
> 
>>> Have you tried `lsblk -O`?
>>>
>>> Dan
>>>
>>
>> Well, I forgot how much info that barfs out.
>>
>> Try `lsblk -o name,model,serial` instead.
> 
> nice one, thanks.
> But the shown serials don't match the serials on the disk(s) :-(
> 
> I also tried "-O" and searched for them.
> 
> It seems that the controller adds some extra layer or something.
> The vendor is shown as "ICP" (wrong in a way), I see partitions and so
> (looks good).
> 
> I have a list containing the actual vendors/serials on the physical
> labels, and the order in the physical slots, plus which label matches
> which /dev/sgX
> 
> *but* the map between sg- and sd-devices isn't correct IMO.
> 
> This is really a pita because I never can tell exactly which physical
> disk failed, I only see "ah, sdi1 was kicked out of the array" but then
> the search starts 
> 
> 

I'm not sure how the sg? -> sd? mapping is supposed to work. I find it
odd that there seems to be two nodes reported for each sd? entry.
However, this could be the way the controller driver reports it to the
kernel...

> 07:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030
> PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08)
> 0a:0e.0 RAID bus controller: Adaptec AAC-RAID
>

Well, if you are using a hw raid card in jbod mode the controller will
generally not report that info. You'd have to install the controller's
cli management tools and use that. You'd have to figure out which
controller your drives are attached to.

Adaptec uses sys-block/arcconf
LSI uses sys-block/megacli
3ware uses sys-block/tw_cli

An example of my 3ware card in my home server:

//> /c4 show drivestatus

VPort Status Unit Size  Type  Phy Encl-SlotModel
--
p0OK u0   931.51 GB SATA  0   -WDC
WD1003FBYX-01Y7
p1OK u0   931.51 GB SATA  1   -WDC
WD1003FBYX-01Y7
p2OK u0   931.51 GB SATA  2   -WDC
WD1003FBYX-01Y7
p3OK u0   931.51 GB SATA  3   -WDC
WD1003FBYX-01Y7
p4OK u0   931.51 GB SATA  4   -WDC
WD1003FBYX-01Y7
p5OK u0   931.51 GB SATA  5   -WDC
WD1003FBYX-01Y7
p6OK u0   931.51 GB SATA  6   -WDC
WD1003FBYX-01Y7
p7OK u0   931.51 GB SATA  7   -WDC
WD1003FBYX-01Y7

I can also pick a drive and get stats:
//> /c4/p0 show model
/c4/p0 Model = WDC WD1003FBYX-01Y7B1

//> /c4/p0 show serial
/c4/p0 Serial = WD-WMAW31350107

The management tools for the other cards should provide this sort of
functionality.

If you had used the raid card to create an array the management cli
tools with show that a specific port is dead and you query it for the
serial number.

This doesn't help you with the sg mapping. The problem for you now will
be figuring out why sg_map is reporting the way it is.

Dan

Re: [gentoo-user] sg_map etc

[Stefan G. Weichinger]

Am 2017-03-01 um 16:49 schrieb Daniel Frey:

>> Have you tried `lsblk -O`?
>>
>> Dan
>>
> 
> Well, I forgot how much info that barfs out.
> 
> Try `lsblk -o name,model,serial` instead.

nice one, thanks.
But the shown serials don't match the serials on the disk(s) :-(

I also tried "-O" and searched for them.

It seems that the controller adds some extra layer or something.
The vendor is shown as "ICP" (wrong in a way), I see partitions and so
(looks good).

I have a list containing the actual vendors/serials on the physical
labels, and the order in the physical slots, plus which label matches
which /dev/sgX

*but* the map between sg- and sd-devices isn't correct IMO.

This is really a pita because I never can tell exactly which physical
disk failed, I only see "ah, sdi1 was kicked out of the array" but then
the search starts 

Re: [gentoo-user] sg_map etc

[Daniel Frey]

On 03/01/2017 07:45 AM, Daniel Frey wrote:
> On 03/01/2017 07:05 AM, Stefan G. Weichinger wrote:
>> Am 2017-03-01 um 15:42 schrieb Neil Bothwick:
>>
>>> Never hurts to try the low hanging fruit first :)
>>>
>>> Have you tried lshw?
>>
>> did so right now:
>>
>>
>>
>>  *-disk:2
>>   description: SCSI Disk
>>   physical id: 0.2.0
>>   bus info: scsi@1:0.2.0
>>   logical name: /dev/sdc
>>   size: 697GiB (749GB)
>>   capabilities: partitioned partitioned:dos
>>   configuration: sectorsize=512
>> *-volume
>>  description: Linux raid autodetect partition
>>  physical id: 1
>>  bus info: scsi@1:0.2.0,1
>>  logical name: /dev/sdc1
>>  capacity: 697GiB
>>  capabilities: primary multi
>>
>>
>> no clear connection between /dev/sdX and any hw-serial number
>>
>>
> 
> Have you tried `lsblk -O`?
> 
> Dan
> 

Well, I forgot how much info that barfs out.

Try `lsblk -o name,model,serial` instead.

Dan

Re: [gentoo-user] sg_map etc

[Daniel Frey]

On 03/01/2017 07:05 AM, Stefan G. Weichinger wrote:
> Am 2017-03-01 um 15:42 schrieb Neil Bothwick:
> 
>> Never hurts to try the low hanging fruit first :)
>>
>> Have you tried lshw?
> 
> did so right now:
> 
> 
> 
>  *-disk:2
>   description: SCSI Disk
>   physical id: 0.2.0
>   bus info: scsi@1:0.2.0
>   logical name: /dev/sdc
>   size: 697GiB (749GB)
>   capabilities: partitioned partitioned:dos
>   configuration: sectorsize=512
> *-volume
>  description: Linux raid autodetect partition
>  physical id: 1
>  bus info: scsi@1:0.2.0,1
>  logical name: /dev/sdc1
>  capacity: 697GiB
>  capabilities: primary multi
> 
> 
> no clear connection between /dev/sdX and any hw-serial number
> 
> 

Have you tried `lsblk -O`?

Dan

Re: [gentoo-user] sg_map etc

[Stefan G. Weichinger]

Am 2017-03-01 um 15:42 schrieb Neil Bothwick:

> Never hurts to try the low hanging fruit first :)
> 
> Have you tried lshw?

did so right now:



 *-disk:2
  description: SCSI Disk
  physical id: 0.2.0
  bus info: scsi@1:0.2.0
  logical name: /dev/sdc
  size: 697GiB (749GB)
  capabilities: partitioned partitioned:dos
  configuration: sectorsize=512
*-volume
 description: Linux raid autodetect partition
 physical id: 1
 bus info: scsi@1:0.2.0,1
 logical name: /dev/sdc1
 capacity: 697GiB
 capabilities: primary multi


no clear connection between /dev/sdX and any hw-serial number

Re: [gentoo-user] sg_map etc

[Neil Bothwick]

On Wed, 1 Mar 2017 14:46:00 +0100, Stefan G. Weichinger wrote:

> >> and I would like to know which hard disk (vendor, serial) each
> >> /dev/sdX is.  
> > 
> > hdparm -i /dev/sdX  
> 
> 
> # hdparm -i /dev/sdi
> 
> /dev/sdi:
> SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00
> 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  HDIO_GET_IDENTITY failed: Inappropriate ioctl for device
> 
> that one would have been too easy ;-)

Never hurts to try the low hanging fruit first :)

Have you tried lshw?


-- 
Neil Bothwick

"We demand rigidly defined areas of doubt and uncertainty!"


pgpddGEuRkK71.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] sg_map etc

[Stefan G. Weichinger]

Am 2017-03-01 um 14:39 schrieb Neil Bothwick:
> On Wed, 1 Mar 2017 14:04:45 +0100, Stefan G. Weichinger wrote:
> 
>> and I would like to know which hard disk (vendor, serial) each
>> /dev/sdX is.
> 
> hdparm -i /dev/sdX


# hdparm -i /dev/sdi

/dev/sdi:
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00
00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 HDIO_GET_IDENTITY failed: Inappropriate ioctl for device

that one would have been too easy ;-)


maybe also helpful:


# lspci
00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller
Hub (rev b1)
00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
x8 Port 2-3 (rev b1)
00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
x8 Port 4-5 (rev b1)
00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
x8 Port 6-7 (rev b1)
00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA
Engine (rev b1)
00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB
Registers (rev b1)
00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB
Registers (rev b1)
00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB
Registers (rev b1)
00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved
Registers (rev b1)
00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved
Registers (rev b1)
00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD
Registers (rev b1)
00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD
Registers (rev b1)
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI
Express Root Port 1 (rev 09)
00:1d.0 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset
UHCI USB Controller #1 (rev 09)
00:1d.1 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset
UHCI USB Controller #2 (rev 09)
00:1d.2 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset
UHCI USB Controller #3 (rev 09)
00:1d.7 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset
EHCI USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC
Interface Controller (rev 09)
00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE
Controller (rev 09)
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus
Controller (rev 09)
01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express
Upstream Port (rev 01)
01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to
PCI-X Bridge (rev 01)
02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express
Downstream Port E1 (rev 01)
02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express
Downstream Port E3 (rev 01)
03:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI
Bridge A (rev 09)
03:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI
Bridge B (rev 09)
06:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
Ethernet Controller (Copper) (rev 01)
06:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
Ethernet Controller (Copper) (rev 01)
07:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030
PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08)
09:00.0 PCI bridge: Intel Corporation 80333 Segment-A PCIe Express to
PCI-X bridge
09:00.2 PCI bridge: Intel Corporation 80333 Segment-B PCIe Express to
PCI-X bridge
0a:0e.0 RAID bus controller: Adaptec AAC-RAID
0d:01.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] ES1000 (rev 02)

Re: [gentoo-user] sg_map etc

[Neil Bothwick]

On Wed, 1 Mar 2017 14:04:45 +0100, Stefan G. Weichinger wrote:

> and I would like to know which hard disk (vendor, serial) each /dev/sdX
> is.

hdparm -i /dev/sdX


-- 
Neil Bothwick

Yes, I've heard of "decaf." What's your point?


pgpO4mntXn3qg.pgp
Description: OpenPGP digital signature

[gentoo-user] Intermittent nouveau graphics failures

[Devrin Talen]

Hey all,

My desktop system has an NVidia graphics card that identifies as:

% lspci -v
# snip...
01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX
650] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd GK107 [GeForce GTX 650]
Flags: bus master, fast devsel, latency 0, IRQ 29
Memory at f600 (32-bit, non-prefetchable) [size=16M]
Memory at e000 (64-bit, prefetchable) [size=256M]
Memory at f000 (64-bit, prefetchable) [size=32M]
I/O ports at e000 [size=128]
Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [b4] Vendor Specific Information: Len=14 
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting 
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1
Len=024 
Capabilities: [900] #19
Kernel driver in use: nouveau

>From time to time, maybe once or twice a week, my system will fail.  The
symptoms are:

- Graphics freeze, no mouse movement, and they never start working no
matter how long I wait
- Sound is working (spotify keeps playing)
- Network connectivity works (I can ssh in)

When this happens and I ssh in and check out dmesg, I always see an error
like the following:

[11741.905192] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[11741.905202] nouveau :01:00.0: fifo: gr engine fault on channel 10,
recovering...

Sometimes I see a lot of those errors, sometimes just one.  Whenever the
system is running normally those don't ever appear.  I'm always able to ssh
in and reboot cleanly.

Does anyone have any idea where I can start digging in to find out what's
happening?  Are these fifo errors happening in some logic that I can
disable with a kernel command line option?

Thanks,
Devrin

[gentoo-user] sg_map etc

[Stefan G. Weichinger]

could someone help me out?

I have this software-raid:

md3 : active raid6 sdi1[8] sdh1[6] sdg1[4] sdf1[5] sde1[3] sdd1[2] sdc1[0]
  4391334912 blocks level 6, 64k chunk, algorithm 2 [8/6] [U_U_]
  [>]  recovery = 22.8% (167386900/731889152)
finish=196.6min speed=47837K/sec

and I would like to know which hard disk (vendor, serial) each /dev/sdX is.

(I have to tell the remote admin which physical disk to remove from the
server, and there are disks in the server which aren't part of the RAID yet)

Found sg_map and sg_scan:


# sg_map
/dev/sg0  /dev/nst0
/dev/sg1
/dev/sg2  /dev/sda
/dev/sg3  /dev/sdb
/dev/sg4  /dev/sdc
/dev/sg5  /dev/sdd
/dev/sg6  /dev/sde
/dev/sg7  /dev/sdf
/dev/sg8  /dev/sdg
/dev/sg9  /dev/sdh
/dev/sg10  /dev/sdi
/dev/sg11
/dev/sg12
/dev/sg13
/dev/sg14
/dev/sg15
/dev/sg16
/dev/sg17
/dev/sg18
/dev/sg19
/dev/sg20
/dev/sg21

--

The crux:

It seems I get two sg-devices per physical disk:

sda = sg2 = sg11 ...

sg11 is shown as SEAGATE, sg2 as ICP

(tried -d scsi and -d sat as well)

and I only get useful info from the sg-devices >10

->


# smartctl -d auto -i /dev/sg11
smartctl 6.4 2015-06-04 r4109 [x86_64-linux-3.18.11-gentoo-smp] (local
build)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:   SEAGATE
Product:  ST373455SS
Revision: 0002
User Capacity:73,407,868,928 bytes [73.4 GB]
Logical block size:   512 bytes
Rotation Rate:15015 rpm
Logical Unit id:  0x5000c50002448407
Serial number:3LQ11JWH9748U10J
Device type:  disk
Transport protocol:   SAS (SPL-3)
Local Time is:Wed Mar  1 15:51:28 2017 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Temperature Warning:  Enabled

juno ~ # smartctl -d auto -i /dev/sg2
smartctl 6.4 2015-06-04 r4109 [x86_64-linux-3.18.11-gentoo-smp] (local
build)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:   ICP
Product:  SAS1
Revision: V1.0
User Capacity:73,284,976,640 bytes [73.2 GB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or more
'-T permissive' options.
juno ~ # smartctl -d auto -i /dev/sda
smartctl 6.4 2015-06-04 r4109 [x86_64-linux-3.18.11-gentoo-smp] (local
build)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:   ICP
Product:  SAS1
Revision: V1.0
User Capacity:73,284,976,640 bytes [73.2 GB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or more
'-T permissive' options.


//



# sg_scan -iv
/dev/sg0: scsi0 channel=0 id=1 lun=0
HPUltrium 4-SCSIB12H [rmb=1 cmdq=1 pqual=0 pdev=0x1]
/dev/sg1: scsi0 channel=0 id=1 lun=1
OVERLAND  NEO Series0510 [rmb=1 cmdq=1 pqual=0 pdev=0x8]
/dev/sg2: scsi1 channel=0 id=0 lun=0 [em]
ICP   SAS1  V1.0 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg3: scsi1 channel=0 id=1 lun=0 [em]
ICP   SAS2  V1.0 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg4: scsi1 channel=0 id=2 lun=0 [em]
ICP   Device 2  V1.0 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg5: scsi1 channel=0 id=3 lun=0 [em]
ICP   Device 3  V1.0 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg6: scsi1 channel=0 id=4 lun=0 [em]
ICP   Device 4  V1.0 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg7: scsi1 channel=0 id=5 lun=0 [em]
ICP   Device 5  V1.0 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg8: scsi1 channel=0 id=6 lun=0 [em]
ICP   Device 6  V1.0 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg9: scsi1 channel=0 id=8 lun=0 [em]
ICP   Device 8  V1.0 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg10: scsi1 channel=0 id=12 lun=0 [em]
ICP   Device 12 V1.0 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg11: scsi1 channel=1 id=0 lun=0 [em]
SEAGATE   ST373455SS0002 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg12: scsi1 channel=1 id=1 lun=0 [em]
SEAGATE   ST373455SS0002 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg13: scsi1 channel=1 id=3 lun=0 [em]
WDC   WD7500AZEX-00RKK  0A80 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg14: scsi1 channel=1 id=4 lun=0 [em]
WDC   WD7500AZEX-00RKK  0A80 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg15: scsi1 channel=1 id=5 lun=0 

Re: [gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Miroslav Rovis]

I must not abbreviate this time...

On 170228-20:07-0500, Harry Putnam wrote:
> Miroslav Rovis  writes:
> 
> > On 170226-09:42-0500, Harry Putnam wrote:
> >> Stroller  writes:
> > ...
> >> 
> >> > Example at the beginning:  [32;01m * 
> >> > Example from the end:   * 
> >> >
> >> > Output to the terminal these would show the text in different colours,
> >> > but the output was redirected to a textfile or mishandled in a
> >> > copy-paste operation (not sure if screen or tmux does this?).
> >> >
> >> > Running emerge with `--color n` would have made this log much more
> >> > readable. Its size already makes it hard to search.
> >> 
> >> Yes, and I am sorry about that, its just that I could not discern what
> >> parts were important.  Still I should have posted only the last
> >> 400-500 lines.
> >> 
> >> Just so you know... I did try that. [--color n] The resulting log
> >> looked exactly the same.  ...
> >
> > This is hard to believe. I just tried, and either:
> >
> > --color n
> >
> > or:
> >
> > --color=n
> >
> > added to the emerge line, worked.
> >
> 
> Are you looking at the Terminal output?  If so that is not what I
> posted. 
> 
> I did mention that yes `--color n' kills the color in terminal output.
> 
> Read the whole paragraph you quote 1 sentence from above. 
> 
> This is the end of that para:
> 
> ". . . . . . . . . . . . . . . . . . . . . . . . I don't expect
> anyone would have noticed the comment... but it does seem a bit off
> that I see no differernce here.  That is, no difference in the actual
> log emerge creates. I do see the difference in the terminal output."

I see now what you mean (and meant, previously)!

> But as I mentioned what I posted was not the terminal output but the
> actual log that emerge creates for you.. and points you to when a
> failure occurs.
> 
> I just checked it again and I know that is what happens.  That is,
> setting `--color n' kills the color ouput at the terminal however the
> `build.log' still contains all the color sequences.
> 
> I'm already viewed dimly for posting so much junk so rather than post
> samples of both ... I'll leave it for you to try yourself.

No, you're not. Because you corrected your mistake.

(Very busy... got to go.)

Regards!

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature