[arch-dev-public] mkinitcpio 0.6 alpha - testing and help needed
Quoted from http://bugs.archlinux.org/task/17298 (which is also to be used for feedback, besides the threads on these mailing lists): So, now something can be tested. I recommend using it in conjunction with testing/udev only: [kill-klibc] Server = http://dev.archlinux.org/~thomas/kill-klibc/i686/ or [kill-klibc] Server = http://dev.archlinux.org/~thomas/kill-klibc/x86_64/ The standard hooks work, so do keymap, lvm2, encrypt. What does NOT work is raid/mdadm/dmraid and root on NFS. I would appreciate any input and patches w.r.t. those, as well as any testing. The v86d package also needs to be fixed, but that is trivial. device-mapper, lvm2 and cryptsetup have a weird "1.local" pkgrel so they won't collide with the ones from the repo, sorry if that bothers anyone. If you upgrade to this repositories, your existing mkinitcpio will be replaced and all klibc packages will be gone too. So, if you try it, please save your existing initramfs to a different filename as a fallback, and do not perform kernel upgrades until you either confirmed that it works, or downgraded to the klibc-based mkinitcpio.
Am Sonntag 24 Januar 2010 schrieb Thomas Bächler: > Quoted from http://bugs.archlinux.org/task/17298 (which is also to be > used for feedback, besides the threads on these mailing lists): > > So, now something can be tested. I recommend using it in conjunction > with testing/udev only: > > [kill-klibc] > Server = http://dev.archlinux.org/~thomas/kill-klibc/i686/ > > or > > [kill-klibc] > Server = http://dev.archlinux.org/~thomas/kill-klibc/x86_64/ > > The standard hooks work, so do keymap, lvm2, encrypt. What does NOT work > is raid/mdadm/dmraid and root on NFS. I would appreciate any input and > patches w.r.t. those, as well as any testing. The v86d package also > needs to be fixed, but that is trivial. > > device-mapper, lvm2 and cryptsetup have a weird "1.local" pkgrel so they > won't collide with the ones from the repo, sorry if that bothers anyone. - new mdadm package with symlink to raid hook is needed and probably a non static binary. - dmraid hook just needs to be changed to non static binary then all should work as before. -nfs will be more tricky. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Sun, 24 Jan 2010 19:42:49 +0100, Tobias Powalowski <t.powa@gmx.de> wrote: >> device-mapper, lvm2 and cryptsetup have a weird "1.local" pkgrel so they >> won't collide with the ones from the repo, sorry if that bothers anyone. > - new mdadm package with symlink to raid hook is needed and probably > a non static binary. > - dmraid hook just needs to be changed to non static binary then all should > work as before. I had the same assumption. Do you think we will have "auto detection" if we also add /lib/udev/rules.d/64-md-raid.rules to the initramfs image? -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 24.01.2010 18:05, schrieb Thomas Bächler:
Quoted from http://bugs.archlinux.org/task/17298 (which is also to be used for feedback, besides the threads on these mailing lists):
So, now something can be tested. I recommend using it in conjunction with testing/udev only:
[kill-klibc] Server = http://dev.archlinux.org/~thomas/kill-klibc/i686/
or
[kill-klibc] Server = http://dev.archlinux.org/~thomas/kill-klibc/x86_64/
The standard hooks work, so do keymap, lvm2, encrypt. What does NOT work is raid/mdadm/dmraid and root on NFS. I would appreciate any input and patches w.r.t. those, as well as any testing. The v86d package also needs to be fixed, but that is trivial.
device-mapper, lvm2 and cryptsetup have a weird "1.local" pkgrel so they won't collide with the ones from the repo, sorry if that bothers anyone.
If you upgrade to this repositories, your existing mkinitcpio will be replaced and all klibc packages will be gone too. So, if you try it, please save your existing initramfs to a different filename as a fallback, and do not perform kernel upgrades until you either confirmed that it works, or downgraded to the klibc-based mkinitcpio.
Bump! Virtually nobody has performed any testing (except the people I poked about it). Also, I still don't have fixed raid or dmraid hooks, nor any suggestion for implementing root on NFS (of the last three, I use neither). I could write raid, but I have no idea if it will work. I don't know what exactly needs to be done in the NFS case, because that was all hidden inside "ipconfig" from klibc. The part that works (standard hooks, keymap, cryptsetup, lvm2) has been 100% stable and has worked perfectly for all of the testers so far (which aren't many, so you never know). Note that the klibc-based mkinitcpio has problems which will never be fixed (because I can't fix them, or don't want to fix them), some of which are already fixed in the 0.6 branch. One example is the lack of vfat detection in fstype, which affects people who want to put archiso on vfat volumes - this is no problem because we use blkid now. I am sure there are more examples. I simply refuse to put more time into something that is entirely broken and can't even be rebuilt against our current kernel headers (yes, the last time klibc was successfully rebuilt was against 2.6.29 iirc, the version I built against 2.6.31 works on x86_64, but not on i686).
On Tue, Feb 2, 2010 at 12:13 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 24.01.2010 18:05, schrieb Thomas Bächler:
Quoted from http://bugs.archlinux.org/task/17298 (which is also to be used for feedback, besides the threads on these mailing lists):
So, now something can be tested. I recommend using it in conjunction with testing/udev only:
[kill-klibc] Server = http://dev.archlinux.org/~thomas/kill-klibc/i686/
or
[kill-klibc] Server = http://dev.archlinux.org/~thomas/kill-klibc/x86_64/
The standard hooks work, so do keymap, lvm2, encrypt. What does NOT work is raid/mdadm/dmraid and root on NFS. I would appreciate any input and patches w.r.t. those, as well as any testing. The v86d package also needs to be fixed, but that is trivial.
device-mapper, lvm2 and cryptsetup have a weird "1.local" pkgrel so they won't collide with the ones from the repo, sorry if that bothers anyone.
If you upgrade to this repositories, your existing mkinitcpio will be replaced and all klibc packages will be gone too. So, if you try it, please save your existing initramfs to a different filename as a fallback, and do not perform kernel upgrades until you either confirmed that it works, or downgraded to the klibc-based mkinitcpio.
Bump! Virtually nobody has performed any testing (except the people I poked about it). Also, I still don't have fixed raid or dmraid hooks, nor any suggestion for implementing root on NFS (of the last three, I use neither). I could write raid, but I have no idea if it will work. I don't know what exactly needs to be done in the NFS case, because that was all hidden inside "ipconfig" from klibc.
Is is possible to just port the ipconfig binary from klibc for this purpose? It's already tested
Am 02.02.2010 20:18, schrieb Aaron Griffin:
Bump! Virtually nobody has performed any testing (except the people I poked about it). Also, I still don't have fixed raid or dmraid hooks, nor any suggestion for implementing root on NFS (of the last three, I use neither). I could write raid, but I have no idea if it will work. I don't know what exactly needs to be done in the NFS case, because that was all hidden inside "ipconfig" from klibc.
Is is possible to just port the ipconfig binary from klibc for this purpose? It's already tested
I guess we could try, it will probably compile.
On Tue, Feb 2, 2010 at 1:13 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 24.01.2010 18:05, schrieb Thomas Bächler:
Quoted from http://bugs.archlinux.org/task/17298 (which is also to be used for feedback, besides the threads on these mailing lists):
So, now something can be tested. I recommend using it in conjunction with testing/udev only:
[kill-klibc] Server = http://dev.archlinux.org/~thomas/kill-klibc/i686/
or
[kill-klibc] Server = http://dev.archlinux.org/~thomas/kill-klibc/x86_64/
The standard hooks work, so do keymap, lvm2, encrypt. What does NOT work is raid/mdadm/dmraid and root on NFS. I would appreciate any input and patches w.r.t. those, as well as any testing. The v86d package also needs to be fixed, but that is trivial.
device-mapper, lvm2 and cryptsetup have a weird "1.local" pkgrel so they won't collide with the ones from the repo, sorry if that bothers anyone.
If you upgrade to this repositories, your existing mkinitcpio will be replaced and all klibc packages will be gone too. So, if you try it, please save your existing initramfs to a different filename as a fallback, and do not perform kernel upgrades until you either confirmed that it works, or downgraded to the klibc-based mkinitcpio.
Bump! Virtually nobody has performed any testing (except the people I poked about it). Also, I still don't have fixed raid or dmraid hooks, nor any suggestion for implementing root on NFS (of the last three, I use neither). I could write raid, but I have no idea if it will work. I don't know what exactly needs to be done in the NFS case, because that was all hidden inside "ipconfig" from klibc.
The part that works (standard hooks, keymap, cryptsetup, lvm2) has been 100% stable and has worked perfectly for all of the testers so far (which aren't many, so you never know).
Just tested on my i686 system with lvm2. It booted fine and everything looks OK, in fact I haven't noted any difference. Hooks used in /etc/mkinitcpio.conf: HOOKS="base udev autodetect pata usbinput keymap lvm2 filesystems" I would be willing to test raid support when it will be added. I'm not really familiar with kernels and early userspace stuff so I can't be much help in making a patch for it.
Note that the klibc-based mkinitcpio has problems which will never be fixed (because I can't fix them, or don't want to fix them), some of which are already fixed in the 0.6 branch.
One example is the lack of vfat detection in fstype, which affects people who want to put archiso on vfat volumes - this is no problem because we use blkid now. I am sure there are more examples. I simply refuse to put more time into something that is entirely broken and can't even be rebuilt against our current kernel headers (yes, the last time klibc was successfully rebuilt was against 2.6.29 iirc, the version I built against 2.6.31 works on x86_64, but not on i686).
participants (5)
-
Aaron Griffin
-
Eric Bélanger
-
Pierre Schmitz
-
Thomas Bächler
-
Tobias Powalowski