Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

core-services/03-filesystems.sh drops to emergency shell if root is read-only, even if this is desired behavior

オープン
#34 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
shell

調査の方向性

/etc/core-services/03-filesystems.sh の 67 行目付近から始め、root ファイルシステムの再マウント失敗がどのように emergency_shell に到達するかを確認してください。提案されている /proc/cmdline の処理を確認し、読み取り専用の root が明示的に要求されていない場合は、既存の緊急時の動作を維持してください。読み取り専用の root が要求された場合に emergency shell へ移行しなくなり、通常の root ファイルシステムの失敗では引き続き移行することが完了の条件です。

索引モデルが issue の本文から書いたものです。

説明

Greetings!

I've been building a Void-ish system using a read-only squashfs root filesystem. Unfortunately, the script /etc/core-services/03-filesystems.sh, at line 67, drops to an emergency shell if root cannot be mounted read-write.

This makes sense for the majority of desktop and server use cases, but for some embedded devices and some desktops/servers, having a read-only rootfs makes sense.

Proposal: have core-services/03-filesystems.sh check if /proc/cmdline contains ro, or readonly, or ro=true, or some such string, to support a wider range of use cases.


My temporary solution is to just remove the || emergency_shell from line 67, but this is undesirable because I wish to stay as close to upstream as possible

主要言語
C
スター
245
フォーク
67
平均マージ
2日
マージ済み PR(30日)
2

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

void-linux/void-runit のほかの issue

void-linux/void-runit の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。