Questions about archiso

firecat53 · 2012-01-12 17:27:47

1. I think I have a conceptual issue -- I can use archiso to successfully create a live cd/usb, but I don't understand why there are 2 layers of chroot involved. The wiki tells me to create the archlive chroot and then build.sh creates another one in the work/ directory. How come you can't just run build.sh from your regular install? Hope that makes sense...

2. I was a bit confused also when the build.sh process started and it couldn't find the multilib packages in my packages list. I ended up editing pacman.conf in /mnt/extra/archlive/tmp/releng/work/x86_64/root-image/etc to allow the multilib repository. Is there another pacman.conf someplace that contains modifications for build.sh to use when creating the work/x86_64 chroot?

3. If I've got a bunch of AUR and ABS packages to install, where should I put them? The wiki mentions creating a repo for them, which is easy, but I'm not clear as to where (which chroot) it should be created. I normally keep a directory of these packages in ~/.local/var/local_packages but I'm not sure the best way to point the work/x86_64/root-image chroot to that directory (other than creating an empty directory in work/x86_64/root-image and then mounting my local directory to that and editing the root-image pacman.conf after it gets initially created....that seems awful hackish so I'm wondering if I'm missing something obvious)

Thanks!
Scott

Edit: Grrr. Discovered the hard way that with the normal pacman cache mounted in both chroots that "./build.sh clean single" deletes all of the packages in the cache, requiring them all to re-download.

Last edited by firecat53 (2012-01-12 18:24:47)

djgera · 2012-01-12 19:57:30

firecat53 wrote:

1. I think I have a conceptual issue -- I can use archiso to successfully create a live cd/usb, but I don't understand why there are 2 layers of chroot involved. The wiki tells me to create the archlive chroot and then build.sh creates another one in the work/ directory. How come you can't just run build.sh from your regular install? Hope that makes sense...

First chroot enviroment is _optional_ when you are building an image that is equal to your architecture. If you are building a 32-bit image on 64-bit host, first chroot enviroment is _required_. In any case, working in chroot ensures a clear enviroment to work.

firecat53 wrote:

2. I was a bit confused also when the build.sh process started and it couldn't find the multilib packages in my packages list. I ended up editing pacman.conf in /mnt/extra/archlive/tmp/releng/work/x86_64/root-image/etc to allow the multilib repository. Is there another pacman.conf someplace that contains modifications for build.sh to use when creating the work/x86_64 chroot?

Edit pacman.conf inside the chroot made by you with mkarchroot then enable multilib.

firecat53 wrote:

3. If I've got a bunch of AUR and ABS packages to install, where should I put them? The wiki mentions creating a repo for them, which is easy, but I'm not clear as to where (which chroot) it should be created. I normally keep a directory of these packages in ~/.local/var/local_packages but I'm not sure the best way to point the work/x86_64/root-image chroot to that directory (other than creating an empty directory in work/x86_64/root-image and then mounting my local directory to that and editing the root-image pacman.conf after it gets initially created....that seems awful hackish so I'm wondering if I'm missing something obvious)

Bind mount your custom repo, inside some place in chroot, then edit pacman.conf to reflect this repo/place.

firecat53 wrote:

Thanks!
Scott
Edit: Grrr. Discovered the hard way that with the normal pacman cache mounted in both chroots that "./build.sh clean single" deletes all of the packages in the cache, requiring them all to re-download.

mkarchroot bind mount your pacman cache inside the chroot, clean_single only deletes things made by build.sh only (work and out). There is no relation with pacman cache. (at least in normal procedure, if you made things inside root-image, and save important things here, is a bad workflow, or if you interrupt (^C) build.sh, then some mounts are still present in root-image)

firecat53 · 2012-01-13 23:26:49

Ok, I'm getting somewhere now...thanks for the help!

Other issues found:
1. I've added some package groups (multilib-devel, xorg-drivers, etc) to the packages list and it seems to be skipping over all the members in the groups.

2. How can I resolve the dependency errors about installing gcc-libs-multilib and also replacing cronie with dcron?

3. I added kernel26-lts, vi, nano and cronie to the core.exclude.x86_64 file, but it still installs those packages. How to avoid that?

Here is the ouput from from running ./build.sh -v build single core into a clean work directory. Any other suggestions based on that?

Thanks!
Scott

djgera · 2012-01-14 00:09:23

This is outside archiso. Anyway...

1) Ensure proper installing order. This is, not list all packages in one _big_ step. Split them in logic parts then install in order.
2) Like in (1), sometimes you need to not use package groups, but select only some from these groups to avoid conflics. There is no way in pacman to do some things like ignore one package, and install another (provides) in one step.
3) core.exclude.* is only for "core-repo.sfs", for core-install purpose. (releng profile)

I suggest to write your own build.sh, take as base "baseline" profile. Do not use "releng", that is mainly for official images. Just follow the logic in how to use mkarchiso. (install base packages, customize root-image, make initramfs, make squashfs images, and optionally the do an iso).

djgera · 2012-01-14 00:15:09

be the way, to take an idea with an example of what I am talking , see my customize profile https://github.com/djgera/pandereta/ (needs update I did not touch in months, since I made lots of changes in archiso in these months)

firecat53 · 2012-01-18 17:40:42

Thanks for the help! I ended up modifying /usr/bin/mkarchiso to remove the '--noconfirm' flag from the pacman statement for now. That allows all the groups to be installed with some user input instead of putting all the individual group member packages into the 'packages' file.

Couple of more questions --
1. I'm using the boot parameter cow_label=DATA to put the persistent data on a separate partition. Can I use the same partition as the live USB? Right now I have /dev/sdb1 is ext4 DATA, and /dev/sdb2 is ext4 ARCH (with the arch/ and isolinux/ directories)...can I assign cow_label=ARCH?

2. If I make a change in a $HOME configuration file (like .xinitrc) that is copied from /etc/skel on boot, it appears that this overwrites any changes stored in the cow snapshot. Is there a way to make those persistent changes apply AFTER the /etc/skel files are copied?

Hope that makes sense!

Thanks,
Scott

djgera · 2012-01-18 23:10:15

Great

1) Yes, archisolabel == cow_label
2) /etc/skel is only copied on build step with useradd for "arch" user in "releng" profile. Nothing in archiso (current) does this task (at least since 2011-07).

Arch Linux

#1 2012-01-12 17:27:47

Questions about archiso

#2 2012-01-12 19:57:30

Re: Questions about archiso

#3 2012-01-13 23:26:49

Re: Questions about archiso

#4 2012-01-14 00:09:23

Re: Questions about archiso

#5 2012-01-14 00:15:09

Re: Questions about archiso

#6 2012-01-18 17:40:42

Re: Questions about archiso

#7 2012-01-18 23:10:15

Re: Questions about archiso

Board footer