maemo.org - Talk - Easy Debian Fremantle Beta Testing

maemo.org - Talk (https://talk.maemo.org/index.php)

- Alternatives (https://talk.maemo.org/forumdisplay.php?f=36)

- - Easy Debian Fremantle Beta Testing (https://talk.maemo.org/showthread.php?t=34550)

Re: Easy Debian Fremantle Beta Testing

Well, as I said, I later realized that I did not need to edit that much but that was only on editing my third script when I found out about using 'none'. I started off by using IMGFILE=/path/to/my/chroot/dir and leaving CHROOT alone. That required editing qmount to add a case for a directory which I later reverted.

However, valdur55's post did not cure the "Nothing to do" problem, I had to edit closechroot thus:

Code:

pp900-a:/sbin# diff closechroot closechroot.old

--- closechroot

+++ closechroot.old

@@ -29,7 +29,7 @@

 fi

 

 #Abort if chroot not mounted.

-if [ "$IMGFILE" != "none" ] && [ ! -f "$CHROOT/var/lock/qmount-complete" ] ; then

+if [ ! -f "$CHROOT/var/lock/qmount-complete" ] ; then

   echo "Nothing to do; chroot not mounted!"

   exit 1

 fi

@@ -58,11 +58,22 @@

 

 echo "...closing chroot apps..."

 

-if [ -f "/bin/gfuser" ] ; then

-  gfuser "$CHROOT" -k

+TEST1=`mount | grep " $CHROOT "`

+MAPPER=`mount | grep "/dev/mapper"`

+if [ "x$TEST1" != "x" ] && [ "x$MAPPER" == "x" ] ; then

+  if [ -f "/bin/gfuser" ] ; then

+    gfuser -m "$CHROOT" -k

+  else

+    cd /proc

+    fuser -m "$CHROOT" -k

+  fi

 else

-  cd /proc

-  fuser "$CHROOT" -k

+  if [ -f "/bin/gfuser" ] ; then

+    gfuser "$CHROOT" -k

+  else

+    cd /proc

+    fuser "$CHROOT" -k

+  fi

 fi

 

 echo "..Unmounting bound dirs..."

@@ -87,9 +98,7 @@

   rm "$CHROOT/var/lock/chroot-complete"

 fi

 

-if [ "$IMGFILE" != "none" ] ; then

-  /sbin/qumount $CHROOT

-fi

+/sbin/qumount $CHROOT

 

 echo "chroot closed."

 exit 0

\ No newline at end of file

pp900-a:/sbin#

Basically, adding a test for $IMGFILE!=none in two places and removing -m in the call to fuser as it was causing aforementioned issues.

I have also edited qchroot to alter some mounts but that is just my preference and I am not suggesting that it should be in any way taken seriously. I just did not think ED needed to know about my entire /home tree (which would include ED recursively). Mounting user's home dir ought to be enough for everybody ;)

Code:

pp900-a:/sbin# diff qchroot qchroot.old 

--- qchroot

+++ qchroot.old

@@ -76,10 +76,10 @@

 

   #Mount the user's home dir

   echo .... >/dev/stderr

-  mount -o bind /home/user "$CHROOT/home/user"

+  #mount -o bind /home/user "$CHROOT/home/user"

 

   # Do it the Fremantle way.

-  #mount /dev/mmcblk0p2 "$CHROOT/home"

+  mount /dev/mmcblk0p2 "$CHROOT/home"

   mount /dev/mmcblk0p1 "$CHROOT/home/user/MyDocs"

   

   #Make DBus work

pp900-a:/sbin#

Re: Easy Debian Fremantle Beta Testing

After many months of constant development, the Debian project is proud to present its new stable version 7.0 (code name Wheezy).
http://lists.debian.org/debian-annou.../msg00002.html

When will the new image Easy Debian of Wheezy?

Re: Easy Debian Fremantle Beta Testing

When somebody at mainstream will care to fix critical bugs we have reported ages ago :[ I have quite polished wheezy ED image, but it's no joy, if glibc is borked (so no gparted and friends), GIMP is borked, Chromium is borked...

/Estel

Re: Easy Debian Fremantle Beta Testing

Please forgive me a naive question. I've wanted to ask for a long time but felt too embarrassed. Finally the curiosity got the better of me :)

I was trying to implement "easier-than-Easy" Debian by adding Debian repositories to FAM but nothing happened. No Debian packages appeared on the list. Why?

Re: Easy Debian Fremantle Beta Testing

Quote:

Originally Posted by pichlo (Post 1345214)

You'd need to view hidden packages too. But easier than Easy Debian isn't a good idea as it's not optified

Re: Easy Debian Fremantle Beta Testing

Of course I've checked hidden packages.

I am not too bothered about optification. I have 80 MB in root and was intending to install apps one at a time and optify manually.

Re: Easy Debian Fremantle Beta Testing

No errors during fapt-get update?

Re: Easy Debian Fremantle Beta Testing

Hopefully I may be able to tell you in an hour or so. I was fiddling with it to the point of getting myself into a boot loop so now I have to reflash.

Edit (a few hours later):
Reflashed, restored from backupmenu backup, added Debian repos and... it works! I don't know what I did wrong the last time. Most likely a typo in the URL or something like that.

But there is a small problem. I can't install anything from the Debian repos because the Maemno packages are so old that installing even the simplest Debian package requires to upgrade pretty much everything. (Which is how I ended up with an unbootable device in the first place. Tried to upgrade libc6 manually and ended up with a partial installation that went boom on the next reboot.)

Re: Easy Debian Fremantle Beta Testing

Quote:

Originally Posted by pichlo (Post 1341275)

Basically, adding a test for $IMGFILE!=none in two places and removing -m in the call to fuser as it was causing aforementioned issues.

I'm just in process of setting ED to use directory on /opt myself, and I noticed, that your closechroot modification contains something else (as addition to mentioned checks and removing -m):

Code:

TEST1=`mount | grep " $CHROOT "`

MAPPER=`mount | grep "/dev/mapper"`

if [ "x$TEST1" != "x" ] && [ "x$MAPPER" == "x" ] ; then

  if [ -f "/bin/gfuser" ] ; then

    gfuser -m "$CHROOT" -k

  else

    cd /proc

    fuser -m "$CHROOT" -k

  fi

 else

  cd /proc

  fuser "$CHROOT" -k

Above bunch of tests got removed, and replaced by just [i]cd /proc; fuser "$CHROOT -k[/code]. Any idea, why it did all the trickery to decide between gfuser (in case of using /dev/mapper = using loopback file) or fuser (and fallback to fuser in case of gfuser absence, even for said loopback file) in the first time? Also, why you've decided to remove it?

I would like to (one day) sum up all fixes, add some more (like removing dependency on murrina night orange in *maemo's* repos, which mess with some non-ed GTK programs, making using them harder), then, upload new version of easy debian package. Thus, Imm interested, why gfsuer was considered better for some specific scenario (and ithus, if that code snippet is worth keeping).

/Estel

//Edit

A sidenote:

Quote:

Originally Posted by pichlo (Post 1341275)

I just did not think ED needed to know about my entire /home tree (which would include ED recursively). Mounting user's home dir ought to be enough for everybody ;)

Code:

pp900-a:/sbin# diff qchroot qchroot.old 

--- qchroot

+++ qchroot.old

@@ -76,10 +76,10 @@

 

   #Mount the user's home dir

   echo .... >/dev/stderr

-  mount -o bind /home/user "$CHROOT/home/user"

+  #mount -o bind /home/user "$CHROOT/home/user"

 

   # Do it the Fremantle way.

-  #mount /dev/mmcblk0p2 "$CHROOT/home"

+  mount /dev/mmcblk0p2 "$CHROOT/home"

   mount /dev/mmcblk0p1 "$CHROOT/home/user/MyDocs"

   

   #Make DBus work

pp900-a:/sbin#

I do not recommend mounting /home/user *at all* in any form for ED. If you investigate latest (Squeeze and later) images, they contain onchrootmount (or smth like that) script, that gets executed from within ED, and umount /dev/mmcblk0p2 (for ED only). It's due to fact, that having /home shared between ED and Maemo leaves you with total mess, if you try to move your ED imgfile/partition content/directory content to another device, or share it with someone (like with images in this thread). Obviously, it would require to also distribute parts of your /home/, but only those related to ED - post-separating them is PITA.

BTW, I know, that mounting it in qchroot, then, unmounting second later by some on<whatever>chroot script is stupid. I think qole decided on this approach, as he wanted to avoid updating easy debian package in Maemo repos for all cost (probably, he didn't wanted to go through promotion to extras, again).

This is also going to be fixed when/if I come to releae updated version - so, as you have browsed trough those scripts already, is it only place where something related to /dev/mmclk0p2 or Maemo's /home/ is executed?

// Edit 2
Just finished it, everything works as OK. First impression - initial start is, obviously, even faster than with native partition - due to skipping mounting part. Thanks a lot valdur55 and pichlo for solutions on fixing ED scripts!

Re: Easy Debian Fremantle Beta Testing

Quote:

Originally Posted by Estel (Post 1350830)

Any idea, why it did all the trickery to decide between gfuser (in case of using /dev/mapper = using loopback file) or fuser (and fallback to fuser in case of gfuser absence, even for said loopback file) in the first time? Also, why you've decided to remove it?

I don't quite remember. It may have been something trivial, like gfuser not being present on my phone so what's the point checking. Why it was implemented that way to start with I have no idea. It worked for me in the simplified form. I am sure someone more knowledgeable can answer it better as this was the first time I found out about fuser :-)

Quote:

Ah, thanks, good to know. I ended up having to do a bit more due to the fact that I started from the minimal (50MB) image and built up. That image turned out to be quite out of date so I might have done better starting from your Squeeze image and remove things.

I have since moved on to a bigger challenge, trying to install and run Debian packages directly without chrooting. I have not had much success yet as per a couple of posts above but now I have a spare device to thrash so I am not giving up yet.