How to start the DE automatically?

[ghost]

First, I tried disable rootfs_verification with this command:

sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification

But I get this output:

ERROR: YOU ARE TRYING TO MODIFY THE LIVE SYSTEM IMAGE /dev/sda.

The system may become unusable after that change, especially when you have some auto updates in progress. To make it safer, we suggest you to only change the partition you have booted with. To do that, re-execute this command as:

sudo ./make_dev_ssh.sh --remove_rootfs_verification --partitions 2

If you are sure to modify other partition, please invoke the command again and explicitly assign only one target partition for each time (--partitions N)

ERROR: IMAGE /dev/sda IS NOT MODIFIED.

So I took the computer's advice and I ran:

sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions 2

It seemed to work. I then did cd etc and then I did vim rc.local. I entered startunity -b into vim and then I tried to exit with :wq but it says that it doesn't have permissions to save. I tried sudo but same error.

When I try to run this command again:

sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification

The computer now suggests to run:

sudo ./make_dev_ssh.sh --remove_rootfs_verification --partitions 4

[dnschneid]

You still need to sudo mount -o remount,rw / in order to actually modify things.
Be sure to also disable rootfs verification: sudo crossystem dev_boot_signed_only=0 otherwise you'll find yourself unable to start up if you reboot.

[ghost]

I ran sudo crossystem dev_boot_signed_only=0 and that gave no output. Then when I ran sudo mount -o remount,rw /, I got this output: mount: cannot remount block device /dev/ROOT read-write, is write-protected

[DennisLfromGA]

@TahaYassen - Did you run

sudo /usr/share/vboot/bin/make_dev_ssh.sh --remove_rootfs_verification --partitions 4

as suggested earlier and reboot? It looks like it may have updated and switched active partitions since you first started.

[ghost]

I ran the command again with sudo /usr/share/vboot/bin/make_dev_ssh.sh --remove_rootfs_verification --partitions 2 and it still doesn't work. The reason I used 2 instead of 4 is because that is what it suggested this time.

[dnschneid]

You have to reboot once before remount will start working.

[ghost]

Nice, it worked!

For anyone in the future:

1. sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification
2. It will fail and tell you to run a command with --partitions 2 flag at the end where 2 can be any number. Run the command again with the new flag.
3. sudo mount -o remount,rw /
4. sudo crossystem dev_boot_signed_only=0
5. Reboot. You now can write to your drive.

I created /etc/rc.local and chmodded it but it doesn't seem to execute on startup. Has anyone gotten startup scripts to work on ChromeOS?

@DennisLfromGA I see you attempted this months ago. Any success?

[DennisLfromGA]

@TahaYassen

You don't have to use the trial & error method above - to determine which active kernel to modify use 'rootdev -s'. It will report the active root partition is either '/dev/sda3' or '/dev/sda5'. If it's '/dev/sda3' then your active kernel is partition 2, if it's '/dev/sda5' then your active kernel is partition 4. You can then run the 'make_dev_ssd.sh' command with the correct active kernel partition number.

Also, I think the above order of events should be - 1., 2., 4., 5., 3. You need to reboot before you issue the mount command.

[lightstrike]

I just came across this in an attempt to edit my hosts file. Great success! I wanted to confirm that @DennisLfromGA is correct that the order of @ghost's steps should be 1, 2, 4, 5, 3.

[DennisLfromGA]

@lightstrike - You might want to check out a few scripts I have -

• rw-rootfs makes the root filesystem read-writable for subsequent changes and additions by the user.
  I use a line in my .bashrc file to run this:

  sudo mount -i -o remount,rw / || bash ~/bin/rw-rootfs

• crouton.conf upstart script to kick-off a crouton chroot desktop environment.
  Be sure to check out the Comments section for tips on making a file for external control.

• mnt-crouton.conf init script to mount the CROUTON partition - made possible via @drinkcat's crouton/separate_partition branch

Also, Chrome OS doesn't run or use the /etc/rc.local file so you may have to use a /etc/init/*.conf script to do what you want - I did.

[lightstrike]

Thanks for script links @DennisLfromGA, I'll check them out! :-)

[tr0043t]

Hi. I'd like verify the status of these instructions and the script. In the virtualbox integration writeup for Crouton, it involves copying the new vb udev rules to a directory on the CrOS root fs (at least, that's my interpretation). Of course that fs is ro. Before I start mucking with the partition flags and such to gain rw access, I'd like to minimize the chances of some of the problems noted above (this is on an Asus Chromebox, by the way). Any suggestions appreciated. Thanks!

[DennisLfromGA]

@UT99310 - Unfortunately, I don't have a Chromebox to test on but I think the problems stemmed from the dev_boot_signed_only flag being set (1). I mention this in the comments section of the rw-rootfs script here - https://gist.github.com/DennisLfromGA/6690677#comment-1418056.

I haven't heard from any Chromebox users since I modified the script to unset the flag so your on your own I guess - sorry.

-DennisL

[tr0043t]

Understood. Guess I'll back up ye ol' chroot and give the script a try.
Thanks!

L

On Mon, Apr 13, 2015 at 12:58 PM, DennisL [email protected] wrote:

@UT99310 https://github.com/UT99310 - Unfortunately, I don't have a
Chromebox to test on but I think the problems stemmed from the
dev_boot_signed_only flag being set (1). I mention this in the comments
section of the rw-rootfs script here -
https://gist.github.com/DennisLfromGA/6690677#comment-1418056.

I haven't heard from any Chromebox users since I modified the script to
unset the flag so your on your own I guess - sorry.

-DennisL

—
Reply to this email directly or view it on GitHub
#582 (comment).

[tr0043t]

Looks like it worked OK on my Asus Chromebox. The script did throw an error
about a misplaced or unrecognized -gt just before the reboot (around line
119 I think), but I didn't see any obvious negative effects so far. Thanks
again.

On Mon, Apr 13, 2015 at 1:07 PM, Lauren Weinstein [email protected]
wrote:

Understood. Guess I'll back up ye ol' chroot and give the script a try.
Thanks!

L

On Mon, Apr 13, 2015 at 12:58 PM, DennisL [email protected]
wrote:

@UT99310 https://github.com/UT99310 - Unfortunately, I don't have a
Chromebox to test on but I think the problems stemmed from the
dev_boot_signed_only flag being set (1). I mention this in the comments
section of the rw-rootfs script here -
https://gist.github.com/DennisLfromGA/6690677#comment-1418056.

I haven't heard from any Chromebox users since I modified the script to
unset the flag so your on your own I guess - sorry.

-DennisL

—
Reply to this email directly or view it on GitHub
#582 (comment).

[DennisLfromGA]

That's great news.
I haven't tracked down that '-gt' error yet, I've been lazy...

[divx118]

@UT99310 For the udev rules you don't have to make the system rw. /var/run is writable, however you will need to redo it on a reboot.

[tr0043t]

Having to manually do that on reboots isn't a viable option (to me, anyway). I used /etc/udev/rules.d which is at least stable through boots.

[divx118]

@UT99310 Well, I just thought I should mention. Also when other people come across this.

[tr0043t]

Definitely. Thanks.

On Tue, Apr 14, 2015 at 8:19 AM, Maurice van Kruchten <
[email protected]> wrote:

@UT99310 https://github.com/UT99310 Well, I just thought I should
mention. Also when other people come across this.

—
Reply to this email directly or view it on GitHub
#582 (comment).

[DennisLfromGA]

Yes, that's good info. I think since probably most crouton users don't or won't remove rootfs.
It might be a good idea to add it to the https://github.com/dnschneid/crouton/wiki/VirtualBox-udev-integration wiki page too. Maybe it's something that users could add to their .bashrc.

[tr0043t]

If the mount/script sequencing is such that .bashrc can routinely copy the
rules.d entries into /var/run/udev/rules.d at the correct time to be
effective, the procedure probably should be documented in place of the
existing specification to copy into a root dir.

On Tue, Apr 14, 2015 at 1:14 PM, DennisL [email protected] wrote:

Yes, that's good info. I think since probably most crouton users don't
or won't remove rootfs.
It might be a good idea to add it to the
https://github.com/dnschneid/crouton/wiki/VirtualBox-udev-integration
pwiki age too. Maybe it's something that could users could add to their
.bashrc.

—
Reply to this email directly or view it on GitHub
#582 (comment).

[tr0043t]

I may be missing something, but it appears that this isn't going to work for VirtualBox loading. You need to change the kernel flags to enable module loading, and I don't see any way to do that without taking the system rw first. Is there another way? Thanks.

[divx118]

@UT99310 You don't need to make the system rw to change kernel-flags. You can follow the wiki instructions or my script change-kernel-flags See the first part of the README.md for the usage. The script will also let you revert the changes of the kernel flags by dd back an old backup kernel. Also it will handle automatically the crossystem variable settings.

[tr0043t]

I should have been more explicit. The point I was trying to make is that
you can't get at the kernel flags without those various partition
operations (in my case, via your script) that must be made each time CrOS
updates and that some users may be uncomfortable doing. Thanks.

On Thu, Apr 16, 2015 at 12:19 PM, Maurice van Kruchten <
[email protected]> wrote:

@UT99310 https://github.com/UT99310 You don't need to make the system
rw to change kernel-flags. You can follow the wiki instructions
https://github.com/dnschneid/crouton/wiki/Repack-kernel-to-Enable-VT_x-for-Virtualbox
or my script change-kernel-flags
https://github.com/divx118/crouton-packages/blob/master/change-kernel-flags
See the first part of the README.md
https://github.com/divx118/crouton-packages/blob/master/README.md for
the usage. The script will also let you revert the changes of the kernel
flags by dd back an old backup kernel. Also it will handle automatically
the crossystem variable settings.

—
Reply to this email directly or view it on GitHub
#582 (comment).

[divx118]

FYI if you make the system rw, you don't need to change kernel-flags. The sysfs path to disable module_locking should be visible again on a rw rootfs.

[tr0043t]

Quick question: In the course of this testing, looks like I ended up with a
corrupt .bashrc (probably an extraneous chdir or exit on the end). Now when
I try to enter the shell I just revert immediately back to the crosh
prompt. Is there a suggested way to fix this? Thanks!

On Thu, Apr 16, 2015 at 12:47 PM, Maurice van Kruchten <
[email protected]> wrote:

FYI if you make the system rw, you don't need to change kernel-flags. The
sysfs path to disable module_locking should be visible again on a rw
rootfs.

—
Reply to this email directly or view it on GitHub
#582 (comment).

[DennisLfromGA]

@UT99310 - I think you can login to your Google account and then, without opening a shell in that session, open the Developer Console via <Ctrl+Alt+Forward>. Then log in as root and cd to the chronos home folder # cd ~chronos, then fix or remove the .bashrc file.

[tr0043t]

Bingo! Thanks!

On Thu, Apr 16, 2015 at 2:59 PM, DennisL [email protected] wrote:

@UT99310 https://github.com/UT99310 - I think you can login to your
Google account and then, without opening a shell in that session, open the
Developer Console via <Ctrl+Alt+Forward>. Then log in as root and cd to the
chronos home folder # cd ~chronos, then fix or remove the .bashrc file.

—
Reply to this email directly or view it on GitHub
#582 (comment).

[DennisLfromGA]

Been there, done that... ;)

[tr0043t]

Looks like there may be more damage of a sort. Even though the partitions
look right, I can no longer remount / rw -- keep getting write-protected
error. Rerunning the script claims that the correct partition is already
unlocked. Odd.

On Thu, Apr 16, 2015 at 3:11 PM, DennisL [email protected] wrote:

Been there, done that... ;)

—
Reply to this email directly or view it on GitHub
#582 (comment).

[DennisLfromGA]

Have you rebooted since running the script?

[tr0043t]

Yeah. Still getting:

mount: cannot remount /dev/dm-0 read-write, is write-protected

On Thu, Apr 16, 2015 at 3:29 PM, DennisL [email protected] wrote:

Have you rebooted since running the script?

—
Reply to this email directly or view it on GitHub
#582 (comment).

[tr0043t]

Got it rw now. Took a few more boots. Something must have been out of
sequence. Thanks again!

On Thu, Apr 16, 2015 at 3:38 PM, Lauren Weinstein [email protected]
wrote:

Yeah. Still getting:

mount: cannot remount /dev/dm-0 read-write, is write-protected

On Thu, Apr 16, 2015 at 3:29 PM, DennisL [email protected] wrote:

Have you rebooted since running the script?

—
Reply to this email directly or view it on GitHub
#582 (comment).

[DennisLfromGA]

@UT99310,

I had a similar issue, I think, a while back with my Acer C710, which has since bit the dust.
The problem was in the file /usr/share/vboot/bin/make_dev_ssd.sh where it was only looking at dm-0 instead of dm-[0-9]. Look at line # 65 or there abouts. I filed a bug report https://code.google.com/p/chromium/issues/detail?id=428041 and it was resolved.

Hopefully this hasn't reared it's ugly head again...

[DennisLfromGA]

Oh, cool! I should have refreshed the page, I didn't see your last reply.

[tr0043t]

There clearly were changes that had unexpected (to me) effects in the last
CrOS update, there's now a conflict in the vb driver name paths that wasn't
there before. I'm working on it.

On Thu, Apr 16, 2015 at 4:49 PM, DennisL [email protected] wrote:

@UT99310 https://github.com/UT99310,

I had a similar issue, I think, a while back with my Acer C710, which has
since bit the dust.
The problem was in the file /usr/share/vboot/bin/make_dev_ssd.sh where it
was only looking at dm-0 instead of dm-[0-9]. Look at line # 65 or there
abouts. I filed a bug report
https://code.google.com/p/chromium/issues/detail?id=428041 and it was
resolved.

Hopefully this hasn't reared it's ugly head again...

—
Reply to this email directly or view it on GitHub
#582 (comment).

[tr0043t]

For the record, this didn't end well. Something in the new CrOS update
really confused the modules, and ultimately I could not reboot. I do have a
crouton backup from a few days ago that will get me back to some known
state. Just got back into fresh dev mode -- takes quite a while with 128G
SSD.

On Thu, Apr 16, 2015 at 4:53 PM, Lauren Weinstein [email protected]
wrote:

There clearly were changes that had unexpected (to me) effects in the last
CrOS update, there's now a conflict in the vb driver name paths that wasn't
there before. I'm working on it.

On Thu, Apr 16, 2015 at 4:49 PM, DennisL [email protected] wrote:

@UT99310 https://github.com/UT99310,

I had a similar issue, I think, a while back with my Acer C710, which has
since bit the dust.
The problem was in the file /usr/share/vboot/bin/make_dev_ssd.sh where
it was only looking at dm-0 instead of dm-[0-9]. Look at line # 65 or
there abouts. I filed a bug report
https://code.google.com/p/chromium/issues/detail?id=428041 and it was
resolved.

Hopefully this hasn't reared it's ugly head again...

—
Reply to this email directly or view it on GitHub
#582 (comment).

[tr0043t]

I got VB running on the previous CrOS version under Crouton w/o much difficulty, but when CrOS updated yesterday I ran into trouble. In fact, I ended up unbootable and had to restore from my most recent Crouton backup. Now I'm back to the point where VB starts but I'm getting the VT-x is Disabled error (which I did not see on my previous install of VB). I'd prefer not to blow away the system again if possible. Any suggestions? Thanks!

[tr0043t]

Got VT-x working again. Even though the kernel flags were already changed appropriately, the partition was back in a locked state -- this prevented VT-x from functioning. Unlocked partition again using the script for making root writeable -- and VT-x popped back in.