Active Topics

 


Page 11 of 33 « First 910 11 121321 Last »
Reply
Thread Tools
titan is offline titan
2009-12-30 , 12:03
Posts: 946 | Thanked: 1,650 times | Joined on Oct 2009 @ Germany
#101
Originally Posted by bastler View Post
- we cannot just resize "root" (repartition) because it's on a seperate physical device.
- we cannot get rid of the vfat-partition completely because the camera application (anything else?) can only store data on vfat
- some users might need vfat for MS-Windows compatibility
Is this about correct or did I miss something?
1) the root partition makes sense as this is what the flasher overwrites
and which gives you a basic working system. home should be the user's playground.

2) the camera app works with a FAT32 image file mounted as loop device.
so we can get rid of the FAT partition completely and replace it by FAT images.

3) same as 2), you can keep a FAT image for M$ compatibility.

1. When doing the VFAT via the sparse image: does it shrink again once files are removed? Someone mentioned earlier that it wouldn't...
no. but in theory it should be possible to "sparsify" a ext3 file with
holes defined by the cluster allocation in the FAT image.
virtual machine users would benefit from such a feature as well.
For now we should stick to "dense" images for normal users.
advanced users can use the same tricks as for the virtual machine harddisks.
2. If it's just the camera, what about having it store data onto the SD? There's already an option for that builtin.
we cannot force users to buy a SD for taking pictures.

Dreaming further: I don't use Windows, so with the camera shooting to SD, to hell with the internal vfat partition. Could I instead just get one large ext3-partition containing /home (and /home/MyDocs as a subfolder if I must) and export that to usb?
ext4 would also be interesting, but I'm not sure wether the N900's kernel supports it
you may have a single ext3/4 partition on the flash but you cannot export it
while it's mounted. you could, however, export it via NFS or export ext3 image files.

As for installing foreign packages: I don't completely understand yet how this works exactly, but couldn't we just "export" /usr/ to the large flash the same way /opt/ is exported now? Shouldn't that solve the problem and be a lot easier than migrating "root" to a LVM on a live system?
I don't understand why did not stick to the original UNIX layout.
/usr, /bin etc. are stored on /
and the hierarchy /usr/local is for user installed applications.
/usr/local/bin, lib, share, icons etc. are added to the standard search paths
so that all user apps are found automatically.
The flash could be mounted on /mmc with symlinks
/usr/local -> /mmc/local
/home -> /mmc/home
maybe /etc/local -> /usr/local/etc
additionally, we could have /usr/local/stow for non-debianized stuff.
why all the hassle with bind, /opt, LVM, AUFS?
 

The Following 2 Users Say Thank You to titan For This Useful Post:
soeiro is offline soeiro
2009-12-30 , 13:31
Posts: 292 | Thanked: 131 times | Joined on Dec 2009
#102
Originally Posted by titan View Post
I don't understand why did not stick to the original UNIX layout.
/usr, /bin etc. are stored on /
and the hierarchy /usr/local is for user installed applications.
/usr/local/bin, lib, share, icons etc. are added to the standard search paths
so that all user apps are found automatically.
The flash could be mounted on /mmc with symlinks
/usr/local -> /mmc/local
/home -> /mmc/home
maybe /etc/local -> /usr/local/etc
additionally, we could have /usr/local/stow for non-debianized stuff.
why all the hassle with bind, /opt, LVM, AUFS?
Ok. Considering the current N900 hardware:

1) What do we do about /usr and /etc? Do you think symlinking or mounting them on the MMC would slow down the device?

2) In the case that the flasher tool or Nokia firmware updates expect the exact current layout (and that it can't be changed), wouldn't AUFS, UnionFS (or maybe even LVM) help?

The scenario would be the following:
a) AUFS is configured to readonly for /oneNAND
b) AUFS writes every change to /usr , /etc and so on to /mmc
c) home, MyDocs, etc work just as proposed

Would this scenario allow a simpler firmware update usage, assuming it will overwrite rootfs, but during the next boot, AUFS would keep placing new stuf in /mmc?

Considering a major firmware upgrade:

It seems to be possible for a new firmware upgrade to restructure both the rootfs and the MMC in order stick to standard Unix Layout. Of course, the flasher could backup user files before and place them on the correct places afterwards. Advanced users could be warned that they would have to manually correct things aftewards. No more, 256MB limit, no more 2GB limit, no more hardcoded MyDocs. Everybody would be happy hereafter.
 
javispedro's Avatar
javispedro is offline javispedro
2009-12-30 , 13:36
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#103
Yet another Opt thread: http://wiki.maemo.org/Opt_Problem. Feel free to extend that with your data.
 

The Following User Says Thank You to javispedro For This Useful Post:
ruskie is offline ruskie
2009-12-30 , 13:52
Posts: 543 | Thanked: 181 times | Joined on Aug 2009 @ Universe,LocalCluster.MilkyWay.Sol.Earth.Europe.Slovenia.Ljubljana
#104
Well added my suggestions... doubt it'll help but still. Anyway it's not another Opt thread. It devolved into that. It's still a repartioning practical examples 101 thread
 
bastler's Avatar
bastler is offline bastler
2009-12-30 , 14:26
Posts: 31 | Thanked: 11 times | Joined on Dec 2009
#105
Originally Posted by titan View Post
1) the root partition makes sense as this is what the flasher overwrites
and which gives you a basic working system. home should be the user's playground.
Agreed


Originally Posted by titan View Post
we cannot force users to buy a SD for taking pictures.
I see your point, but that means it would be a marketing decision, from a technical viewpoint it's possible, right?

Originally Posted by titan View Post
you may have a single ext3/4 partition on the flash but you cannot export it
while it's mounted.
I knew I'd missed something. So basically (to get back to the practical examples) if I for me personally decided that I don't need an internal vfat partition and deleted it in favour of a large ext3 home partition I could no longer access it via USB cable?
I get your problem... That'd suck!
 
soeiro is offline soeiro
2009-12-30 , 16:55
Posts: 292 | Thanked: 131 times | Joined on Dec 2009
#106
Has anybody tried the feasibility of leaving only the basic rootfs in place and mounting everything else in the MMC (/usr, /opt, /home, etc)?
Last edited by soeiro; 2009-12-30 at 16:55. Reason: grammar
 
titan is offline titan
2009-12-30 , 18:10
Posts: 946 | Thanked: 1,650 times | Joined on Oct 2009 @ Germany
#107
Originally Posted by bastler View Post
I see your point, but that means it would be a marketing decision, from a technical viewpoint it's possible, right?
absolutely! If I only the camera app had a manual setting for the output directory...
I knew I'd missed something. So basically (to get back to the practical examples) if I for me personally decided that I don't need an internal vfat partition and deleted it in favour of a large ext3 home partition I could no longer access it via USB cable?
correct. only unmounted partitions or loop files can be exported via USB.
 
titan is offline titan
2009-12-30 , 18:13
Posts: 946 | Thanked: 1,650 times | Joined on Oct 2009 @ Germany
#108
Originally Posted by soeiro View Post
Has anybody tried the feasibility of leaving only the basic rootfs in place and mounting everything else in the MMC (/usr, /opt, /home, etc)?
moving /usr is dangerous as most essential apps are stored in /usr.
I doubt, however, that root fs is much faster than eMMC.
 
titan is offline titan
2009-12-30 , 18:25
Posts: 946 | Thanked: 1,650 times | Joined on Oct 2009 @ Germany
#109
Originally Posted by soeiro View Post
Would this scenario allow a simpler firmware update usage, assuming it will overwrite rootfs, but during the next boot, AUFS would keep placing new stuf in /mmc?
I think that ideally root should be reserved only for static, essential stuff
(booting, GUI, I/O, standard apps) and changed only by Nokia updates or
reflashing. Everything which is likely to change (/etc, /var) should be copied
to home and bind-mounted if home is available (maybe have a "r" bootkey to avoid mounting home if you screwed your configuration?).
maybe we should have a separate /var/lib/dpkg for the Nokia packages?
This way we would avoid AUFS or UnionFs solution.
What do you think?

It seems to be possible for a new firmware upgrade to restructure both the rootfs and the MMC in order stick to standard Unix Layout. Of course, the flasher could backup user files before and place them on the correct places afterwards.
I don't think flasher should be responsible for that. it's closed source anyway...
 
ruskie is offline ruskie
2009-12-30 , 18:55
Posts: 543 | Thanked: 181 times | Joined on Aug 2009 @ Universe,LocalCluster.MilkyWay.Sol.Earth.Europe.Slovenia.Ljubljana
#110
Originally Posted by titan View Post
moving /usr is dangerous as most essential apps are stored in /usr.
I doubt, however, that root fs is much faster than eMMC.
Not really.

I have /usr mounted as eMMC. - See a few pages back on how I have it configured.

And yes there is a noticable delay with /usr on eMMC.

I do mount /usr early.. just after modules are loaded iirc. It's all in the post.
 
Reply
Page 11 of 33 « First 910 11 121321 Last »

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 14:13.

Contact Us - Home - Archive - Top