arashi1977さんの助け合いフォーラム投稿一覧
解説のこの文ですかね。
PROD表とCATEGORY表では、CATEGORY列とNAME列が同名で同じデータ型の列になりますので、これらの列の値の組合せが一致する行が結合されます。
項目名、データ型が一致していても「値」が一致するものがないので1件も表示されないと言うことです。
できますね。ただこれをRAID（ Redundant Arrays of Inexpensive Disks）と呼ぶかというのはありますが。
# mdadm -C /dev/md0 -l0 -n1 /dev/loop0 --force
mdadm: partition table exists on /dev/loop0
mdadm: partition table exists on /dev/loop0 but will be lost or
meaningless after creating array
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
# mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Dec 4 17:50:17 2023
Raid Level : raid0
Array Size : 509952 (498.00 MiB 522.19 MB)
Raid Devices : 1
Total Devices : 1
Persistence : Superblock is persistent
Update Time : Mon Dec 4 17:50:17 2023
State : clean
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0
Chunk Size : 512K
逆ですかね？ man mke2fs してみたらこういう記述がありましたが。
DESCRIPTION
mke2fs is used to create an ext2, ext3, or ext4 filesystem, usually in a disk partition. device
is the special file corresponding to the device (e.g /dev/hdXX). blocks-count is the number of
blocks on the device. If omitted, mke2fs automagically figures the file system size. If called
as mkfs.ext3 a journal is created as if the -j option was specified.
-t fs-type
Specify the filesystem type (i.e., ext2, ext3, ext4, etc.) that is to be created. If this
option is not specified, mke2fs will pick a default either via how the command was run (for
example, using a name of the form mkfs.ext2, mkfs.ext3, etc.) or via a default as defined
by the /etc/mke2fs.conf file. This option controls which filesystem options are used by
default, based on the fstypes configuration stanza in /etc/mke2fs.conf.
どちらも「 mke2fs を別名で実行した場合にはその呼び出し名によってファイルシステムタイプ指定を変える」という意味ですよね。実際私の手元のCentOS 7ではどちらも同じバイナリでした。
# ls -l `which mkfs.ext3`
-rwxr-xr-x. 4 root root 96336 10月 1 2020 /usr/sbin/mkfs.ext3
# ls -l `which mke2fs`
-rwxr-xr-x. 4 root root 96336 10月 1 2020 /usr/sbin/mke2fs
# md5sum `which mkfs.ext3`
420ae83149b9e7fc101bd9878b0613e3 /usr/sbin/mkfs.ext3
# md5sum `which mke2fs`
420ae83149b9e7fc101bd9878b0613e3 /usr/sbin/mke2fs
細かい挙動は mke2fs.c の中見るのが確実ですかね。
https://github.com/tytso/e2fsprogs/blob/master/misc/mke2fs.c
検索したらすぐ出てきましたけど、こう言う話を誰かに調べさせたいのでしょうか？
https://gihyo.jp/admin/serial/01/ubuntu-recipe/0559
「/devices/」で始まる文字列はイベントターゲットのデバイスパスです。これはそのまま「/sys」以下のディレクトリパスです。
なぜ微妙なニュアンスの違いで正解が変わるのでしょうか
スピードマスターのことはスピードマスターの発行元に聞くしかないんじゃないでしょうか？
とりあえず実機確認したらこんなことになりましたけど。
[root@centos7 ~]# ls -l /var/log/dmesg
-rw-r--r--. 1 root root 35484 11月 25 07:30 /var/log/dmesg
[root@centos7 ~]# wc -l /var/log/dmesg
567 /var/log/dmesg
[root@centos7 ~]# dmesg | wc -l
575
[root@centos7 ~]# dmesg --clear
[root@centos7 ~]# wc -l /var/log/dmesg
567 /var/log/dmesg
[root@centos7 ~]# dmesg | wc -l
0
ちなみに、Red Hat 8系やUbuntuの22とか新しい環境では /var/log/dmesg 自体存在しないっぽいですね。
参考URLの先に書いてあるのですが、読んでからのご質問ですよね？
Normal patches¶
These patches are not incremental, meaning that for example the 5.7.3 patch does not apply on top of the 5.7.2 kernel source, but rather on top of the base 5.7 kernel source.So, in order to apply the 5.7.3 patch to your existing 5.7.2 kernel source you have to first back out the 5.7.2 patch (so you are left with a base 5.7 kernel source) and then apply the new 5.7.3 patch.
その結果EIGRPが配布する経路がおかしくなったのでしゃうか？
その通りです。RIPドメインまで1hop多くあるのが肝ですかね。
show ip eigrp topologyで192.168.1.0/24の情報を確認するとわかります。私の手元の環境（IPアドレスとかは適当に振ってます。多分こんな感じかなと）でですが実際にループしますしこう見えます。
RD#sh ip ei top 192.168.1.0/24
EIGRP-IPv4 Topology Entry for AS(1)/ID(172.16.31.4) for 192.168.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3072
Descriptor Blocks:
172.16.12.3 (GigabitEthernet0/2), from 172.16.12.3, Send flag is 0x0
Composite metric is (3072/2816), route is External ←RCからのADが2816なのでFDが3072
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 20 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 172.16.12.3
External data:
AS number of route is 1
External protocol is OSPF, external metric is 20
Administrator tag is 0 (0x00000000)
172.16.31.5 (GigabitEthernet0/0), from 172.16.31.5, Send flag is 0x0
Composite metric is (3328/3072), route is External ←REからのADが3072なのでFDが3328
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 30 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Originating router is 192.168.1.6
External data:
AS number of route is 0
External protocol is RIP, external metric is 0
Administrator tag is 0 (0x00000000)
EIGRPのメトリック的にREに流すよりRC(RB)へ送るほうが近いって判断されてるんですね。
ちなみに、RA観点でRBとRCのどっちに行くかという話で言うと、先取りです。この設問ではRA→RBってなってますがその環境でRBからの経路情報をリセット（clear ip eigrp neighborとか）するとRA→RC→RD→RB→RA→...ってできます。
「State」は空白の場合、どのように判断すればよいのかを教えていただけますでしょうか。
State（状態）がない、と理解すれば良いです。
TCPだとコネクションには状態（待受中のLISTEN, 接続中のESTABLISHED, 切断中のFIN_WAITとか）が存在するのでそれを表示しているだけですが、UDPにはそもそも状態というものがなく、受け取ったパケットが適切であれば相応の応答を返すというだけの仕組みなので、表示すべき状態（State）が存在しないのです。
こちらでインターネットなどで参考になりそうなものを探しましたが、
「State」が空白になっている事例は見当たらなかったので。
これは昔のnetstatの出力かなぁと思います。私の手元の環境ではこんな出力が得られました。
# netstat -an | egrep '(udp | State)' | sort | head -n 5
Proto Recv-Q Send-Q Local Address Foreign Address State
Proto RefCnt Flags Type State I-Node Path
udp 0 0 0.0.0.0:68 0.0.0.0:*
udp 0 0 10.0.0.1:4500 0.0.0.0:*
udp 0 0 10.0.0.1:500 0.0.0.0:*
同じ環境でssを使って確認すると表示が違うんですよね。
# ss -an | egrep '(udp | State)' | sort | head -n 5
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
udp UNCONN 0 0 *:68 *:*
udp UNCONN 0 0 [::1]:323 [::]:*
udp UNCONN 0 0 [::1]:500 [::]:*
udp UNCONN 0 0 10.0.0.1:4500 *:*
もっと言うと、「UDP」に待ち受けポートがあるとは判断できないと思います。
わかりやすい例では、DNSのための53/udpはどうでしょう？UDPだけ出したいので -u オプションつけてます。
# netstat -au | grep domain | grep localhost
udp 0 0 localhost:domain 0.0.0.0:*
# netstat -anu | grep 53 | grep 127
udp 0 0 127.0.0.1:53 0.0.0.0:*
# ss -au | grep domain | grep 127
UNCONN 0 0 127.0.0.1:domain *:*
# ss -aun | grep 53 | grep 127
UNCONN 0 0 127.0.0.1:53 *:*
EIGRPの動作としてはワイルドカードマスクで指定しようがサブネットマスクで指定しようが同じ挙動になると私は思っているのでこの正誤判定はおかしいと思いました。
コマンドとして通ることと設問の条件を満たしているかは別の問題じゃないでしょうか？
手元の環境でサブネットマスク形式で指定したところワイルドカードマスク形式に自動的に修正されたのですが、これは「正しい構文ではない」ために修正されたと考えるのが自然かと思います。
「正しい構文で設定しているnetworkコマンド」の条件を満たすためには、自動的に修正されない形式である 0.0.0.255 が適切な回答で問題ないと思いますよ。
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#int g0/0
Router(config-if)#ip addr 10.1.1.1 255.255.255.0
Router(config-if)#no shut
Router(config)#router eigrp 1
Router(config-router)#net 10.1.1.0 255.255.255.0
Router(config-router)#end
Router#sh run | section router eigrp
router eigrp 1
network 10.1.1.0 0.0.0.255
トランクでEtherChannelリンクを形成している物理ポート達の中から、一つだけアクセスポートにした際
相手のポートがトランクモードでも、ダウン状態のままになるんでしょうか？
疑問点がよくわからないのですが、解説に記述されている「共通にすべき点」が信用できない、という意味でしょうか？
EtherChannelでポートをバンドルする際に共通にする必要があるのは以下の通りです。今回はスイッチポートの種類をfa0/1だけ変更した事になります。
（略）
・スイッチポートの種類（アクセスポート/トランクポート/レイヤ3ポート）
単純化した言い方をすれば「共通の（必須）設定をしたポート群を1つの論理リンク（グループ）として扱う」のがEtherChannelなので、native VLANで通信できるかどうかは関係ないかと思います。
これをオプションというかどうかですかね。
# lsmod -h
Usage: lsmod
# lsmod | head -n 3
Module Size Used by
drbg 30186 1
ansi_cprng 12989 0
WindowsのtracertコマンドであればICMPを使用するのでネットワーク層の接続性確認といえますが、
tracerouteコマンドはCisco IOSやUNIX系OSともにUDPを使用するので
いまいち回答に納得がいかないです
これは難しいですね…とはいえ、UDP（トランスポート層）での接続性が確認できるということはそれより下のレイヤ（物理層、データリンク層、ネットワーク層）がすべてOKということが言えるので、別に間違っているわけではないんですよね ^^;