#general

2019年1月

 1月1日 

watawatawataru9時19分
@watawatawataruさんがチャンネルに参加しました

 1月7日 

ryoto.no.address17時52分
@ryoto.no.addressさんがチャンネルに参加しました
hiro_aiba199522時53分
@hiro_aiba1995さんがチャンネルに参加しました

 1月9日 

itakeshi.net13時9分
@itakeshi.netさんがチャンネルに参加しました

 1月10日 

h.s.13415.b19時44分
@h.s.13415.bさんがチャンネルに参加しました

 1月12日 

yasuo.yamasaki_archil14時21分
@yasuo.yamasaki_archilさんがチャンネルに参加しました

 1月13日 

mail20時14分
いろいろ試してみたのですが、解決できなかったので質問させてください。
現在、デスクトップマシンに2つのSSDがあり、1つ目にWindows10、2つ目にArch Linuxが入っています。両方ともUEFI形式かつGPTです。
後者の方にGrubが入っており、電源投入後にGrubのメニューが表れるのですが、その一覧にWindows 10が表示されません。
BIOSでいちいち並び替えるよりも、Grubから選べる方が楽だと思っていたので当てが外れた格好です。
調べたところ、以下のような記述を/etc/grub.d/40-customに加えればよいとのことだったので、

if [ "${grub_platform}" == "efi" ]; then
menuentry "Microsoft Windows 10" {
insmod part_gpt
insmod fat
insmod search_fs_uuid
insmod chain
search --fs-uuid --set=root hd0,gpt2 6A9D-3CDD
drivemap -s hd0 hd2
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
fi

試してみたのですが、特に何も変化はない状態でした。grub-mkconfigコマンドは実行済みです。どなたか解決策をご存知の方はいらっしゃいますか。
tacha20時48分
os-prober は試されました?
mail20時50分
はい。試しましたが、だめでした。
tacha20時54分
うーんそうですよね...自分も別のドライブにWindows10とArchいれて同じような状況になった覚えあるんですが、どうやって解決したっけなあ
あと思うところがあるとすればbootmgfw.efiがちゃんと/EFI/Microsoft/Boot配下にあるかどうかとかですかね
mail21時0分
僕と環境だと/dev/sda2がEFIパーティションでした。hd0,gpt2で指定できていると思うのですが。
tacha21時8分
それならあってそうですね
他に思い当たる節がなくてお力になれずすみません:pensive:

 1月14日 

odknt22時28分
search のところ hd0,gpt2--hint-efi=hd0,gpt2 とかにしてもダメですかね?
mail22時29分
ありがとうございます。試してみます。
mail23時0分
だめでした……。
aruneko9923時8分
tachaさんがおっしゃるように、今参照している /EFI/Microsoft/Boot ってArch側の /EFI だと思うのですが、そこに該当ディレクトリやファイルって存在しています?
aruneko9923時9分
もしArch側の /EFI に存在していないのであれば、 /etc/fstab を編集してWin側のEFIパーティションをどこかにマウントしないとダメかもです。

 1月15日 

odknt1時47分
/etc/fstab はカーネル起動してからの問題なので drivemap を調整ですかね?
mail22時42分
アドバイスありがとうございます。>お二方
mail22時43分
いまGrubのwikiを見ているのですが、
mail22時43分
>これらの2つのコマンドは Windows が使っている ESP が $esp にマウントされているということを前提にしています。場合によっては Windows の EFI ファイルのパスが異なっている可能性があります。
mail22時43分
この一文が気になりますね。色々探っていますがまだうまくいっておりません。
aruneko9922時45分
そのページの上の方に書いてありますが、 $esp は通常 /boot になる前提で書かれています。
aruneko9922時46分
ただ今回の場合は /boot にWin側のEFI領域をマウントしていないので、まずLinux側のどこかにWin側のEFI領域をブートして、そこを $esp として読み替えていただければ。
mail22時51分
ああ、なるほど、これは$hints_stringsを呼び出すための記述でしたね。
mail22時52分
Grubメニューの段階ではmountは読み込まれないはずなので首をかしげていましたが、それとは関係なさそうです。
mail23時5分
驚くべきことに解決しました。
aruneko9923時6分
おぉ
mail23時6分
現在の記述は以下のとおりですが、これまでに同じやり方を試しているので理由は謎です。

menuentry "Micoroft Windows 10" {
insmod part_gpt
insmod fat
insmod search_fs_uuid
insmod chain
search --fs-uuid --no-floppy --set=root --hint-ieee1275='ieee1275//disk0,gpt2' --hint-bios=hd0,gpt2 --hint-efi=hd,gpt2 --hint-baremetal=ahci0,gpt2 6A9D-3CDD
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
mail23時8分
ともあれ、解決してよかったです。皆さんありがとうございました。

 1月17日 

usatosi15時25分
@usatosiさんがチャンネルに参加しました

 1月18日 

slouis.21422時52分
@slouis.214さんがチャンネルに参加しました

 1月20日 

mail12時41分
度々申し訳ありません。
起動時に[OK]Reached target Graphical Interface. のところでいつも1分〜2分もかかってしまいます。
ハードウェア環境はCore-i7 2600K,RAM16GB,GTX1070,256GBSSD(SSDSC2KW256G8X1)で、CPUは時代遅れですが性能的には問題ないと思います。
デスクトップ環境等はSDDMとKDE Plasmaです。
決してフリーズしているわけではなく、単にGUIの立ち上がりが遅いだけのようですが、なんとかして高速化する方法はないものでしょうか。
mail12時42分
ドライバは「Pacman -S nvidia」で入るものを使っています。
atnanasi14時40分
GUIが立ち上がる前に裏でなにかが動いてるかもしれないので、とりあえず https://atani.github.io/2015/06/%E8%B5%B7%E5%8B%95%E3%81%8C%E9%81%85%E3%81%84%E5%8E%9F%E5%9B%A0%E3%81%AF%EF%BC%9F%E3%81%9D%E3%82%93%E3%81%AA%E6%99%82%E3%81%AFsystemd-analyze%E3%81%A7%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF/ ここなどを参考にして本当にsddm.serviceが時間を食ってるのか確認すると切り分けやすくなるかと!
mail14時59分
ありがとうございます。さっそく試してみましたが、blameオプションをつけてみても特に時間のかかっているサービスはないですね。どれもミリセカンド単位でした。
mail15時0分
コマンドべた打ちだと
startup finished in 2.654s (kernel) + 7.699s (userspace) = 10.354s
graphical.target reached after 7.698s in userspace
と表示されました。うーん。
atnanasi15時2分
うーん、そうなるとグラボ回りでエラーが出ていないかdmesgとかを見たり、別なログインマネージャで再現するか試したり…となりますね
atnanasi15時3分
journalctlでsddm.serviceのログを見るのもありますね
mail15時31分
ありがとうございます。以下のような出力になりました。

1月 13 12:19:42 Arch systemd[1]: Started Simple Desktop Display Manager.
1月 13 12:21:31 Arch sddm[645]: Initializing...
1月 13 12:21:31 Arch sddm[645]: Starting...

一行目と二行目でいきなり2分近く空いています。これ以降は秒単位で進んでいるのでここに何かありそうです。
mail17時12分
SDDMからLightDMに変えたら一瞬で起動するようになりました。
mail17時13分
SDDM周辺に的を絞って調べてみます。
mail18時0分
原因が判明しました。
カーネルの問題だそうです。
(参考):https://bbs.archlinux.org/viewtopic.php?id=236696
(解決法):https://bbs.archlinux.org/viewtopic.php?id=237125
結論から言うとhavegedを導入すると治ります。
初期は起動に2分、lightdm導入後は40秒、sddmに戻して上のパッケージ導入後は10秒まで縮まりました。
おそらくこれで解決したと思います。
アドバイスありがとうございました。

 1月23日 

dilarackr519時42分
@dilarackr5さんがチャンネルに参加しました
dilarackr519時45分
Hi everyone I'm Dilara from Turkey

 1月26日 

mgoldchild14時40分
@mgoldchildさんがチャンネルに参加しました

 1月28日 

syui13時57分
誰か、以下のスクリプトを実行したときにでるエラーの原因ってわかる人いますか?
syui13時59分
## error
:: The following packages cannot be upgraded due to unresolvable dependencies:
pacman curl arch-install-scripts
:: Do you want to skip the above packages for this upgrade? [y/N] ==> WARNING: /var/tmp/rootfs-archlinux-xxxxxxx is not a mountpoint. This may have undesirable side effects.
mount: /var/tmp/rootfs-archlinux-xxxxxxx/proc: proc already mounted on /proc.
==> ERROR: failed to setup chroot /var/tmp/rootfs-archlinux-xxxxxxx
syui13時59分
tmpフォルダは、以下のコマンドでランダムに作られる模様
ROOTFS=$(mktemp -d ${TMPDIR:-/var/tmp}/rootfs-archlinux-XXXXXXXXXX)
chmod 755 $ROOTFS

 1月30日 

kobdotsh16時33分
@kobdotshさんがチャンネルに参加しました

 1月31日 

a61時7分
@a6さんがチャンネルに参加しました

Arch Linux JP Slack コミュニティ

Arch ユーザーや Arch Linux に興味がある人なら誰でも参加できる Slack コミュニティです。詳しくはこちらを見てください。

ログ作成日時: 2019/10/04 22:56:31。