System Update turns on read-only file system with debugging features enabled

[eli.lia...@gmail.com]

After enabling debugging features on a chromebook after powerwash, I was able to reset the root password and have full access to the system, meaning it was read-write enabled. However, after an update was pushed and my chromebook rebooted and updated, the file system was locked to read-only everywhere outside my home directory. I am building a tool that relies on having this read-write access and was wondering if any of you know how to get around this resetting of permissions that seems to happen with updates. I have a Dell Chromebook 11 running the latest version of ChromeOS(I know this is about chromium, just wondering about similarities).

Thanks

[Mike Frysinger]

while we might be able to address the issue of re-propagating read-write access on an update, just to be clear, we wouldn't propagate any changes you might have made to the rootfs.  that requires significantly more effort to pull off.  is that really what you're looking for, or do you just want the read-only bit cleared ?

-mike

On Sat, Mar 10, 2018 at 8:36 AM, <eli.lia...@gmail.com> wrote:

After enabling debugging features on a chromebook after powerwash, I was able to reset the root password and have full access to the system, meaning it was read-write enabled. However, after an update was pushed and my chromebook rebooted and updated, the file system was locked to read-only everywhere outside my home directory. I am building a tool that relies on having this read-write access and was wondering if any of you know how to get around this resetting of permissions that seems to happen with updates. I have a Dell Chromebook 11 running the latest version of ChromeOS(I know this is about chromium, just wondering about similarities).

Thanks

--
--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-discuss+unsub...@chromium.org.

[eli.lia...@gmail.com]

We have made changes to files in the /usr/local folder, which from prior experience and if my memory serves me right, shouldn't get wiped by an update. But we need to be able to make changes to this folder as we push out updates, meaning that this rw bit needs to be enabled for us to make changes once again to the files in this folder. Does that make sense? We arent adding any files to anything directly off the root dir like in /etc, but we are working with files in /usr/local

On Saturday, March 10, 2018 at 11:01:52 AM UTC-6, Mike Frysinger wrote:

while we might be able to address the issue of re-propagating read-write access on an update, just to be clear, we wouldn't propagate any changes you might have made to the rootfs.  that requires significantly more effort to pull off.  is that really what you're looking for, or do you just want the read-only bit cleared ?

-mike

On Sat, Mar 10, 2018 at 8:36 AM, <eli.lia...@gmail.com> wrote:

After enabling debugging features on a chromebook after powerwash, I was able to reset the root password and have full access to the system, meaning it was read-write enabled. However, after an update was pushed and my chromebook rebooted and updated, the file system was locked to read-only everywhere outside my home directory. I am building a tool that relies on having this read-write access and was wondering if any of you know how to get around this resetting of permissions that seems to happen with updates. I have a Dell Chromebook 11 running the latest version of ChromeOS(I know this is about chromium, just wondering about similarities).

Thanks

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org

[Mike Frysinger]

/usr/local should not be wiped during an update, but it also shouldn't be read only. it isn't stored on the rootfs, so there's no reason you need to make the rootfs writable in order to utilize it (by design).

are your sure you're testing the right thing?

-mike

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

[DennisLfromGA]

eli.lia...,

If you want some but not all of the Debugging Features you can pass up the option on the initial sign-in screen and enable the one(s) you want afterward.

They are located as follows:

ls -l /usr/libexec/debugd/helpers/dev_features*

-rwxr-xr-x. 1 root root 11K Mar  6 04:13 /usr/libexec/debugd/helpers/dev_features_chrome_remote_debugging

-rwxr-xr-x. 1 root root 39K Mar  6 04:13 /usr/libexec/debugd/helpers/dev_features_password

-rwxr-xr-x. 1 root root 31K Mar  6 04:13 /usr/libexec/debugd/helpers/dev_features_rootfs_verification

-rwxr-xr-x. 1 root root 35K Mar  6 04:13 /usr/libexec/debugd/helpers/dev_features_ssh

-rwxr-xr-x. 1 root root 51K Mar  6 04:13 /usr/libexec/debugd/helpers/dev_features_usb_boot

The one you're interested in is 'dev_features_rootfs_verification'

~Dennis

On Saturday, March 10, 2018 at 2:41:31 PM UTC-5, Mike Frysinger wrote:

/usr/local should not be wiped during an update, but it also shouldn't be read only. it isn't stored on the rootfs, so there's no reason you need to make the rootfs writable in order to utilize it (by design).

are your sure you're testing the right thing?

-mike

On Sat, Mar 10, 2018, 09:05 <eli.lia...@gmail.com> wrote:

We have made changes to files in the /usr/local folder, which from prior experience and if my memory serves me right, shouldn't get wiped by an update. But we need to be able to make changes to this folder as we push out updates, meaning that this rw bit needs to be enabled for us to make changes once again to the files in this folder. Does that make sense? We arent adding any files to anything directly off the root dir like in /etc, but we are working with files in /usr/local

On Saturday, March 10, 2018 at 11:01:52 AM UTC-6, Mike Frysinger wrote:

while we might be able to address the issue of re-propagating read-write access on an update, just to be clear, we wouldn't propagate any changes you might have made to the rootfs.  that requires significantly more effort to pull off.  is that really what you're looking for, or do you just want the read-only bit cleared ?

-mike

On Sat, Mar 10, 2018 at 8:36 AM, <eli.lia...@gmail.com> wrote:

After enabling debugging features on a chromebook after powerwash, I was able to reset the root password and have full access to the system, meaning it was read-write enabled. However, after an update was pushed and my chromebook rebooted and updated, the file system was locked to read-only everywhere outside my home directory. I am building a tool that relies on having this read-write access and was wondering if any of you know how to get around this resetting of permissions that seems to happen with updates. I have a Dell Chromebook 11 running the latest version of ChromeOS(I know this is about chromium, just wondering about similarities).

Thanks

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-discuss+unsub...@chromium.org.

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-discuss+unsub...@chromium.org.