[arch-general] [RFC] patches to initscripts
On Fri, Nov 19, 2010 at 7:58 AM, Allan McRae <allan@archlinux.org> wrote:
While looking through bugs for [core] packages, I notice that there are a large number of bug report for these three packages. In total they account for ~13% of the bugs in the tracker!
[...]
But given these are some of the uniqueness of Arch, I wonder what we _as a group_ could to do to improve this situation? Perhaps organize a hack-a-thon on IRC one day? Or we could advertise for help, with the selection criterion being a git repo provided by the applicant showing they can do stuff?
As discussed with Allan, here are some patches to initscripts: <https://github.com/teg/initscripts-arch>. Comments very much welcome. I started off with what appeared to me as the low-hanging fruit. Once I have had feedback on this I'll have a look at more difficult (or invasive) problems. My long-term goal is to ease the maintenance burden of initscripts by simplifying them and harmonizing them with other distros/projects (without, of course, loosing any of their features). Cheers, Tom
Am 06.12.2010 11:39, schrieb Tom Gundersen:
On Fri, Nov 19, 2010 at 7:58 AM, Allan McRae <allan@archlinux.org> wrote:
While looking through bugs for [core] packages, I notice that there are a large number of bug report for these three packages. In total they account for ~13% of the bugs in the tracker!
[...]
But given these are some of the uniqueness of Arch, I wonder what we _as a group_ could to do to improve this situation? Perhaps organize a hack-a-thon on IRC one day? Or we could advertise for help, with the selection criterion being a git repo provided by the applicant showing they can do stuff?
As discussed with Allan, here are some patches to initscripts: <https://github.com/teg/initscripts-arch>.
Comments very much welcome.
I started off with what appeared to me as the low-hanging fruit. Once I have had feedback on this I'll have a look at more difficult (or invasive) problems.
My long-term goal is to ease the maintenance burden of initscripts by simplifying them and harmonizing them with other distros/projects (without, of course, loosing any of their features).
https://github.com/teg/initscripts-arch/commit/b4c804d60d6e8361db3f19bf3a2fa... Two short comments about this commit: 1) We need to run vgchange again after rw-mounting everything (without --sysinit), so monitoring can be set up. 2) mkinitcpio's LVM hook also needs --sysinit. The rest of the patches are fine.
On Mon, Dec 6, 2010 at 12:04 PM, Thomas Bächler <thomas@archlinux.org> wrote:
https://github.com/teg/initscripts-arch/commit/b4c804d60d6e8361db3f19bf3a2fa...
Two short comments about this commit:
1) We need to run vgchange again after rw-mounting everything (without --sysinit), so monitoring can be set up. 2) mkinitcpio's LVM hook also needs --sysinit.
The rest of the patches are fine.
Thanks to Thomas and Dave for fast feedback. I pushed a few more commits to my trees to address their comments: <https://github.com/teg/initscripts-arch/> <https://github.com/teg/mkinitcpio/> Finally, here is a patch for mkinitcpio's LVM hook (don't know if this is the best way to contribute to svn repo's...): --- lvm2_hook 2010-12-06 13:20:10.588544437 +0100 +++ lvm2_hook 2010-12-06 13:25:22.838755236 +0100 @@ -20,6 +20,6 @@ msg "Scanning logical volumes..." eval /sbin/lvm vgscan --ignorelockingfailure $LVMQUIET msg "Activating logical volumes..." - eval /sbin/lvm vgchange --ignorelockingfailure --ignoremonitoring -ay $LVMQUIET + eval /sbin/vgchange --sysinit -a y $LVMQUIET fi }
Am 06.12.2010 13:43, schrieb Tom Gundersen:
On Mon, Dec 6, 2010 at 12:04 PM, Thomas Bächler <thomas@archlinux.org> wrote:
https://github.com/teg/initscripts-arch/commit/b4c804d60d6e8361db3f19bf3a2fa...
Two short comments about this commit:
1) We need to run vgchange again after rw-mounting everything (without --sysinit), so monitoring can be set up. 2) mkinitcpio's LVM hook also needs --sysinit.
The rest of the patches are fine.
Thanks to Thomas and Dave for fast feedback. I pushed a few more commits to my trees to address their comments:
<https://github.com/teg/initscripts-arch/> <https://github.com/teg/mkinitcpio/>
Thanks. The initscripts patch won't work though: [[ $USELVM =~ yes|YES && -x /sbin/lvm && -d /sys/block ]] || return "return" is a statement that will only work inside a function. I don't know what it will do on the top level, but certainly not what you'd expect.
Finally, here is a patch for mkinitcpio's LVM hook (don't know if this is the best way to contribute to svn repo's...):
--- lvm2_hook 2010-12-06 13:20:10.588544437 +0100 +++ lvm2_hook 2010-12-06 13:25:22.838755236 +0100 @@ -20,6 +20,6 @@ msg "Scanning logical volumes..." eval /sbin/lvm vgscan --ignorelockingfailure $LVMQUIET msg "Activating logical volumes..." - eval /sbin/lvm vgchange --ignorelockingfailure --ignoremonitoring -ay $LVMQUIET + eval /sbin/vgchange --sysinit -a y $LVMQUIET fi }
Heh, there is no good way, sadly.
On Mon, Dec 6, 2010 at 1:52 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Thanks. The initscripts patch won't work though:
[[ $USELVM =~ yes|YES && -x /sbin/lvm && -d /sys/block ]] || return "return" is a statement that will only work inside a function. I don't know what it will do on the top level, but certainly not what you'd expect.
D'oh! Copy-paste error, sorry about that. Updated commit: <https://github.com/teg/initscripts-arch/commit/feef447b8368244525dd98582b662a369098b2f7>. Thanks for testing, Tom
Am 06.12.2010 16:48, schrieb Tom Gundersen:
On Mon, Dec 6, 2010 at 1:52 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Thanks. The initscripts patch won't work though:
[[ $USELVM =~ yes|YES && -x /sbin/lvm && -d /sys/block ]] || return "return" is a statement that will only work inside a function. I don't know what it will do on the top level, but certainly not what you'd expect.
D'oh! Copy-paste error, sorry about that.
Updated commit: <https://github.com/teg/initscripts-arch/commit/feef447b8368244525dd98582b662a369098b2f7>.
Thanks for testing,
Tom
I pushed everything to the official git tree. There's one more thing about the check in the SWAP area of the crypttab code: Instead of using isLuks to check for a LUKS device, check with blkid whether there is any valid file system signature on it. The problem is: If blkid finds more than one valid signature, it will not return anything, and we will mistakenly believe that there is no file system (and happily overwrite the drive). This part of initscripts is giving me a headache everytime I touch it.
On Tue, Dec 7, 2010 at 1:10 AM, Thomas Bächler <thomas@archlinux.org> wrote:
I pushed everything to the official git tree.
Great!
There's one more thing about the check in the SWAP area of the crypttab code: Instead of using isLuks to check for a LUKS device, check with blkid whether there is any valid file system signature on it.
The problem is: If blkid finds more than one valid signature, it will not return anything, and we will mistakenly believe that there is no file system (and happily overwrite the drive). This part of initscripts is giving me a headache everytime I touch it.
Hmmm... Interesting... I'll put this on my mental TODO list and have a look next time I have time. Cheers, Tom
On Tue, 07 Dec 2010 01:10:12 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
The problem is: If blkid finds more than one valid signature, it will not return anything, and we will mistakenly believe that there is no file system (and happily overwrite the drive). This part of initscripts is giving me a headache everytime I touch it.
what do the util-linux-ng maintainers say about that? Isn't this something that should be fixed in the blkid source code? Dieter
Am 07.12.2010 14:30, schrieb Dieter Plaetinck:
The problem is: If blkid finds more than one valid signature, it will not return anything, and we will mistakenly believe that there is no file system (and happily overwrite the drive). This part of initscripts is giving me a headache everytime I touch it.
what do the util-linux-ng maintainers say about that? Isn't this something that should be fixed in the blkid source code?
No, that won't be fixed - at least not the way you think. Older blkid-like tools used to report the first matched signature. That resulted in (for example) using an ext3 file system that also happened to have a valid swap header as swapspace, destroying the ext3 file system. (There are tons of other examples like this, in particular, old versions of cryptsetup and mkswap didn't wipe old existing file system headers.) It was decided that blkid will refuse to report any ambiguous match as a match. I'm thinking about requesting a feature that allows to report any match, ambiguous or not.
On Mon, 6 Dec 2010 11:39:06 +0100 Tom Gundersen <teg@jklm.no> wrote:
On Fri, Nov 19, 2010 at 7:58 AM, Allan McRae <allan@archlinux.org> wrote:
While looking through bugs for [core] packages, I notice that there are a large number of bug report for these three packages. In total they account for ~13% of the bugs in the tracker!
[...]
But given these are some of the uniqueness of Arch, I wonder what we _as a group_ could to do to improve this situation? Perhaps organize a hack-a-thon on IRC one day? Or we could advertise for help, with the selection criterion being a git repo provided by the applicant showing they can do stuff?
As discussed with Allan, here are some patches to initscripts: <https://github.com/teg/initscripts-arch>.
Comments very much welcome.
Do you think, you can have a look at https://bugs.archlinux.org/task/16625 It's a constant annoyance if you use something like qemu/kvm/etc and have to wait ~20 seconds on every boot just for your dhcp-assigned IP-Address. Thanks, Jinks
Am 08.12.2010 00:47, schrieb Alexander Duscheleit:
Do you think, you can have a look at https://bugs.archlinux.org/task/16625
It's a constant annoyance if you use something like qemu/kvm/etc and have to wait ~20 seconds on every boot just for your dhcp-assigned IP-Address.
Thanks, Jinks
Please oh please can that be implemented that in netcfg (basic bridging is there, but no advanced options), so we can drop bridging support from initscripts entirely?
participants (4)
-
Alexander Duscheleit
-
Dieter Plaetinck
-
Thomas Bächler
-
Tom Gundersen