"bootmanger" For Zaurus

[CoreDump]

Hey all!

I'm currently in the process of writing a "boot manager" for Zaurus which allows booting
off of SD and CF cards.

The current features are:
 - Can boot a "real" filesystem from SD and CF
 - Can boot ext2 loop-images containing a filesystem from SD and CF
 - loop-images are fsck'ed on each boot.
 - Allows to boot into other runlevels
   ( This is interesting for OZ 3.5.4 as it features a new, GUI-less runlevel)
 - Allows to drop into an emergency shell (init=/bin/sh)
   This is a real life-saver when messing w^H^H^H^H^H debugging the device

I've currently only tested it on Collie (Z5500 / Z5000). To make it work on the clam-shells
(or any other Z now shipping w/ kernel 2.6) I'd need volunteers.

Someone needs to figure out how to mount the SD and CF cardfs under kernel 2.6, that's basically all.
A basic manual can be found here: http://www.hentges.net/misc/openzaurus/docs/altboot.shtml

and the.ipk is here: http://hentges.net/tmp/altboot/ (yep, no messing with the system required, just install and be done with it  )

NOTE: Installing this ipk might render your Z unbootable (if Z != collie and OS != OZ 3.5.x)
PLEASE BACKUP ALL IMPORTANT DATA

I can upload some ext2 collie images to play with if you want. I have a shiny new opie snappshot lying around and a combined opie/GPE ROM. However, since the image are device-dependent, they'll only work on collie.

[Greg2]

I can upload some ext2 collie images to play with if you want. I have a shiny new opie snappshot lying around and a combined opie/GPE ROM.

I just looked at your manual and it sounds like I can place one of your ext2 images on my SD-card and select at boot... so if you what to upload that Opie/GPE 'rom' (koen doesn't like the 'rom' word)    I'll be happy to give it a try!

Greg

[CoreDump]

I can upload some ext2 collie images to play with if you want. I have a shiny new opie snappshot lying around and a combined opie/GPE ROM.

I just looked at your manual and it sounds like I can place one of your ext2 images on my SD-card and select at boot... so if you what to upload that Opie/GPE 'rom' (koen doesn't like the 'rom' word)    I'll be happy to give it a try!

Greg
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

Hey Greg  
After booting, you can umount the "ROM". That is as read-only as it gets heh  

The "Image" is here:
[a href=\"http://www.hentges.net/tmp/altboot/oz3.5.3-opie-gpe-1.2.0-ext2loop_T2-RC3-DE.tar.gz]http://www.hentges.net/tmp/altboot/oz3.5.3...2-RC3-DE.tar.gz[/url]

Put rootfs.bin into /media/[card|cf]/boot-images and select "Boot SD card"

GPE is on VT2, Opie on VT3

Have fun

[Greg2]

I thought if I was going to do some testing/playing with your boot manager I would go ahead and install your T2-rc2 with the cardfs-r6. I found it mounted the SD-card as read-only... lol!  

Anyway, the boot manager works great and your Opie/GPE-ext2loop image works very well. Your making this too easy... I'm ashamed to say how long it took me to make that work last year with 3.5.1.

Let me know if there is anything you want me to check with this setup.

Thanks for the boot manager.

Greg

[CoreDump]

I thought if I was going to do some testing/playing with your boot manager I would go ahead and install your T2-rc2 with the cardfs-r6. I found it mounted the SD-card as read-only... lol!

You've probably aborted the filesystem check of the SD card on boot?

Anyway, the boot manager works great and your Opie/GPE-ext2loop image works very well. Your making this too easy... I'm ashamed to say how long it took me to make that work last year with 3.5.1.

As a matter of fact, I failed doing this under 3.5.1  

Let me know if there is anything you want me to check with this setup.

I'm more of an Opie guy and creating this image was a proof-of-concept type thing.
I wanted to know if such a setup is possible. Looks like it is  

GPE has matured greatly since the 3.5.1 days and looks quite good but it is still suffering from small problems which add up quickly. I see a great future for GPE though.

Thanks for the boot manager.
Greg
[div align=\"right\"][a href=\"index.php?act=findpost&pid=82086\"][{POST_SNAPBACK}][/a][/div]

You're welcome  

I'm still hoping that a clam-shell user ports the bootmanager to his device. altboot will very likely end up in the OZ feed in the next release and having it work on most devices would be great .

While booting from SD and CF is quite a nice thing (IMHO), the real "killer" feature for Linux professionals will probably be the emergency shell (init=/bin/sh).

Maybe I'll think up a way to detect if the last boot was unsuccessful and boot the shell on the next run
even if altboot is turned off. This could be a real life saver  

[Greg2]

I thought if I was going to do some testing/playing with your boot manager I would go ahead and install your T2-rc2 with the cardfs-r6. I found it mounted the SD-card as read-only... lol!

You've probably aborted the filesystem check of the SD card on boot?

Your correct, that was the cause of it. For my own curiosity... why does it happen if you don't check the filesystem on boot?

I see it changes from

(rw,noatime,nodev)

to

(ro,noatime,nodev)

but I don't know what changes it?

Greg

[CoreDump]

I thought if I was going to do some testing/playing with your boot manager I would go ahead and install your T2-rc2 with the cardfs-r6. I found it mounted the SD-card as read-only... lol!

You've probably aborted the filesystem check of the SD card on boot?

Your correct, that was the cause of it. For my own curiosity... why does it happen if you don't check the filesystem on boot?

I see it changes from

(rw,noatime,nodev)

to

(ro,noatime,nodev)

but I don't know what changes it?

Greg
[div align=\"right\"][a href=\"index.php?act=findpost&pid=82153\"][{POST_SNAPBACK}][/a][/div]

This was actually a wanted behaviour at some point but tends to be quite annyoing from time to time.
I'll rework the whole scanning script anyways since it is less that ideal currently and the "ro" mount will be thrown out.

The reason was the following: Only if errors on the card are detected you'll see the red "popup" asking if you'd like to repair the card. If you choose not to, it would be mounted "ro" so the filesystem damage doesn't get worse.

[Greg2]

Thanks for explaining this to me. I have been checking how you have made this work, and I think that it can work on a poodle without too much trouble.

I know you don't have a poodle, but it appears that the init.d/sd and the sdcontrol are identical between your collie and my poodle. The fstab I can change with no problems. The one I don't completely understand is your hotplug script... do you think that I can use that in my poodle without any problems? If I would use it do you know of anything else that I might need to change to keep the system working?

Now if I can make those changes and keep the system running and stable with SD-card... your altboot_xxx_collie.ipk looks like a 'close' fit, 'close' meaning that I could probably make it work. I can only find one referance to /dev/mtdblock6 in the 21-bootRAM that would be a problem, but I don't think it would be used here? (there is the possibility that I'm completely wrong about this whole thing)

Sorry for all the stupid questions, but I'm just starting to think that I 'partially' understand how this works. Unfortunately making it work for me and getting it in OE... I understand even less. I have however been reading about OE and the build process a good bit lately.

Thanks for your time,

Greg

[CoreDump]

Thanks for explaining this to me. I have been checking how you have made this work, and I think that it can work on a poodle without too much trouble.

Yes, a poodle is probably close enough to a collie that only very few adjustments were needed.

I know you don't have a poodle, but it appears that the init.d/sd and the sdcontrol are identical between your collie and my poodle.

Correct. AFAIK, sdcontrol was identical on all Z's. Since most devices now run a 2.6 kernel, this has changed. sdcontrol only works on Z's w/ a 2.4 kernel. FYI the sdcontrol shipped w/ this ROM is the same as shipped w/ OZ 3.5.3

The fstab I can change with no problems. The one I don't completely understand is your hotplug script... do you think that I can use that in my poodle without any problems? If I would use it do you know of anything else that I might need to change to keep the system working?

Hmm, I don't remember hacking the hotplug stuff. What exactly do you mean?

Now if I can make those changes and keep the system running and stable with SD-card... your altboot_xxx_collie.ipk looks like a 'close' fit, 'close' meaning that I could probably make it work.

Please let me know of any changes you have applied

I can only find one referance to /dev/mtdblock6 in the 21-bootRAM that would be a problem, but I don't think it would be used here? (there is the possibility that I'm completely wrong about this whole thing)

You are correct, bootRAM never worked. The only thing I've used it for was debugging pivot_root.
Since I do not believe that anyone is as "crazy" as trying to boot off of RAM, I'll probably remove it.
I have no intention of finishing this script.

Sorry for all the stupid questions, but I'm just starting to think that I 'partially' understand how this works.

Your questions are valid and by no means stupid  

Unfortunately making it work for me and getting it in OE... I understand even less. I have however been reading about OE and the build process a good bit lately.

Leave the OE part to me. I'll apply all poodle- and hentges specific stuff to my (public) CVS - which is pulled for the altboot.bb. If this works out, I'll ship hentges ROMs for the poodle, too. After the "porting" is done, that'd be no problem and just one more 4 hour compile heh.

[Greg2]

Yes, a poodle is probably close enough to a collie that only very few adjustments were needed.

I'm using this on my collie now, I haven't yet but I will give it a try on my poodle. If or when it works I will let you know of any changes I've made.

Hmm, I don't remember hacking the hotplug stuff. What exactly do you mean?

Edit:
I'm sorry they are the same... this one is from etc/sysconfig/hotplug. (that had me even more confused) I think I will have to change this one also?

Code: [Select]

##
## Each of these may be assigned to the number of nanoseconds by which to
## increase the timing of pcmcia bus transactions
##
# COMPACTFLASH_TIMING_INCREMENT=0
## the single pcmcia sleeve seems to be a bit slow, but 25ns makes my
## orinoco card detectable. -Jamey 4/2/2002
PCMCIA_TIMING_INCREMENT=25
# DUAL_PCMCIA_TIMING_INCREMENT=0

## mount options used by MMC
MMC_MOUNT_OPTIONS="-t auto -o sync,noatime"

Leave the OE part to me. I'll apply all poodle- and hentges specific stuff to my (public) CVS - which is pulled for the altboot.bb. If this works out, I'll ship hentges ROMs for the poodle, too. After the "porting" is done, that'd be no problem and just one more 4 hour compile heh.

Thank you, that is a very generous offer. I will work on this when I have the time.

Thanks again,

Greg

[Greg2]

It's installed on my poodle and it when it boots it gives me all the options... I select '1' and it boots into Opie as normal!

I only had to change the control file for ipkg:

Architecture: collie
to
Architecture: arm

It wouldn't accept that... heh

After all the careful checking of both systems... not a thing had to be modified for the poodle.

Now I need a simple howto for that ext2loop_rootfs.bin... unless you can supply a small one for testing to prove that this works on a poodle. I would be happy with a bootstrap.

Thanks,

Greg

[CoreDump]

It's installed on my poodle and it when it boots it gives me all the options... I select '1' and it boots into Opie as normal!

I only had to change the control file for ipkg:

Architecture: collie
to
Architecture: arm

That was expected as only "collie" is a valid target currently. I'll push a poodle config into OE (altboot_poodle here we come)

After all the careful checking of both systems... not a thing had to be modified for the poodle.

Now I need a simple howto for that ext2loop_rootfs.bin... unless you can supply a small one for testing to prove that this works on a poodle. I would be happy with a bootstrap.

Thanks,

Greg
[div align=\"right\"][a href=\"index.php?act=findpost&pid=82310\"][{POST_SNAPBACK}][/a][/div]

Great!
I'll setup a poodle environment today to build a full image. That's going to take some time though

[JohnX]

Thank you CoreDump!
This is exactly what I was looking for.  I've been hacking around with this a bit in the last couple days and I can now boot to a shell from an image that I made out of the pocketworkstation v.18 tgz file.  I'm at school right now and I can't get the zaurus on the VPN'ed wireless net here, so I can't post my whole setup.  But below is the general path that I followed to make this work.  A couple things to note before I go on:
1) I may have made some typos or forgot some details, so if a command doesn't make sense to you, look it up instead of trusting me blindly.
2) This is strictly YMMV, it worked for me but it may just cause your zaurus to burst into flames.
3) I think this goes without saying, but don't even try this if you're not comfortable hacking around in mostly broken linux systems, because that is what this will boot into, even if it works.

My setup:
Zaurus SL-5500
OZ/Opie 3.5.3 (with lots of other stuff installed from random places)

I first made the ext2 image file on my desktop computer (running Debian Sid).  There's no real reason that it couldn't be done on a Zaurus but I didn't test it that way so, YMMV:
touch zaurus.ext2
dd if=/dev/zero of=zaurus.ext2 count=200000

That will get you a file about 100MB in size.  Adjust the dd parameters accordingly for a different size.  Then I just made an ext2 filesystem on it:
mkfs.ext2 zaurus.ext2

Then I mounted it, and unpacked the pocketworkstation v.18 tgz file in it
(I used the pocketworkstation base image found here: http://pocketworkstation.org/files )

mount -o loop zaurus.ext2 /mnt/loop
cd /mnt/loop
tar zxvf /path/to/zaurus-debian-base-v0.18.tgz
cd /somewhere/else
umount /mnt/loop

Then I installed the altboot ipks to my zaurus, and copied the zaurus.ext2 file into /media/card/boot-images and renamed it to debian-rootfs.bin

When I tried to reboot into it I got errors.

I changed the following in /etc/altboot-menu/15-bootSD

The version of mount on my zaurus doesn't seem to cope well with the "-o loop" option. So I changed the line in 15-bootSD that mounts the image on the sd or cf card to instead run:
losetup /dev/loop1 $XX_MOUNTPOINT/$IMAGE_PATH/$IMAGE_NAME
mount /dev/loop1 /media/image

That made it mount the fs image on the card at least.  The second problem is that pocketworkstation was never really made to be a bootable system.  it was made to be chrooted from a running zaurus.  Because of that it doesn't contain such important things as an /etc/fstab.  This causes init to die in a not so graceful way.  So, I commented out the line in 15-bootSD that calls /sbin/init and replaced it with one that calls /bin/sh.  That part of my 15-bootSD file now looks like this:

exec /usr/sbin/chroot . /bin/sh >/dev/tty0 2> &1
#exec /usr/sbin/chroot . /sbin/init  6 >/dev/tty0 2>&1

If this works you'll be in a bash shell in the root of your debian install.  I haven't played with it much but I imagine most of it is fairly broken.
Thanks again to CoreDump and Mickey and all the other guys working on OZ for making it easier to hack on the zaurus.  Now I have to run to class cause I'm late.   Happy hacking!

-John

[CoreDump]

Thank you CoreDump!
This is exactly what I was looking for.  I've been hacking around with this a bit in the last couple days and I can now boot to a shell from an image that I made out of the pocketworkstation v.18 tgz file.

[...]

My setup:
Zaurus SL-5500
OZ/Opie 3.5.3 (with lots of other stuff installed from random places)

[...]

Then I installed the altboot ipks to my zaurus, and copied the zaurus.ext2 file into /media/card/boot-images and renamed it to debian-rootfs.bin

When I tried to reboot into it I got errors.

I changed the following in /etc/altboot-menu/15-bootSD

The version of mount on my zaurus doesn't seem to cope well with the "-o loop" option. So I changed the line in 15-bootSD that mounts the image on the sd or cf card to instead run:
losetup /dev/loop1 $XX_MOUNTPOINT/$IMAGE_PATH/$IMAGE_NAME
mount /dev/loop1 /media/image

Doh, busybox's mount was patched a few month ago to handle -o. Anyways, I've changed the script to use your version. Thanks!

The second problem is that pocketworkstation was never really made to be a bootable system.  it was made to be chrooted from a running zaurus.  Because of that it doesn't contain such important things as an /etc/fstab.  This causes init to die in a not so graceful way.

Ah, now that is a shame.

So, I commented out the line in 15-bootSD that calls /sbin/init and replaced it with one that calls /bin/sh.  That part of my 15-bootSD file now looks like this:

exec /usr/sbin/chroot . /bin/sh >/dev/tty0 2> &1
#exec /usr/sbin/chroot . /sbin/init  6 >/dev/tty0 2>&1

If this works you'll be in a bash shell in the root of your debian install.  I haven't played with it much but I imagine most of it is fairly broken.
Thanks again to CoreDump and Mickey and all the other guys working on OZ for making it easier to hack on the zaurus.  Now I have to run to class cause I'm late.   Happy hacking!

-John
[div align=\"right\"][a href=\"index.php?act=findpost&pid=82397\"][{POST_SNAPBACK}][/a][/div]

I tried booting PW in the past and it froze during INI. Maybe I could add a "init=/bin/sh" option to bootSD. For example:

[4] Boot SD card ->

[1] some-image-rootfs.bin
[2] another-rootfs.bin ->

[1] Normal boot
[2] init=/bin/sh

However, this menu should IMO be optional and be turned off by default in /etc/altboot.cfg
What do you think?

[JohnX]

I wouldn't worry about it.  The only people likely to need an option like that are the people who are hacking up their own ROM image.  It would be imppossible to chase down all the different options and script them in.  I'd rather have a simple straight-forward script to hack on, than one that tried to do everything and became so complex that it was difficult to understand and modify.

If you do end up adding something along those lines maybe something like this would be an idea:
[4] Boot SD card ->

[1] some-image-rootfs.bin
[2] another-rootfs.bin ->

[1] Normal boot
[2] Prompt for command to run on chroot ->

Enter the command to run: /sbin/init S

Anyways, I made a really simple fstab for PW and now I can run /sbin/init S and end up in single user mode.  PW relies on its "host" operating system to do so much that it's not really useful when it is run by itself.  No carctl is the real problem for me.  I'll hack on it a bit later...