headers
Sameer Naik | 1 Jun 2012 09:24

Re: Mounting Filesystem over existing directory

Hello Conrad,

First of, I was able to successfully test (very basic testing) unionfs
for my case. I used the latest version of unionfs (2.5.11).

On Wed, May 30, 2012 at 11:12 PM, Michael Conrad
<mconrad <at> intellitree.com> wrote:
> On 5/30/2012 3:08 AM, Sameer Naik wrote:
>>
>> Thanks for the quick response. I will check out the links Bartos provided.
>> Certainly, my query is not related to busybox, but where else can i
>> find a better community for my query :)
>>
>> Regards
>> ~Sameer
>
>
> Indeed, you're posting your question to a lot of people who have done this
> exact thing :-)
>
> I found aufs to be more experimental with lots of fancy features... but
> wasn't stable enough for me.  (this changes over time and by kernel version,
> of course, but when I tested it 3 years ago I got some strange results)
>  Unionfs has worked flawlessly for me on multiple kernels.

I was able to get UnionFS configured into the system rather quickly. I
will stick to unionfs, cause i don't think i need to do too many
"fancy" things.

>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Laurent Bercot | 1 Jun 2012 08:42
Favicon

Re: Mounting Filesystem over existing directory

> Out of curiosity, Is is possible to free up the resources used by
> initramfs. I would be very interested in knowing how this can be done.

 That is the point of switch_root.
 When you switch_root from an initramfs to another rootfs, you free up
all the initramfs resources.
 Of course, you can't do it if you are still using initramfs as your
"main" rootfs.

> In my case, i am developing a system for an embedded system with NAND
> storage. Due to NAND corruption issues that mostly arise right now is
> when system is powered off while NAND writes are being performed (i.e.
> when files are being flushed out to the filesystem). This corruption
> makes the system un-bootable. Due to this issue i want to make the
> NAND filesystem readonly. Only at the time of system updates the
> filesystem will be remounted in rw mode. This still leaves room for
> the corruption to occur during system updates.

 There's only one way to guarantee bootability even with updates:
have *two* read-only partitions for the rootfs. Boot on one; when you
download an update, write the binary file to the other one. Reboot. If
it boots, use the new partition as your new rootfs; if not, fall back
on the old one (it still works) and report a failure.

> Right now i am thinking of having a initramfs filesystem with a
> recovery system that starts a device recovery process if the system
> partition cannot be mounted. So the intention is:

 You can do that, but that means your device will be non-functional
(i.e. stuck in recovery mode) at the first failing update. (And trust
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tanguy Pruvot | 1 Jun 2012 12:44
Picon
Gravatar

[PATCH] modinfo: match more standard module fields and fix version field

Previously, -F version could match the srcversion= string.

before :
  ~ # modinfo -F version tiwlan_drv
  version:        6.1.2012.05.29
  version:        533BB7E5866E52F63B9ACCB
  version:        0x%x, oui=0x%x, 0x%x, 0x%x
  version:        0x%x

  ~ # modinfo tiwlan_drv
  filename:       tiwlan_drv.ko
  author:         Texas Instruments Inc - Retouched by CyanogenDefy
  license:        GPL
  vermagic:       2.6.32.9 preempt mod_unload ARMv7
  parm:           g_sdio_debug_level:debug level
  depends:

now :
  ~ # modinfo -F version tiwlan_drv
  version:        6.1.2012.05.29

  ~ # modinfo tiwlan_drv
  filename:       tiwlan_drv.ko
  license:        GPL
  author:         Texas Instruments Inc - Retouched by CyanogenDefy
  version:        6.1.2012.05.29
  srcversion:     533BB7E5866E52F63B9ACCB
  depends:
  uts_release:    2.6.32.9-g306944c
  vermagic:       2.6.32.9 preempt mod_unload ARMv7
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Conrad | 1 Jun 2012 22:01

Re: Mounting Filesystem over existing directory

On 5/31/2012 2:04 AM, Bartos-Elekes Zsolt wrote:
> Michael Conrad wrote:
>
>> Unionfs has one problem though: the only way to get correct behavior 
>> is to merge path A and B onto mountpoint C.  (C can't be the same as 
>> A or B).
>
> Perhaps this is valid only for older versions of unionfs. I am using 
> unionfs mounted on /var that is composed of a tmpfs mounted on 
> /mnt/tmpfs, and the original /var that is on the flash (containing 
> only a few important files and directories that must be preserved 
> across reboots, like /var/lib/dpkg).
>
> $ mount | grep "unionfs"
> unionfs on /var type unionfs (rw,relatime,dirs=/mnt/tmpfs=rw:/var=rw)
>
...

On 6/1/2012 3:24 AM, Sameer Naik wrote:

> With UnionFS-2.5.11 i could merge /var/cache/etc=rw and /etc=ro at
> /etc. But evidently i have no real world testing going on here. Is
> there any specific test case i should try to confirm this?

I think I was remembering it wrong.  I think my actual problem was 
because I was trying to put the union on "/", and so the source of the 
union was *under* the mount-point.  And who knows, this might work now too.

-Mike
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Conrad | 1 Jun 2012 22:56

Re: Mounting Filesystem over existing directory

On 6/1/2012 2:42 AM, Laurent Bercot wrote:
>> Out of curiosity, Is is possible to free up the resources used by
>> initramfs. I would be very interested in knowing how this can be done.
Initramfs is really just a tmpfs which the kernel copies files into at 
boot-time.  You free it by removing all files from it, and unmounting it 
(after switch_root, because you can't unmount "/").

My initramfs was only 5MB (busybox, rsync, dropbear-sshd, some symlinks 
and a script) so I didn't care.  I want busybox loaded into ram for the 
entire life of the system, so I could just "rm" the others to reclaim a 
tiny bit of ram and that's pretty much optimal for me.

>> In my case, i am developing a system for an embedded system with NAND
>> storage. Due to NAND corruption issues that mostly arise right now is
>> when system is powered off while NAND writes are being performed (i.e.
>> when files are being flushed out to the filesystem). This corruption
>> makes the system un-bootable. Due to this issue i want to make the
>> NAND filesystem readonly. Only at the time of system updates the
>> filesystem will be remounted in rw mode. This still leaves room for
>> the corruption to occur during system updates.
>   There's only one way to guarantee bootability even with updates:
> have *two* read-only partitions for the rootfs. Boot on one; when you
> download an update, write the binary file to the other one. Reboot. If
> it boots, use the new partition as your new rootfs; if not, fall back
> on the old one (it still works) and report a failure.
>> Right now i am thinking of having a initramfs filesystem with a
>> recovery system that starts a device recovery process if the system
>> partition cannot be mounted. So the intention is:
>   You can do that, but that means your device will be non-functional
> (i.e. stuck in recovery mode) at the first failing update. (And trust
(Continue reading)

Permalink | Reply | 1 comment |
headers
Laurent Bercot | 2 Jun 2012 11:18
Favicon

Re: Mounting Filesystem over existing directory

> Interesting.  But where do you have the logic for choosing a boot 
> device?

 This is very platform-dependent. Usually, embedded devices will have
some EEPROM-equivalent switches, accessible via /dev/something or a
platform-dependent binary; you just need to store 2 bits of information,
the hardware should support that. Professional embedded devices will
even require a more complex boot process with a cryptographically
signed boot loader; on those, the hardware will give you a lot of room
to store boot-related flags.

> What if your new partition is fine, but core services fail to 
> load?  How do you recognize that you need to start over with a different 
> root partition?

 Only say "ok to switch partitions" at the end of the boot process, of
course, after verification that everything works properly. To ensure
that core services work, you can use a supervision system. I wrote s6
just for this: http://www.skarnet.org/software/s6/

> If anything goes wrong with the new version, I just pop in a USB drive 
> with the old version.  The initramfs is simple enough that it never 
> needs changed.

 As long as the user has a working version on a USB drive, that's a
viable solution. My approach was made for embedded systems where the
user has access to nothing at all - he wants it to just work once it's
plugged in and switched on.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Denys Vlasenko | 3 Jun 2012 15:34

Re: busybox 1.20.*

[CCing busybox <at> busybox.net]

On Thursday 31 May 2012 04:32, Joe Zeppie wrote:
> There seems to be a large bug in the most recent busybox builds in that awk
> can no longer do simple mathematical calculations.

$ cd testsuite
$ ./runtest awk
PASS: awk -F case 0
PASS: awk -F case 1
PASS: awk -F case 2
PASS: awk -F case 3
PASS: awk -F case 4
PASS: awk -F case 5
PASS: awk -F case 6
PASS: awk -F case 7
PASS: awk bitwise op
PASS: awk hex const 1
PASS: awk hex const 2
PASS: awk oct const
PASS: awk floating const with leading zeroes
PASS: awk long field sep
PASS: awk gsub falls back to non-extended-regex
PASS: awk 'gcc build bug'
PASS: awk NF in BEGIN
PASS: awk string cast (bug 725)
PASS: awk handles whitespace before array subscript
PASS: awk handles non-existing file correctly
PASS: awk nested loops with the same variable
PASS: awk handles empty ()
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rich Felker | 3 Jun 2012 15:54

Re: Bug in busybox sed - this one is real

Ping. Anybody looked at this? I filed it as bug # 5246.

Rich

On Mon, May 07, 2012 at 11:12:09PM -0400, Rich Felker wrote:
> $ echo hello | busybox sed 's/l*/ <at> /g'
>  <at> he <at> o
> $ echo hello | sed 's/l*/ <at> /g'
>  <at> h <at> e <at> o <at> 
> 
> The latter is of course correct. My naive diagnosis is that Busybox
> sed's 'g' option has an off-by-one error in its next-match search,
> i.e. advanced by one character too many before searching for the next
> match.
> 
> Rich
> _______________________________________________
> busybox mailing list
> busybox <at> busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
Permalink | Reply | 14 comments |
headers
Tias Guns | 3 Jun 2012 16:43
Favicon

android fixes, first series of patches v2

Thanks for the feedback received so far, this series incorporates the feedback:
- CONFIG_FEATURE_LS_COLOR_IS_DEFAULT is not set
- remove the older duplicate SYS_ioprio replace
- use ifdef S_TYPEIS* guarding

Kind regards,
Tias
Permalink | Reply | 9 comments |
headers
Tias Guns | 3 Jun 2012 16:43
Favicon

[PATCH 1/6] android: some sensible defconfig changes

- no /usr
- no skip rootfs
- use /system/lib/modules

And for niceties:
- show usage
- have installer
- long opts
- verbose cp
- ls --color support
- bbconfig

Also adds lsof (new in 1.20.0)

Signed-off-by: Tias Guns <tias <at> ulyssis.org>
---
 configs/android_ndk_defconfig |   28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/configs/android_ndk_defconfig b/configs/android_ndk_defconfig
index bf8827a..332bea6 100644
--- a/configs/android_ndk_defconfig
+++ b/configs/android_ndk_defconfig
 <at>  <at>  -1,7 +1,7  <at>  <at> 
 #
 # Automatically generated make config: don't edit
-# Busybox version: 1.20.0.git
-# Fri Mar  2 16:53:26 2012
+# Busybox version: 1.21.0.git
+# Mon May 28 21:51:18 2012
(Continue reading)

Permalink | Reply | 1 comment |

Gmane