[arch-releng] [archiso] saying good-bye to union-fs-method?
Hi * With 2.6.39 there is no aufs2 support, at least for a long time[#1]. * I think that back in time with unionfs is not desirable, needs a complete kernel patch. * union-fs-fuse does not work good. What about using the method like in Fedora? (basically a device-mapper with a snapshot in tmpfs). This change from file-to-file level to block-to-block logic. I can do some research in my free time if there any interest on this. I am open to all sugestions. Thanks. [#1] http://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg03315.html -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am 31.05.2011 03:21, schrieb Gerardo Exequiel Pozzi:
Hi
* With 2.6.39 there is no aufs2 support, at least for a long time[#1]. * I think that back in time with unionfs is not desirable, needs a complete kernel patch. * union-fs-fuse does not work good.
What about using the method like in Fedora? (basically a device-mapper with a snapshot in tmpfs).
This change from file-to-file level to block-to-block logic.
This actually sounds pretty cool. However, I don't understand how it works: The squashfs file system is a read-only one, how can we put that into a block-level snapshot?
On 05/31/2011 07:54 AM, Thomas Bächler wrote:
Am 31.05.2011 03:21, schrieb Gerardo Exequiel Pozzi:
Hi
* With 2.6.39 there is no aufs2 support, at least for a long time[#1]. * I think that back in time with unionfs is not desirable, needs a complete kernel patch. * union-fs-fuse does not work good.
What about using the method like in Fedora? (basically a device-mapper with a snapshot in tmpfs).
This change from file-to-file level to block-to-block logic. This actually sounds pretty cool. However, I don't understand how it works: The squashfs file system is a read-only one, how can we put that into a block-level snapshot?
Yes, but there are at least one downside: since is not an union-fs, there is no concept of layers. We are currently using "overlay" thats overlap some files on the layer "root-image". With the others layers like "core-pkgs" and "lib-modules", there are no overlap and can be replaced by a simple mount point. Of course this "overlay" can be merged at build time on "root-image". About your question: The squasfs image contains only one file... an image of and 4 GiB ext4. There is another small squasfs image with another one file inside that is a "lvm snapshot". So dm device is made via these images loopback mounted... The code is here http://git.kernel.org/?p=boot/dracut/dracut.git;a=tree;f=modules.d/90dmsquas... -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am 31.05.2011 17:08, schrieb Gerardo Exequiel Pozzi:
On 05/31/2011 07:54 AM, Thomas Bächler wrote:
Am 31.05.2011 03:21, schrieb Gerardo Exequiel Pozzi:
Hi
* With 2.6.39 there is no aufs2 support, at least for a long time[#1]. * I think that back in time with unionfs is not desirable, needs a complete kernel patch. * union-fs-fuse does not work good.
What about using the method like in Fedora? (basically a device-mapper with a snapshot in tmpfs).
This change from file-to-file level to block-to-block logic. This actually sounds pretty cool. However, I don't understand how it works: The squashfs file system is a read-only one, how can we put that into a block-level snapshot?
Yes, but there are at least one downside: since is not an union-fs, there is no concept of layers. We are currently using "overlay" thats overlap some files on the layer "root-image".
This is not problematic.
About your question: The squasfs image contains only one file... an image of and 4 GiB ext4. There is another small squasfs image with another one file inside that is a "lvm snapshot". So dm device is made via these images loopback mounted...
Some of this doesn't make sense to me right now (especially the second squashfs image). However: With an ext4 loopback inside the squashfs image you loose one squashfs feature: metadata compression. I don't know how bad that will be though. I'll summarize what I think is going on: You mount the squashfs (loop0), and set up the ext4 image inside as loop1. You then create a large sparse file on tmpfs and set it up as loop2. Then, you create a snapshot device (can't use LVM here, can one use the device-mapper snapshot target directly?) with loop1 as read-only and loop2 as read-write layer. You then mount that device. Sounds doable, but not optimal (a VFS-based solution would be way cooler).
Am 31.05.2011 18:07, schrieb Thomas Bächler:
This change from file-to-file level to block-to-block logic. This actually sounds pretty cool. However, I don't understand how it works: The squashfs file system is a read-only one, how can we put that into a block-level snapshot?
Yes, but there are at least one downside: since is not an union-fs, there is no concept of layers. We are currently using "overlay" thats overlap some files on the layer "root-image".
This is not problematic.
About your question: The squasfs image contains only one file... an image of and 4 GiB ext4. There is another small squasfs image with another one file inside that is a "lvm snapshot". So dm device is made via these images loopback mounted...
Some of this doesn't make sense to me right now (especially the second squashfs image).
However: With an ext4 loopback inside the squashfs image you loose one squashfs feature: metadata compression. I don't know how bad that will be though.
I'll summarize what I think is going on: You mount the squashfs (loop0), and set up the ext4 image inside as loop1. You then create a large sparse file on tmpfs and set it up as loop2. Then, you create a snapshot device (can't use LVM here, can one use the device-mapper snapshot target directly?) with loop1 as read-only and loop2 as read-write layer. You then mount that device. Sounds doable, but not optimal (a VFS-based solution would be way cooler).
Okay, this is how a short test works: # dd if=/dev/zero of=ro.img bs=1 seek=100M count=1 # dd if=/dev/zero of=cow.img bs=1 seek=100M count=1 # mkfs.ext4 -F ro.img # losetup /dev/loop0 ro.img # losetup /dev/loop1 cow.img # mount /dev/loop0 /some/path (put some stuff into /some/path) # umount /some/path # echo "0 $(blockdev --getsize /dev/loop0) snapshot /dev/loop0 /dev/loop1 N 8" | dmsetup create snapshottest (8 ist the "chunk size" here, which is now 8 sectors. no idea what a good value might be) # mount /dev/mapper/snapshottest /mnt/other (do whatever you want in /mnt/other) # umount /mnt/other # dmsetup remove snapshottest # losetup -d /dev/loop0 # losetup -d /dev/loop1 In archiso, the file 'ro.img' would be inside squashfs, while 'cow.img' would be in a tmpfs. Noteagain that we might get worse compression with a single file in squashfs, compared to a real read-only squashfs - we could consider making part of the file system entirely read-only, not sure. This seems fairly easy to implement on the mounting side. Creation of the ext4 should be pretty straightforward, too.
On 05/31/2011 03:19 PM, Thomas Bächler wrote:
Am 31.05.2011 18:07, schrieb Thomas Bächler:
This change from file-to-file level to block-to-block logic. This actually sounds pretty cool. However, I don't understand how it works: The squashfs file system is a read-only one, how can we put that into a block-level snapshot?
Yes, but there are at least one downside: since is not an union-fs, there is no concept of layers. We are currently using "overlay" thats overlap some files on the layer "root-image". This is not problematic. OK.
Maybe if we want to maintain an original root-image we can do this using a snapshot with all changes. This make the build process a bit more complex.
About your question: The squasfs image contains only one file... an image of and 4 GiB ext4. There is another small squasfs image with another one file inside that is a "lvm snapshot". So dm device is made via these images loopback mounted... Some of this doesn't make sense to me right now (especially the second squashfs image).
However: With an ext4 loopback inside the squashfs image you loose one squashfs feature: metadata compression. I don't know how bad that will be though. Yes. But the difference is small.
# du -sh /tmp/archbase* 398M /tmp/archbase (1) 456M /tmp/archbase.ext4 (2) 148M /tmp/archbase.ext4.sfs (3) 145M /tmp/archbase.sfs (4) (1) "base" group with all deps. (2) 1GiB file (sparse) then copy all files on it (avoid unused space usage of file deletions, in other words: trash) (3) squashfs of one file (/tmp/archbase.ext4) (4) squashfs of many files (/tmp/archbase/)
I'll summarize what I think is going on: You mount the squashfs (loop0), and set up the ext4 image inside as loop1. You then create a large sparse file on tmpfs and set it up as loop2. Then, you create a snapshot device (can't use LVM here, can one use the device-mapper snapshot target directly?) with loop1 as read-only and loop2 as read-write layer. You then mount that device. Sounds doable, but not optimal (a VFS-based solution would be way cooler). Okay, this is how a short test works:
# dd if=/dev/zero of=ro.img bs=1 seek=100M count=1 # dd if=/dev/zero of=cow.img bs=1 seek=100M count=1 # mkfs.ext4 -F ro.img # losetup /dev/loop0 ro.img # losetup /dev/loop1 cow.img # mount /dev/loop0 /some/path (put some stuff into /some/path) # umount /some/path # echo "0 $(blockdev --getsize /dev/loop0) snapshot /dev/loop0 /dev/loop1 N 8" | dmsetup create snapshottest (8 ist the "chunk size" here, which is now 8 sectors. no idea what a good value might be) I think that 8 is the optimal 8*512 = 4096, that is the size of block of ext4 image and the block size of loopback device. # mount /dev/mapper/snapshottest /mnt/other (do whatever you want in /mnt/other) # umount /mnt/other # dmsetup remove snapshottest # losetup -d /dev/loop0 # losetup -d /dev/loop1
In archiso, the file 'ro.img' would be inside squashfs, while 'cow.img' would be in a tmpfs. Noteagain that we might get worse compression with a single file in squashfs, compared to a real read-only squashfs - we could consider making part of the file system entirely read-only, not sure. Again not a big issue here, in terms of size. This seems fairly easy to implement on the mounting side. Creation of the ext4 should be pretty straightforward, too. There are others downside, only notable when you work inside the "live medium": Create/modify a file and delete it, the space is not released at "physical level" (on tmpfs), like now where new/modify files are written directly on tmpfs.
So go ahead? What do you think: support of both modes if aufs come again(*) or change all code and simply keep this mode (if all people are happy) Thanks for your feedback. (*) or something official union layer in Linux 100.0 :P. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On 05/31/2011 09:43 PM, Gerardo Exequiel Pozzi wrote:
On 05/31/2011 03:19 PM, Thomas Bächler wrote:
Am 31.05.2011 18:07, schrieb Thomas Bächler:
This change from file-to-file level to block-to-block logic. This actually sounds pretty cool. However, I don't understand how it works: The squashfs file system is a read-only one, how can we put that into a block-level snapshot?
Yes, but there are at least one downside: since is not an union-fs, there is no concept of layers. We are currently using "overlay" thats overlap some files on the layer "root-image". This is not problematic. OK.
Maybe if we want to maintain an original root-image we can do this using a snapshot with all changes. This make the build process a bit more complex.
About your question: The squasfs image contains only one file... an image of and 4 GiB ext4. There is another small squasfs image with another one file inside that is a "lvm snapshot". So dm device is made via these images loopback mounted... Some of this doesn't make sense to me right now (especially the second squashfs image).
However: With an ext4 loopback inside the squashfs image you loose one squashfs feature: metadata compression. I don't know how bad that will be though. Yes. But the difference is small.
# du -sh /tmp/archbase* 398M /tmp/archbase (1) 456M /tmp/archbase.ext4 (2) 148M /tmp/archbase.ext4.sfs (3) 145M /tmp/archbase.sfs (4)
(1) "base" group with all deps. (2) 1GiB file (sparse) then copy all files on it (avoid unused space usage of file deletions, in other words: trash) (3) squashfs of one file (/tmp/archbase.ext4) (4) squashfs of many files (/tmp/archbase/)
I'll summarize what I think is going on: You mount the squashfs (loop0), and set up the ext4 image inside as loop1. You then create a large sparse file on tmpfs and set it up as loop2. Then, you create a snapshot device (can't use LVM here, can one use the device-mapper snapshot target directly?) with loop1 as read-only and loop2 as read-write layer. You then mount that device. Sounds doable, but not optimal (a VFS-based solution would be way cooler). Okay, this is how a short test works:
# dd if=/dev/zero of=ro.img bs=1 seek=100M count=1 # dd if=/dev/zero of=cow.img bs=1 seek=100M count=1 # mkfs.ext4 -F ro.img # losetup /dev/loop0 ro.img # losetup /dev/loop1 cow.img # mount /dev/loop0 /some/path (put some stuff into /some/path) # umount /some/path # echo "0 $(blockdev --getsize /dev/loop0) snapshot /dev/loop0 /dev/loop1 N 8" | dmsetup create snapshottest (8 ist the "chunk size" here, which is now 8 sectors. no idea what a good value might be) I think that 8 is the optimal 8*512 = 4096, that is the size of block of ext4 image and the block size of loopback device. # mount /dev/mapper/snapshottest /mnt/other (do whatever you want in /mnt/other) # umount /mnt/other # dmsetup remove snapshottest # losetup -d /dev/loop0 # losetup -d /dev/loop1
In archiso, the file 'ro.img' would be inside squashfs, while 'cow.img' would be in a tmpfs. Noteagain that we might get worse compression with a single file in squashfs, compared to a real read-only squashfs - we could consider making part of the file system entirely read-only, not sure. Again not a big issue here, in terms of size. This seems fairly easy to implement on the mounting side. Creation of the ext4 should be pretty straightforward, too. There are others downside, only notable when you work inside the "live medium": Create/modify a file and delete it, the space is not released at "physical level" (on tmpfs), like now where new/modify files are written directly on tmpfs.
So go ahead?
What do you think: support of both modes if aufs come again(*) or change all code and simply keep this mode (if all people are happy)
Thanks for your feedback.
(*) or something official union layer in Linux 100.0 :P.
before I start, I am thinking in some others areas: * core-iso: I think we need (If I don't remember bad) write access to /src (where core pkgs is mounted), implies we need to mount core-pkgs indirectly via dm-dev w/snapshot like root-img. * dual images (depending on profile [-T] ) ** core-any-pkgs.sqfs, will dissapear (no more union-fs trick), yes this can be done via symlinks... (about 16MB saved) ** usr-share.sqfs, should be done in the same way that root-image, otherwise update is not posible. ** lib-modules.sqfs, idem usr-share and root-image. * net-iso, no issues. mkarchiso can take a optional parameter when creating the "fs.img" thats add some percent to be "free space". """ USED=$(du -sh directory) .... dd ..... of="fs.img" seek=$((USED*PERCENT_FREE)) """ -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am 01.06.2011 04:59, schrieb Gerardo Exequiel Pozzi:
Yes, but there are at least one downside: since is not an union-fs, there is no concept of layers. We are currently using "overlay" thats overlap some files on the layer "root-image". This is not problematic. OK.
Maybe if we want to maintain an original root-image we can do this using a snapshot with all changes. This make the build process a bit more complex.
I don't think we should. Just copy the overlay over the root image and get on with it.
However: With an ext4 loopback inside the squashfs image you loose one squashfs feature: metadata compression. I don't know how bad that will be though. Yes. But the difference is small.
# du -sh /tmp/archbase* 398M /tmp/archbase (1) 456M /tmp/archbase.ext4 (2) 148M /tmp/archbase.ext4.sfs (3) 145M /tmp/archbase.sfs (4)
That seems fine.
# echo "0 $(blockdev --getsize /dev/loop0) snapshot /dev/loop0 /dev/loop1 N 8" | dmsetup create snapshottest (8 ist the "chunk size" here, which is now 8 sectors. no idea what a good value might be) I think that 8 is the optimal 8*512 = 4096, that is the size of block of ext4 image and the block size of loopback device.
4KB was my thought as well. Let's do 8 then.
This seems fairly easy to implement on the mounting side. Creation of the ext4 should be pretty straightforward, too. There are others downside, only notable when you work inside the "live medium": Create/modify a file and delete it, the space is not released at "physical level" (on tmpfs), like now where new/modify files are written directly on tmpfs.
The downsides of aufs2 or another unionfs implementation are worse: They are all unstable and unmaintained.
So go ahead?
Yes, sounds nice.
What do you think: support of both modes if aufs come again(*) or change all code and simply keep this mode (if all people are happy)
Depends on how difficult this will be. I think tpowa will be happy to never have to maintain aufs again. Our image would work with a kernel that is completely vanilla, this makes me happy as well.
Thanks for your feedback.
(*) or something official union layer in Linux 100.0 :P.
I was still hoping for union-mounts, but they are not being developed anymore.
before I start, I am thinking in some others areas:
* core-iso: I think we need (If I don't remember bad) write access to /src (where core pkgs is mounted), implies we need to mount core-pkgs indirectly via dm-dev w/snapshot like root-img.
Why would we need that? I don't like the idea of doing this snapshot stuff with more than one device. We should just mount the packages as a mount point, no hacks.
* dual images (depending on profile [-T] ) ** core-any-pkgs.sqfs, will dissapear (no more union-fs trick), yes this can be done via symlinks... (about 16MB saved)
Symlinks it is - do it like we do on the mirrors.
** usr-share.sqfs, should be done in the same way that root-image, otherwise update is not posible. ** lib-modules.sqfs, idem usr-share and root-image. * net-iso, no issues.
So, we'll need 3 of those snapshot systems for the split ISO? I don't like it, but if we can really save space, I suppose it's a good thing. We could also have one big ext4 with everything inside it, in subdirectories, then bind-mount. This is probably easier. For less overhead, we should also create the ext4 without journal. We don't need it as everything is in RAM anyway.
mkarchiso can take a optional parameter when creating the "fs.img" thats add some percent to be "free space". """ USED=$(du -sh directory) .... dd ..... of="fs.img" seek=$((USED*PERCENT_FREE)) """
You can also vary the size of the snapshot file (it can be smaller than the fs).
On 06/01/2011 04:26 AM, Thomas Bächler wrote:
So go ahead? Yes, sounds nice. Status: mkarchiso 90% done archiso (hook): 30% done archiso2dual: 0%
Makefile, I will propose change to shell script, a the Makefile in this context is more a hack... -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am 07.06.2011 16:24, schrieb Gerardo Exequiel Pozzi:
On 06/01/2011 04:26 AM, Thomas Bächler wrote:
So go ahead? Yes, sounds nice. Status: mkarchiso 90% done archiso (hook): 30% done archiso2dual: 0%
I say we finish mkarchiso and the hook first (I can help with the hook I think) and disable the dual images until we get to fix archiso2dual. Once we move kernel26 to core, we either have no ISOs, or the non-dual ISOs. About changing from Makefile to script or whatever: Refactor it the way you think it works best. I don't think anyone depends on the Makefiles here.
On 06/07/2011 11:58 AM, Thomas Bächler wrote:
On 06/01/2011 04:26 AM, Thomas Bächler wrote:
So go ahead? Yes, sounds nice. Status: mkarchiso 90% done archiso (hook): 30% done archiso2dual: 0% I say we finish mkarchiso and the hook first (I can help with the hook I
Am 07.06.2011 16:24, schrieb Gerardo Exequiel Pozzi: think) and disable the dual images until we get to fix archiso2dual.
Once we move kernel26 to core, we either have no ISOs, or the non-dual ISOs.
About changing from Makefile to script or whatever: Refactor it the way you think it works best. I don't think anyone depends on the Makefiles here.
First: Sorry: this is just a BIG patch, no trivial commits TODO: messages, comments, documentation, archiso2dual, syslinux-iso, other changes. Short description (Highlights): * good-bye aufs2, welcome dm-snapshot. * syslinux-iso is not touched, I just done a simple profile "baseline" to test * mkarchiso use "set -e -u" * isomounts renamed aitab (new syntax) Field to select squashfs compression (xz, lzo, gzip) or "none" (no squashfs is used just raw image) Field to select filesystem type of "raw" image.fs (ext2, ext3, ext4, xfs) Field to set free space (in %) or total size of "raw" image. Fields architecture supports "any". * New command: "prepare", builds all images (used before iso) * *.sqfs -> *.sfs (more standard) * single images looks like dual images (directory scheme) build process (no verbose): http://pastebin.com/8EGRtzQi how live-enviroment look (loop devices, mounts): http://pastebin.com/qt63QnQw branch dm-snapshot: https://github.com/djgera/archiso/tree/dm-snapshot Tree: ├── arch │ ├── boot │ │ ├── aitab │ │ └── i686 │ │ ├── archiso.img │ │ └── vmlinuz26 │ └── i686 │ └── root-image.fs.sfs └── syslinux ├── boot.cat ├── isolinux.bin ├── menu.c32 └── syslinux.cfg -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On 06/08/2011 02:52 AM, Gerardo Exequiel Pozzi wrote:
On 06/07/2011 11:58 AM, Thomas Bächler wrote:
On 06/01/2011 04:26 AM, Thomas Bächler wrote:
So go ahead? Yes, sounds nice. Status: mkarchiso 90% done archiso (hook): 30% done archiso2dual: 0% I say we finish mkarchiso and the hook first (I can help with the hook I
Am 07.06.2011 16:24, schrieb Gerardo Exequiel Pozzi: think) and disable the dual images until we get to fix archiso2dual.
Once we move kernel26 to core, we either have no ISOs, or the non-dual ISOs.
About changing from Makefile to script or whatever: Refactor it the way you think it works best. I don't think anyone depends on the Makefiles here.
First: Sorry: this is just a BIG patch, no trivial commits
TODO: messages, comments, documentation, archiso2dual, syslinux-iso, other changes.
Short description (Highlights):
* good-bye aufs2, welcome dm-snapshot. * syslinux-iso is not touched, I just done a simple profile "baseline" to test * mkarchiso use "set -e -u" * isomounts renamed aitab (new syntax) Field to select squashfs compression (xz, lzo, gzip) or "none" (no squashfs is used just raw image) Field to select filesystem type of "raw" image.fs (ext2, ext3, ext4, xfs) Field to set free space (in %) or total size of "raw" image. Fields architecture supports "any". * New command: "prepare", builds all images (used before iso) * *.sqfs -> *.sfs (more standard) * single images looks like dual images (directory scheme)
build process (no verbose): http://pastebin.com/8EGRtzQi how live-enviroment look (loop devices, mounts): http://pastebin.com/qt63QnQw branch dm-snapshot: https://github.com/djgera/archiso/tree/dm-snapshot
Tree:
├── arch │ ├── boot │ │ ├── aitab │ │ └── i686 │ │ ├── archiso.img │ │ └── vmlinuz26 │ └── i686 │ └── root-image.fs.sfs └── syslinux ├── boot.cat ├── isolinux.bin ├── menu.c32 └── syslinux.cfg
I pushed a "releng" profile, for now, only make net.iso. I will work this weekend for core.iso. In the build process, I split out usr/share and /lib/modules to make more friendly "dual-iso", what do you think? To boot use: loop.max_loop=16 (for now). I will make archiso hook create dev loop nodes on demand. [root@archiso ~]# df -h Filesystem Size Used Avail Use% Mounted on udev 10M 0 10M 0% /dev run 10M 120K 9.9M 2% /run /dev/mapper/root-image 624M 288M 336M 47% / /dev/mapper/lib-modules 49M 38M 12M 77% /lib/modules /dev/mapper/usr-share 434M 169M 266M 39% /usr/share /dev/disk/by-label/ARCH_201106 193M 193M 0 100% /bootmnt shm 61M 0 61M 0% /dev/shm [root@archiso ~]# losetup -a /dev/loop0: [0b00]:330 (/bootmnt/arch/i686/root-image.fs.sfs) /dev/loop1: [0700]:2 (/sfs/root-image/root-image.fs) /dev/loop2: [000f]:5636 (/cowspace/root-image) /dev/loop3: [0b00]:329 (/bootmnt/arch/i686/lib-modules.fs.sfs) /dev/loop4: [0703]:2 (/sfs/lib-modules/lib-modules.fs) /dev/loop5: [000f]:6003 (/cowspace/lib-modules) /dev/loop6: [0b00]:328 (/bootmnt/arch/any/usr-share.fs.sfs) /dev/loop7: [0706]:2 (/sfs/usr-share/usr-share.fs) /dev/loop8: [000f]:6048 (/cowspace/usr-share) /bootmnt/ ├── arch │ ├── any │ │ └── usr-share.fs.sfs │ ├── boot │ │ ├── aitab │ │ ├── i686 │ │ │ ├── archiso.img │ │ │ └── vmlinuz26 │ │ ├── memtest │ │ └── memtest.COPYING │ └── i686 │ ├── lib-modules.fs.sfs │ └── root-image.fs.sfs -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On 06/11/2011 04:14 AM, Gerardo Exequiel Pozzi wrote:
On 06/08/2011 02:52 AM, Gerardo Exequiel Pozzi wrote:
On 06/07/2011 11:58 AM, Thomas Bächler wrote:
On 06/01/2011 04:26 AM, Thomas Bächler wrote:
> So go ahead? Yes, sounds nice. Status: mkarchiso 90% done archiso (hook): 30% done archiso2dual: 0% I say we finish mkarchiso and the hook first (I can help with the hook I
Am 07.06.2011 16:24, schrieb Gerardo Exequiel Pozzi: think) and disable the dual images until we get to fix archiso2dual.
Once we move kernel26 to core, we either have no ISOs, or the non-dual ISOs.
About changing from Makefile to script or whatever: Refactor it the way you think it works best. I don't think anyone depends on the Makefiles here.
First: Sorry: this is just a BIG patch, no trivial commits
TODO: messages, comments, documentation, archiso2dual, syslinux-iso, other changes.
Short description (Highlights):
* good-bye aufs2, welcome dm-snapshot. * syslinux-iso is not touched, I just done a simple profile "baseline" to test * mkarchiso use "set -e -u" * isomounts renamed aitab (new syntax) Field to select squashfs compression (xz, lzo, gzip) or "none" (no squashfs is used just raw image) Field to select filesystem type of "raw" image.fs (ext2, ext3, ext4, xfs) Field to set free space (in %) or total size of "raw" image. Fields architecture supports "any". * New command: "prepare", builds all images (used before iso) * *.sqfs -> *.sfs (more standard) * single images looks like dual images (directory scheme)
build process (no verbose): http://pastebin.com/8EGRtzQi how live-enviroment look (loop devices, mounts): http://pastebin.com/qt63QnQw branch dm-snapshot: https://github.com/djgera/archiso/tree/dm-snapshot
Tree:
├── arch │ ├── boot │ │ ├── aitab │ │ └── i686 │ │ ├── archiso.img │ │ └── vmlinuz26 │ └── i686 │ └── root-image.fs.sfs └── syslinux ├── boot.cat ├── isolinux.bin ├── menu.c32 └── syslinux.cfg
I pushed a "releng" profile, for now, only make net.iso. I will work this weekend for core.iso.
In the build process, I split out usr/share and /lib/modules to make more friendly "dual-iso", what do you think?
To boot use: loop.max_loop=16 (for now). I will make archiso hook create dev loop nodes on demand.
[root@archiso ~]# df -h Filesystem Size Used Avail Use% Mounted on udev 10M 0 10M 0% /dev run 10M 120K 9.9M 2% /run /dev/mapper/root-image 624M 288M 336M 47% / /dev/mapper/lib-modules 49M 38M 12M 77% /lib/modules /dev/mapper/usr-share 434M 169M 266M 39% /usr/share /dev/disk/by-label/ARCH_201106 193M 193M 0 100% /bootmnt shm 61M 0 61M 0% /dev/shm [root@archiso ~]# losetup -a /dev/loop0: [0b00]:330 (/bootmnt/arch/i686/root-image.fs.sfs) /dev/loop1: [0700]:2 (/sfs/root-image/root-image.fs) /dev/loop2: [000f]:5636 (/cowspace/root-image) /dev/loop3: [0b00]:329 (/bootmnt/arch/i686/lib-modules.fs.sfs) /dev/loop4: [0703]:2 (/sfs/lib-modules/lib-modules.fs) /dev/loop5: [000f]:6003 (/cowspace/lib-modules) /dev/loop6: [0b00]:328 (/bootmnt/arch/any/usr-share.fs.sfs) /dev/loop7: [0706]:2 (/sfs/usr-share/usr-share.fs) /dev/loop8: [000f]:6048 (/cowspace/usr-share)
/bootmnt/ ├── arch │ ├── any │ │ └── usr-share.fs.sfs │ ├── boot │ │ ├── aitab │ │ ├── i686 │ │ │ ├── archiso.img │ │ │ └── vmlinuz26 │ │ ├── memtest │ │ └── memtest.COPYING │ └── i686 │ ├── lib-modules.fs.sfs │ └── root-image.fs.sfs
netinstal+core is done. TODO dual, but now is much more easy ;) archlinux-2011.06.13-core-i686.iso ├── arch │ ├── aitab │ ├── any │ │ ├── core-any-pkgs.sfs │ │ └── usr-share.fs.sfs │ ├── boot │ │ ├── i686 │ │ │ ├── archiso.img │ │ │ └── vmlinuz26 │ │ ├── memtest │ │ └── memtest.COPYING │ └── i686 │ ├── core-pkgs.sfs │ ├── lib-modules.fs.sfs │ └── root-image.fs.sfs I am going to sleep mode now! -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
participants (2)
-
Gerardo Exequiel Pozzi
-
Thomas Bächler