** Changed in: xfsprogs (Ubuntu Noble)
Status: Incomplete => New
** Description changed:
[Impact]
tl;dr: fsck.mode=force is not correctly applied in the initramfs, causing XFS
to not be checked or repaired.
When fsck.mode=force is specified in the kernel command line, fsck.xfs
is executed during the boot process. However, when the default shell is
not bash, $PS1 should be a different value, consider the following script:
cat ps1.sh
echo "$PS1"
run ps1.sh with different shells:
ash ./ps1.sh
$
bash ./ps1.sh
dash ./ps1.sh
$
ksh ./ps1.sh
zsh ./ps1.sh
On systems like Ubuntu, where dash is the default shell during the boot
process to improve startup speed. This results in FORCE being incorrectly
set to false and then xfs_repair is not invoked:
if [ -n "$PS1" -o -t 0 ]; then
FORCE=false
fi
Other distros may encounter this issue too if the default shell is set
to anoother shell.
Check "-t 0" is enough to determine if we are in interactive mode, and
xfs_repair is invoked as expected regardless of the shell used.
[Test Case]
1. install Ubuntu Focal with two disks (one for the system, the other for
test xfs partition)
2. create partition and xfs file system on the second drive (in my case it is
/dev/vdb (the disk), /dev/vdb1 (the xfs partition))
3. create mount point dir (ie, /data) and add appropriate line to the
/etc/fstab, ie:
/dev/vdb1 /data xfs defaults 0 2
4. sudo mount --all to test the above, next: sudo umount /data
5. break the xfs fs on /dev/vdb1:
sudo xfs_db -x -c blockget -c "blocktrash -s 512109 -n 1000" /dev/vdb1
6. verify it's broken:
sudo mount --all
7. add the "fsck.mode=force" to the kernel boot option in grub
(/etc/default/grub):
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 fsck.mode=force"
8. sudo update-grub
9. reboot the system and make sure xfs is repaired
- [Where things could go wrong]
+ [Where the problems can occur]
The patche removes $PS1 check, "-t 0" is already enough to determine if it's
in interactive mode in different shells, check $PS1 is more likely causing
unexpected issues mentioned above, in this case, this change won't cause other
issues.
This has been merged into upstream:
https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?h=for-next&id=19dde7fac0f38af2990e367ef4dd8ec512920c12
- [ Original Bug Report ]
+ [Original Bug Report]
https://bugs.launchpad.net/ubuntu/+source/xfsprogs/+bug/2071474
** Description changed:
[Impact]
tl;dr: fsck.mode=force is not correctly applied in the initramfs, causing XFS
to not be checked or repaired.
When fsck.mode=force is specified in the kernel command line, fsck.xfs
is executed during the boot process. However, when the default shell is
not bash, $PS1 should be a different value, consider the following script:
cat ps1.sh
echo "$PS1"
run ps1.sh with different shells:
ash ./ps1.sh
$
bash ./ps1.sh
dash ./ps1.sh
$
ksh ./ps1.sh
zsh ./ps1.sh
On systems like Ubuntu, where dash is the default shell during the boot
process to improve startup speed. This results in FORCE being incorrectly
set to false and then xfs_repair is not invoked:
if [ -n "$PS1" -o -t 0 ]; then
FORCE=false
fi
Other distros may encounter this issue too if the default shell is set
to anoother shell.
Check "-t 0" is enough to determine if we are in interactive mode, and
xfs_repair is invoked as expected regardless of the shell used.
[Test Case]
1. install Ubuntu Focal with two disks (one for the system, the other for
test xfs partition)
2. create partition and xfs file system on the second drive (in my case it is
/dev/vdb (the disk), /dev/vdb1 (the xfs partition))
3. create mount point dir (ie, /data) and add appropriate line to the
/etc/fstab, ie:
/dev/vdb1 /data xfs defaults 0 2
4. sudo mount --all to test the above, next: sudo umount /data
5. break the xfs fs on /dev/vdb1:
sudo xfs_db -x -c blockget -c "blocktrash -s 512109 -n 1000" /dev/vdb1
6. verify it's broken:
sudo mount --all
7. add the "fsck.mode=force" to the kernel boot option in grub
(/etc/default/grub):
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 fsck.mode=force"
8. sudo update-grub
9. reboot the system and make sure xfs is repaired
- [Where the problems can occur]
+ [Where the problems could occur]
The patche removes $PS1 check, "-t 0" is already enough to determine if it's
in interactive mode in different shells, check $PS1 is more likely causing
unexpected issues mentioned above, in this case, this change won't cause other
issues.
This has been merged into upstream:
https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?h=for-next&id=19dde7fac0f38af2990e367ef4dd8ec512920c12
[Original Bug Report]
https://bugs.launchpad.net/ubuntu/+source/xfsprogs/+bug/2071474
** Description changed:
[Impact]
tl;dr: fsck.mode=force is not correctly applied in the initramfs, causing XFS
to not be checked or repaired.
When fsck.mode=force is specified in the kernel command line, fsck.xfs
is executed during the boot process. However, when the default shell is
not bash, $PS1 should be a different value, consider the following script:
cat ps1.sh
echo "$PS1"
run ps1.sh with different shells:
ash ./ps1.sh
$
bash ./ps1.sh
dash ./ps1.sh
$
ksh ./ps1.sh
zsh ./ps1.sh
On systems like Ubuntu, where dash is the default shell during the boot
process to improve startup speed. This results in FORCE being incorrectly
set to false and then xfs_repair is not invoked:
if [ -n "$PS1" -o -t 0 ]; then
FORCE=false
fi
Other distros may encounter this issue too if the default shell is set
to anoother shell.
Check "-t 0" is enough to determine if we are in interactive mode, and
xfs_repair is invoked as expected regardless of the shell used.
[Test Case]
1. install Ubuntu Focal with two disks (one for the system, the other for
test xfs partition)
2. create partition and xfs file system on the second drive (in my case it is
/dev/vdb (the disk), /dev/vdb1 (the xfs partition))
3. create mount point dir (ie, /data) and add appropriate line to the
/etc/fstab, ie:
/dev/vdb1 /data xfs defaults 0 2
4. sudo mount --all to test the above, next: sudo umount /data
5. break the xfs fs on /dev/vdb1:
sudo xfs_db -x -c blockget -c "blocktrash -s 512109 -n 1000" /dev/vdb1
6. verify it's broken:
sudo mount --all
7. add the "fsck.mode=force" to the kernel boot option in grub
(/etc/default/grub):
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 fsck.mode=force"
8. sudo update-grub
9. reboot the system and make sure xfs is repaired
- [Where the problems could occur]
+ [Where problems could occur]
The patche removes $PS1 check, "-t 0" is already enough to determine if it's
in interactive mode in different shells, check $PS1 is more likely causing
unexpected issues mentioned above, in this case, this change won't cause other
issues.
This has been merged into upstream:
https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?h=for-next&id=19dde7fac0f38af2990e367ef4dd8ec512920c12
[Original Bug Report]
https://bugs.launchpad.net/ubuntu/+source/xfsprogs/+bug/2071474
** Changed in: xfsprogs (Ubuntu Noble)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2081163
Title:
fix fsck.xfs run by different shells when fsck.mode=force is set
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xfsprogs/+bug/2081163/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
