Repartition the internal drive - Page 11 - maemo.org

Active Topics

Porting apps to Leste (29)
to Maemo 7 / Leste by Arno_11 - 5 days, 10 hrs ago
Install Fonts in N900 (68)
to Maemo 5 / Fremantle by teroyk - 6 days, 13 hrs ago
more...

Page 11 of 33

Thread Tools

titan	2009-12-30 , 12:03
Posts: 946 \| Thanked: 1,650 times \| Joined on Oct 2009 @ Germany	#101

Originally Posted by bastler

- 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?

Quote & Reply |

The Following 2 Users Say Thank You to titan For This Useful Post:
blubbi, iKneaDough

soeiro	2009-12-30 , 13:31
Posts: 292 \| Thanked: 131 times \| Joined on Dec 2009	#102

Originally Posted by titan

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.

Quote & Reply |

	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.

Quote & Reply |

The Following User Says Thank You to javispedro For This Useful Post:
titan

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

Quote & Reply |

	bastler	2009-12-30 , 14:26
	Posts: 31 \| Thanked: 11 times \| Joined on Dec 2009	#105

Originally Posted by titan

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

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

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!

Quote & Reply |

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

Quote & Reply |

titan	2009-12-30 , 18:10
Posts: 946 \| Thanked: 1,650 times \| Joined on Oct 2009 @ Germany	#107

Originally Posted by bastler

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.

Quote & Reply |

titan	2009-12-30 , 18:13
Posts: 946 \| Thanked: 1,650 times \| Joined on Oct 2009 @ Germany	#108

Originally Posted by soeiro

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.

Quote & Reply |

titan	2009-12-30 , 18:25
Posts: 946 \| Thanked: 1,650 times \| Joined on Oct 2009 @ Germany	#109

Originally Posted by soeiro

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...

Quote & Reply |

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

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.