[sf-lug] Chromebook issue

Michael Paoli michael.paoli at berkeley.edu
Mon Oct 20 23:21:00 PDT 2025


On Mon, Oct 20, 2025 at 1:11 PM John Strazzarino <jstrazzarino at gmail.com> wrote:
> lubuntu 24.2 LTS.  I’m trying to upgrade to lubuntu 25.2.  I ran lubuntu update, but it produced no update,perhaps because 24.2 is LTS?
> i did a sudo do-release-upgrade
> it said set Prompt=normal in /etc/update-manager/release upgrades.
> navigated to this and noticed it is a read-only file
> did a chmod 755 release/upgrades.
> it said changing permission of ‘release-upgrades’: operation not permitted
> not sure what to do, as the file  still shows as read-only
> what should I do?

If it's saying read-only, rather than permission denied, that's
issue with the filesystem having been (re)mounted readonly.
E.g.:
This is what no perms issue looks like:
$ ls -ld *
---------- 1 michael users 0 Oct 20 23:01 no_perms
$ echo foo >> no_perms
-bash: no_perms: Permission denied
$
This is what it looks like when the filesystem is mounted ro:
# id && ls -ld * && echo foo >> fs_is_ro
uid=0(root) gid=0(root) groups=0(root),7(lp),126(lpadmin)
-rw-r--r-- 1 root root 0 Oct 21 06:01 fs_is_ro
-bash: fs_is_ro: Read-only file system
# df -h .
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           7.8G     0  7.8G   0% /tmp/tmp.r0OCn2cdcq
# mount | fgrep " $(df -h . | awk '{if(NR==2)print $(NF)}') "
tmpfs on /tmp/tmp.r0OCn2cdcq type tmpfs (ro,nosuid,nodev,relatime,inode64)
#
Note the differences in the diagnostics (EPERM ("Permission denied")
vs. EROFS ("Read-only file system"))
Not also in the listing of the mounted filesystem from the output of the
mount command, the listing of options (within ()), first option is ro -
that-s read-only.
Typically stuff under /etc wouldn't be on ro mounted filesystem,
as some changes are typically needed there for normal operations
(e.g. for a user to update their password), and that would be on the
root (/) filesystem.  So, check if your root filesytem has been
(re)mounted ro.  Linux will commonly do this with, e.g.
ext2/3/4 filesystems if they're in use and it detects corruption - it will
remount them ro - so at least it won't get worse - and the system still
remains running (as opposed to, e.g. crashing).  Note also in such cases,
mount command may not always give current info (as many versions
depend upon or primarily use /etc/mtab ... which, yeah, if that's on root (/)
filesytem and that's been remounted ro) ... if there's every any question about
that, one can inspect the contents of mounts on the proc filesystem, e.g.
$ cat /proc/mounts
And that will always be current, as that shows the kernel's version/idea of
what's mounted (might lack some details that /etc/mtab may additionally have
and thus mount command may then also provide, but otherwise same).

So, you may need to first repair your root (/) filesystem so you can
get it mounted rw.  You won't be able to upgrade or update much of
anything if your root (/)
file system is mounted ro.



More information about the sf-lug mailing list