Debian GNU/Linux スレッド Ver.97[ﾜ有]
!extend:checked:vvvvv:1000:512
↑これを2行になるようにコピペしてからスレ立てしてください公式
https://www.debian.org/sitemap.ja.html#footer
過去ログは各自検索して見つけること
大体参考にならないので過度な期待は禁物
前スレ
https://mao.5ch.net/test/read.cgi/linux/1606619383/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured >>100
> 93でパージ前なのに99でインストールされてないってのが
> 意味わからないんだが
93でパージ前 待機したが、95 でy した。端末の最終部分だけ
＞dpkg: 警告: firmware-realtek の削除中、ディレクトリ '/lib/firmware/rtlwifi' が空でないため削除できませんでした
コピペ。これの対処方法がわからなかった。$ rm -rfv /lib/firmware/rtlwifiしていいのか？
けっきょく消してません。
99で$ export LANG=en_US したのは、
＞dpkg: 警告: firmware-realtek の削除中、ディレクトリ '/lib/firmware/rtlwifi' が空でないため削除できませんでした
このメッセージを英語化し、対象言語を英語化したグーグルで広く検索してみようとした。
予想に反して、この箇所は表示されず、（インストールされてない）と出た >>102
> $ rm -rfv /lib/firmware/rtlwifiしていいのか？
これは本来 firmware-realtek にしか含まれていないものみたいなので
削除してもおｋ パージする前のスナップショット でfirmwareを元に戻す必要はない？
いろいろのページを読みますと、firmwareいるみたいに書いてあるのですが。
$ sudo rm -rfv /lib/firmware/rtlwifi
'/lib/firmware/rtlwifi/rtl8723bs_ap_wowlan.bin' を削除しました
'/lib/firmware/rtlwifi/rtl8192eu_ap_wowlan.bin' を削除しました
'/lib/firmware/rtlwifi/rtl8812aefw_wowlan.bin' を削除しました
'/lib/firmware/rtlwifi/rtl8723bu_ap_wowlan.bin' を削除しました
'/lib/firmware/rtlwifi/rtl8812aefw.bin' を削除しました
removed directory '/lib/firmware/rtlwifi'
$ >>104
第一に firmware-realtek をpurgeしたのにそれらがある時点でおまかん
削除は済んだようなので、一応その状態でdkmsを作り直してみようか
事前に sudo dkms remove 8192cu/1.11 を忘れずに $ lsusb -v | grep Realtek
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Bus 001 Device 004: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter
idVendor 0x0bda Realtek Semiconductor Corp.
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable よくわからんけどdkmsの生成からやり直してみて
駄目でもスナップショット取ったところへ戻ればいいだけなので
しかしよくやるわ
俺ならとっくにOS再インストールで切り分けするかWi-Fiドングル新調するかしてるところだが >>107
> よくわからんけどdkmsの生成からやり直してみて
> 駄目でもスナップショット取ったところへ戻ればいいだけなので
了解です。
> しかしよくやるわ
> 俺ならとっくにOS再インストールで切り分けするかWi-Fiドングル新調するかしてるところだが
OS再インストールしたいのですが、わからないからです。debian でインストール工程でローカルからwifi ドライバをインストールしたり複雑な上にbtrfs だから。 > 削除は済んだようなので、一応その状態でdkmsを作り直してみようか
事前に sudo dkms remove 8192cu/1.11 を忘れずに
全体の流れ
sudo dkms add ./rtl8192cu-fixes
sudo dkms install 8192cu/1.11
sudo depmod -a
sudo cp ./rtl8192cu-fixes/blacklist-native-rtl8192.conf /etc/modprobe.d/ $ sudo dkms remove 8192cu/1.11 --all
-------- Uninstall Beginning --------
Module: 8192cu
Version: 1.11
Kernel: 4.19.0-17-amd64 (x86_64)
-------------------------------------
Status: Before uninstall, this module version was ACTIVE on this kernel.
8192cu.ko:
- Uninstallation
- Deleting from: /lib/modules/4.19.0-17-amd64/updates/dkms/
rmdir: 'updates/dkms' を削除できません: ディレクトリは空ではありません
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.
depmod..............
update-initramfs..............
DKMS: uninstall completed.
------------------------------
Deleting module version: 1.11
completely from the DKMS tree.
------------------------------
Done.
$ >
- Deleting from: /lib/modules/4.19.0-17-amd64/updates/dkms/
rmdir: 'updates/dkms' を削除できません: ディレクトリは空ではありません
これはどうしたら？ >>108
> OS再インストールしたいのですが、わからないからです。
ライブから入れればそんなに難しくないけどね
> debian でインストール工程でローカルからwifi ドライバをインストールしたり複雑な上にbtrfs だから。
ドライバはともかくBtrfsはZFSに比べれば簡単だけどね 欲を出さなければ
こんな事も簡単に出来るし
https://i.imgur.com/SRcQOVs.png >>111
$ sudo rm -rf /lib/modules/4.19.0-17-amd64/updates jin@kyo:~$ cd /lib/modules/4.19.0-17-amd64/updates/dkms/
jin@kyo:/lib/modules/4.19.0-17-amd64/updates/dkms$ ls -a
. .. r8168.ko
jin@kyo:/lib/modules/4.19.0-17-amd64/updates/dkms$ $ sudo rm -rf /lib/modules/4.19.0-17-amd64/updates
$ cd /lib/modules/4.19.0-17-amd64/updates/dkms/
bash: cd: /lib/modules/4.19.0-17-amd64/updates/dkms/: そのようなファイルやディレクトリはありません
$ 画像見ました。ありがとうございます。複数のDEのサブボリュームがあって
切り替えられる――ということですね $ sudo dkms add ./rtl8192cu-fixes
Creating symlink /var/lib/dkms/8192cu/1.11/source ->
/usr/src/8192cu-1.11
DKMS: add completed.
$ sudo dkms install 8192cu/1.11
Error! Could not find module source directory.
Directory: /usr/src/8192cu-1.11 does not exist.
$ サブボリュームはmvできるんだよ
違うDE使いたい時は@をDEの名前んとこに放り込んで使いたいDEのやつを引っ張り出してる
timeshift使ってる都合があってそういうダセエ方式にしてる(本来はgrubでマルチブート出来るはず) timeshift は宝です。timeshiftを教えてくれて本当にありがとう >>117
$ sudo cp -Rv ./rtl8192cu-fixes /usr/src/8192cu-1.11 $ sudo dkms install 8192cu/1.11
Error! Could not find module source directory.
Directory: /usr/src/8192cu-1.11 does not exist.
$ sudo cp -Rv ./rtl8192cu-fixes /usr/src/8192cu-1.11
'./rtl8192cu-fixes' -> '/usr/src/8192cu-1.11/rtl8192cu-fixes'
'./rtl8192cu-fixes/.git' -> '/usr/src/8192cu-1.11/rtl8192cu-fixes/.git'
'./rtl8192cu-fixes/.git/branches' -> '/usr/src/8192cu-1.11/rtl8192cu-fixes/.git/branches'
ズラーッと。これが再帰的というやつか
:/usr/src/8192cu-1.11/rtl8192cu-fixes$ ls -a
. Makefile hal
.. README.md include
.git blacklist-native-rtl8192.conf os_dep
.gitignore clean runwpa
.travis.yml core
8192cu-disable-power-management.conf dkms.conf >>111
> - Deleting from: /lib/modules/4.19.0-17-amd64/updates/dkms/
> rmdir: 'updates/dkms' を削除できません: ディレクトリは空ではありません
>
> これはどうしたら？
こういうケースのときは管理権限で 手動でrm したらいいということか。その際その中身を
本当に消していいかどうかはユーザが自分で判断するということか。
$ sudo rm -rf /lib/modules/4.19.0-17-amd64/updates jin@kyo:~$ sudo dkms install 8192cu/1.11
Error! Could not find module source directory.
Directory: /usr/src/8192cu-1.11 does not exist.
jin@kyo:~$ cd /usr/src/8192cu-1.11
jin@kyo:/usr/src/8192cu-1.11$ ls -a
. core
.. dkms.conf
8192cu-disable-power-management.conf hal
Makefile include
README.md os_dep
blacklist-native-rtl8192.conf rtl8192cu-fixes
clean runwpa
jin@kyo:/usr/src/8192cu-1.11$ 人力でコピーしたやつは駄目なのかな
ドツボにハマる前にスナップショットで元に戻した方が良さそうな気がする
なお俺は firmware-realtek が無い状態からdkms生成に成功している $ sudo apt purge firmware-realtek
以前の状態に戻しました。
$ lsusb
Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 004: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 002: ID 04c5:14bb Fujitsu, Ltd
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ >>126
その状態のスナップショット以外は全て始末しちゃった方がいいかな
スナップショットが大量にあるとパフォーマンスが落ちるし
スナップショットだらけだとワケがわからなくなるでしょうから これはハードウェアの問題くさい？
参考:
https://unix.stackexchange.com/questions/360125/lsusb-error-cant-get-device-qualifier-descriptor-resource-temporarily-una
$ lsusb -t
/: Bus 09.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/5p, 12M
/: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/5p, 12M
|__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M
|__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=rtl8192cu, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M $ lsusb -v | grep RTL
can't get debug descriptor: Resource temporarily unavailable
Bus 003 Device 004: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter
idProduct 0x8178 RTL8192CU 802.11n WLAN Adapter
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
$ >>127
一つ残してスナップショットを削除しました debian10 usb live 上でおかしなエラーが出てるか？比較して切り分けできないか？ どうせsnapshotで戻せるんだからDebian11にしてみるのも手だな
既知の不具合はインストーラー関連だからアップグレードは問題ない Debian11..... アップグレード？
クリーンではなく？ 試しにやってみてもいいんじゃないかって事でしょう
クリーンインストールより手間かかんないし
ただし野良リポジトリはしばらく無効化する必要があるだろうな
wineとかchromeとかその他もろもろのやつ 私は寝ます。ありがとうございま
１，
スリープから復帰の問題だけなので、スリープ復帰ごとに、手でusb抜き差しをするという
妥協もありかと。以前いっときワイヤレスマウスを使っていたとき、スリープごとに
手で機械スイッチをオフにし、かつそのときはディスプレイとしてテレビを使っていて
これも手で電源ボタンoffにしていた。すごい大変でした。
２，
人生いろいろ、マシンもいろいろ。
さいきん別のトラブルでまるまる2週間かんぜんにdebianが使えないときもあった。その間ずっとういんだった。
アレにくらべれば、こんなの障害とさえいえないと言える。 サスペンドからの復旧時にはこまいトラブルはあるよね
Windowsみたいな挙動はあまり期待しない方がいいかも
それはさておき、Debian11いいぜ
アップグレードするなら複数の方が教えてくれるだろう
何がいいって、まず壁紙がシンプルでカッコいい >>136
壁紙もかっこいいし使いやすいが、
メモリ使用量がbusterの倍喰うし、Windows並にCPUクロックがポンポン上がって
頻繁にファンが回る
Busterは静かなんだけどね >>137
.... そうなんですか...残念です >>137
glibcのバージョンが上がって演算性能も上がったり(某演算プログラムで確認済)してる影響ですかねえ
何をしたらメモリ使用量が倍になるのかは私にはまだよくわかりませんが >>139
うちの環境だと起動後にbusterは400M弱でbullsEyeは700Mくらい喰う
動いてるプロセスはそんなに変わらないので、カーネルとLibの実装自体がどこかで食ってると思う。
クリーンインストールもBusterからのアップグレードも変わらなかった
xrdp使ってるので本体のデスクトップはloginしてなくても同じ
cpupowerの読み出しタイミングの関係かなと思ったが、実際の発熱が多いので
cpuもメモリも食ってるようです
他の使い勝手はほぼ満足してて、bullsEyeで立ち上げるとなかなか戻れない >>140
> busterは400M弱
MATE、Xfce、LXDEあたりですか
週末にSSDがひとつ空く予定なので自分でも確かめてみますわ 面白そうなので https://toshio-web.com/debian10-buster-install
debain10を別ハードディスクにクリーンインストールします
実況しますので支援して下さいっ >>142
支援もなにも、書いてあるとおりにやるだけなんだが
あと、新規にインストールするとUEFIのエントリが書き換わるのでそのつもりで >>141
はい、MATEです
マルチブートでほぼ同じ環境で使っています
meditが無くなったことだけがなにげに痛いです GTK2使ってるのが原因で上流が既に息してないな
君らが4.2に移植してやればいーんじゃね 制限を回避しながらも可能な限り抽象に作り込んで、
文句を言われながらも互換性を維持しながら別の方向で機能を拡張していく・・・
一長一短はあれど、こういう時はMSのフレームワーク類はがんばってたんだなって思えちまうな medit-1.2.92-devel.tar.bz2(上流の最新開発版)
Modified:
2017-11-12(約４年前)
こ、これは... >>143
> 新規にインストールするとUEFIのエントリが書き換わる
それが何の障害になるのかわかりません
現在のHDDのdebianもブートメニューが書き換わって
起動できなくなる、というイメージですか？ やはりアップグレードインストールだ！
アップグレードインストールなどウイン時代も
一回もやったことねえ！
理由は不完全だからだ！！ >>149
基本そう言う事になる
直し方あるけどそれを知りもしないのに突っ走るのはちょっとねえ https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.ja.html#backup
4.1.1. あらゆるデータや設定情報をバックアップする
システムをアップグレードする前に、完全なバックアップを取っておくよう強くお勧めします。少なくとも、失いたくないデータや設定情報だけでもバックアップしておきましょう。アップグレードのツールや処理はきわめて信頼性の高いものですが、アップグレードの最中にハードウェア障害が起こると、システムに大きなダメージを与えることがありえます。
>> やりました。home の必要をusb に入れました
バックアップしておくべき主な対象として、/etc、/var/lib/dpkg、/var/lib/apt/extended_states の中身、dpkg --get-selections "*" (引用符を忘れてはいけません) の出力などがあります。システムの管理に aptitude を使っている場合は、/var/lib/aptitude/pkgstates もバックアップしておくと良いでしょう。
>> /etc、/var/lib/dpkg、/var/lib/apt/extended_states の中身、dpkg --get-selections "*" (引用符を忘れてはいけません) の出力
ちょっと意味がわかりません。ヤルのですか？ >>152
それらは従来型ファイルシステム(ext4とかxfs)の場合は必須
Btrfs & timeshift の場合は基本的にはスナップショット取っておけば必要ない
気になるならやっといてもいいけど
俺だったら一応@と@homeを別ストレージへsend(要するにバックアップ)しておくかなあ >>153
> それらは従来型ファイルシステム(ext4とかxfs)の場合は必須
> Btrfs & timeshift の場合は基本的にはスナップショット取っておけば必要ない
ありがとうございます...
> 俺だったら一応@と@homeを別ストレージへsend(要するにバックアップ)しておくかなあ
usb にコピーではダメですか？やり方がわからない >>154
$ sudo timeshift --list
$ cd /var/run/timeshift/backup
$ sudo btrfs sub snap -r @ わかりやすい名前(※１)
$ sudo btrfs sub snap -r @home わかりやすい名前(※２)
$ sudo btrfs send ※１のスナップショット | sudo gzip -9cv > USBのマウントディレクトリ/わかりやすい名前.btrfs.gz
$ sudo btrfs send ※２のスナップショット | sudo gzip -9cv > USBのマウントディレクトリ/わかりやすい名前.btrfs.gz
$ sudo btrfs sub del ※１のスナップショット
$ sudo btrfs sub del ※２のスナップショット xzだとえらい時間かかりそうじゃん
データ容量知らんけど だよなあ
win10だけどFirefox90のソース展開するのに10分以上かかってたもんな・・ >>155
物凄く脳の状態が悪く、危険な操作ができない状態。超早寝して超朝型で
やります。 メモリ2GBでDebian+LXDEでFirefoxを使っているとスラッシングみたいに
なって苦しそうなことがあったけど3GBにしてやるとぐっと楽になった感じ
スロット1本壊れてしまっているので、これ以上増やすには
容量の大きなメモリに交換するするしか手がないです
Windows2000のときは512MBとかでもそれなりに快適に使えてたけど
Linuxでも64bit OSだと頑張って使用メモリをケチるようにしたのに
2GBではまったく足りない感じですね > 容量の大きなメモリに交換するするしか手がないです
本体を買い換えれば良いんじゃね >>155
$ sudo timeshift --list
/dev/sda2 is mounted at: /run/timeshift/backup, options: rw,relatime,space_cache,subvolid=5,subvol=/
Device : /dev/sda2
UUID : cf82c300-5af6-45d6-a682-1e93b9105cae
Path : /run/timeshift/backup
Mode : BTRFS
Status : OK
2 snapshots, 290.6 GB free
Num Name Tags Description
------------------------------------------------------------------------------
0 > 2021-06-22_22-32-03 O $ sudo apt purge firmware-realtek
1 > 2021-06-25_13-05-58 B
$ jin@kyo:~$ cd /var/run/timeshift/backup
jin@kyo:/var/run/timeshift/backup$ sudo btrfs sub snap -r @ 昇級前退避
Create a readonly snapshot of '@' in './昇級前退避'
jin@kyo:/var/run/timeshift/backup$ sudo btrfs sub snap -r @home 昇級前退避home Create a readonly snapshot of '@home' in './昇級前退避home '
jin@kyo:/var/run/timeshift/backup$
サイズがデカすぎてやり直し jin@kyo:/var/run/timeshift/backup$ sudo rm -rf 昇級前退避home
jin@kyo:/var/run/timeshift/backup$
消えません 昇級前退避home 読み取り専用属性がついてるからと思う。
すでにhomeの内容を整理したものをusbメモリに単純コピーしてある。
それを現在のhomeに再配置して、それから上記コマンドをもう一度やりたいです >>166
要するに@homeはバックアップを取る必要が無かったと言う事か
君のマシンを手に取れるわけじゃないんだからそう言う事は事前に言ってくれ
サブボリュームやスナップショットはrmコマンドでは消せないよ
$ cd /var/run/timeshift/backup
$ sudo btrfs sub del 必要無くなったスナップショット
ホームディレクトリのデータ配置は教える様な難しい事ではないので
後日独自にやって下さい
慣れない事をやろうとする時は余計な欲を出さない方が良い >>167
ホームパス内をUSBメモリにBUCKUP取って、
再導入してからバックアップから必要な物を戻せば良いだけじゃないの？ >>168
> ホームパス内をUSBメモリにBUCKUP取って、
これを既に完了していたと、166で後報告されたと言う成り行き
> 再導入してからバックアップから必要な物を戻せば良いだけじゃないの？
-> > ホームディレクトリのデータ配置は教える様な難しい事ではないので
-> > 後日独自にやって下さい 152で
>> やりました。home の必要をusb に入れました
で報告した。わかりにくい書き方でした
その上でそんな原始的なやり方ではダメで
＞俺だったら一応@と@homeを別ストレージへsend(要するにバックアップ)しておくかなあ
なのかなあ？と解釈しました >>167
> ホームディレクトリのデータ配置は教える様な難しい事ではないので
> 後日独自にやって下さい
> 慣れない事をやろうとする時は余計な欲を出さない方が良い
了解。自分でも同じこと考えた jin@kyo:/var/run/timeshift/backup$ sudo btrfs sub del 昇級前退避home
ERROR: Could not statfs: No such file or directory
jin@kyo:/var/run/timeshift/backup$ ls -a
. .. @ @home timeshift-btrfs 昇級前退避 昇級前退避home
jin@kyo:/var/run/timeshift/backup$ $ sudo btrfs send ※１のスナップショット | sudo gzip -9cv > USBのマウントディレクトリ/わかりやすい名前.btrfs.gz
----------------
$ sudo btrfs send 昇級前退避 | sudo gzip -9cv > /media/jin/C9EA-8480/昇級前退避.btrfs.gz 圧縮？おわりません
btrfs.gz のサイズ3.3ギガ これは時間がかかりすぎます
現在4.3ギガ。@のバックアップは必要度は？
キャンセルしてもいいか？ > Btrfs & timeshift の場合は基本的にはスナップショット取っておけば必要ない
とありますので、この@ のバックアップはやめていいですか？ jin@kyo:/var/run/timeshift/backup$ sudo btrfs send 昇級前退避 | sudo gzip -9cv > /media/jin/C9EA-8480/昇級前退避.btrfs.gz
At subvol 昇級前退避
gzip: stdout: File too large
jin@kyo:/var/run/timeshift/backup$
----------
終わりました >>178
> File too large
訳：ファイルサイズでか過ぎ
まあはじめに言ったとおりアップグレードがヤバそうでも
余程でない限りスナップショットで戻せるから大丈夫でしょ それは大いにある
だがもうやり直すの面倒でしょ？
RAID組んだり透過圧縮かけてたり等の特殊な事やってなけりゃ
Btrfsはそこまでヤワじゃないから大丈夫 て言うかホームディレクトリをそのまんまFAT32にコピーしては駄目じゃん
パーミッションが失われるぞ(確か) >>182
> だがもうやり直すの面倒でしょ？
ラジャー。
>て言うかホームディレクトリをそのまんまFAT32にコピーしては駄目じゃん
パーミッションが失われるぞ(確か)
コピーしたのは、
:/media/jin/C9EA-8480/2021-06-06_23-12-03$ ls -a
. Desktop Downloads Pictures rtl8192cu-fixes
.. Documents Music Videos
だけです。中身を逐一チェックして いる、イラン、いる、いらんした。
サイズは1ギガまで減らした。
ゆえに
---------------------------------
https://www.debian.org/releases/bullsey ... tml#backup
アップグレードの過程自体は、/home ディレクトリ以下は一切変更しません。とはいえ、(Mozilla スイートの一部や、GNOME・KDE といったデスクトップ環境のように) ユーザが初めて新しいバージョンのアプリケーションを起動するときに、既存のユーザ設定を新たなデフォルト値で上書きしてしまうものがあるのも事実です。
万一に備えて、ユーザのホームディレクトリにある隠しファイルと隠しディレクトリ (いわゆる 「ドットファイル」) をバックアップしておくのがよいでしょう。古い状態に戻したり、再度設定する場合に役立つはずです。
---------------------------------
＞ホームディレクトリにある隠しファイルと隠しディレクトリ (いわゆる 「ドットファイル」) をバックアップしておく
この教えを実行してない。次回します。
いまからカレー作るための買い出し、そのあとめし食って寝る
デビアンスレのみんな！あんがとよ！！
君もありがとう 俺はそのような事に真摯に取り組む限りは
俺に可能な助言は惜しまない
某所でおいたせずちゃんと休むんだぞ jin@kyo:/var/run/timeshift/backup$ sudo btrfs sub del 昇級前退避home
ERROR: Could not statfs: No such file or directory ＜＜消せません
ここがどうしたら？ 新しい"USB Drivを準備。
＞ホームディレクトリにある隠しファイルと隠しディレクトリ (いわゆる 「ドットファイル」) をバックアップ
のため
$ sudo mkfs.fat -F 32 /dev/sdb1 -n "USB Drive"
mkfs.fat 4.1 (2017-01-24)
mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows
警告-小文字のラベルは、DOSまたはWindowsでは正しく機能しない可能性があります。 よろしくおねがいします
＞ホームディレクトリにある隠しファイルと隠しディレクトリ (いわゆる 「ドットファイル」)
のサイズが4.4ギガあり"USB Drive"へのコピーでは時間がかかりすぎます。
こういう場合どうするのか？ jin@kyo:~$ cd /var/run/timeshift/backup
jin@kyo:/var/run/timeshift/backup$ sudo btrfs sub del 昇級前退避home
ERROR: Could not statfs: No such file or directory
jin@kyo:/var/run/timeshift/backup$ ls
@ @home timeshift-btrfs 昇級前退避 昇級前退避home
jin@kyo:/var/run/timeshift/backup$ >>190
$ sudo btrfs sub list . $ sudo btrfs sub list .
ID 2333 gen 171991 top level 5 path timeshift-btrfs/snapshots/2021-06-22_22-32-03/@
ID 2334 gen 168748 top level 5 path timeshift-btrfs/snapshots/2021-06-22_22-32-03/@home
ID 2343 gen 172433 top level 5 path @home
ID 2344 gen 172433 top level 5 path @
ID 2355 gen 171015 top level 5 path 昇級前退避
ID 2356 gen 171018 top level 5 path 昇級前退避home
ID 2375 gen 172321 top level 5 path timeshift-btrfs/snapshots/2021-06-27_16-24-22/@
ID 2376 gen 172322 top level 5 path timeshift-btrfs/snapshots/2021-06-27_16-24-22/@home
どうやってbtrfsのコマンド類をマスターしたのでしょう？ まとまったいいページありますか？ >>192
$ sudo btrfs sub del '昇級前退避'
$ sudo btrfs sub del '昇級前退避home'
> どうやってbtrfsのコマンド類をマスターしたのでしょう？
バックアップを抜かりなくやった上でいじくりまくった
> まとまったいいページありますか？
Btrfs - ArchWiki
https://wiki.archlinux.jp/index.php/Btrfs どのページを見てもこんな抽象的なことを
図解もなしに理解できるひとの意味がわかんない jin@kyo:/var/run/timeshift/backup$ sudo btrfs sub del '昇級前退避'
Delete subvolume (no-commit): '/run/timeshift/backup/昇級前退避'
こちらは消えた
jin@kyo:/var/run/timeshift/backup$ sudo btrfs sub del '昇級前退避home'
ERROR: Could not statfs: No such file or directory
jin@kyo:/var/run/timeshift/backup$
こちらは消せない btrfs error could not statfs no such file or directory
でググって
https://bbs.archlinux.org/viewtopic.php?id=211161
Can't delete a btrfs snapshot
スナップショットを削除しようとすると
btrfs subvolume delete 2/snapshot/4/snapshot
私は得る
ERROR: cannot access subvolume 2/snapshot/4/snapshot: No such file or directory
＜＜まったく一緒と思う、自分のと （回答者）
サブボリュームのフルパスを指定する必要があります。rootとしてどのサブボリュームをマウントしましたか？
（質問者）
お返事ありがとうございます。rootのfstabエントリは次のとおりです。
UUID=xxxxxxxxxxxxxxx / btrfs rw,noatime,compress=lzo,space_cache,subvolid=257,subvol=/ROOT,subvol=ROOT 0 0
---------
（俺）意味がわかんねえ、このやり取り >>197
ひとつ気になった事があるので以下を実施
$ 使ってるファイルマネージャ . &
$ ls ファイルマネージャから端末エミュレータへ「昇級前退避home」をドラッグしてエンター jin@kyo:~$ caja . &
[1] 9047
jin@kyo:~$ ls '/var/run/timeshift/backup/昇級前退避home '
jin
ありがとうございます。おれでも分かりました。昇級前退避home のあとに余分な空白が全角で一個入ってます jin@kyo:~$ sudo btrfs sub del '/var/run/timeshift/backup/昇級前退避home '
Delete subvolume (no-commit): '/run/timeshift/backup/昇級前退避home '
jin@kyo:~$
消せました！ 
