[arch-general] Error message on mkinitcpio
This is the second time it happens. When upgrading kernel, I got this message: :: Parsing hook [autodetect] /lib/initcpio/install/autodetect: line 17: other:swap:2: command not found :: Parsing hook [pata] Am I the only one seeing this? Cheers. -- Tomás A. Schertel ---------------------------------------------- Linux Registered User #304838 Arch Linux User http://www.archlinux-br.org/ ----------------------------------------------
On Thu, Feb 11, 2010 at 9:32 AM, Tomás Acauan Schertel <tschertel@gmail.com> wrote:
This is the second time it happens. When upgrading kernel, I got this message:
:: Parsing hook [autodetect] /lib/initcpio/install/autodetect: line 17: other:swap:2: command not found :: Parsing hook [pata]
Am I the only one seeing this?
Others are seeing it too. It's fixed on the trunk and we'll get it when the kill-klibc mkinitcpio is released.
Thanks Ray. :) -- Tomás A. Schertel ---------------------------------------------- Linux Registered User #304838 Arch Linux User http://www.archlinux-br.org/ ---------------------------------------------- On Thu, Feb 11, 2010 at 12:35, Ray Kohler <ataraxia937@gmail.com> wrote:
On Thu, Feb 11, 2010 at 9:32 AM, Tomás Acauan Schertel <tschertel@gmail.com> wrote:
This is the second time it happens. When upgrading kernel, I got this message:
:: Parsing hook [autodetect] /lib/initcpio/install/autodetect: line 17: other:swap:2: command not found :: Parsing hook [pata]
Am I the only one seeing this?
Others are seeing it too. It's fixed on the trunk and we'll get it when the kill-klibc mkinitcpio is released.
Am 11.02.2010 15:32, schrieb Tomás Acauan Schertel:
This is the second time it happens. When upgrading kernel, I got this message:
:: Parsing hook [autodetect] /lib/initcpio/install/autodetect: line 17: other:swap:2: command not found :: Parsing hook [pata]
Am I the only one seeing this?
Cheers.
Can you install testing/mkinitcpio to see if this is fixed, please?
On Thu, 2010-02-11 at 16:25 +0100, Thomas Bächler wrote:
Am 11.02.2010 15:32, schrieb Tomás Acauan Schertel:
This is the second time it happens. When upgrading kernel, I got this message:
:: Parsing hook [autodetect] /lib/initcpio/install/autodetect: line 17: other:swap:2: command not found :: Parsing hook [pata]
Am I the only one seeing this?
Cheers.
Can you install testing/mkinitcpio to see if this is fixed, please?
I've seen that advise come up sometimes from a package maintainer. Can this be assumed to mean (as I'm sure some will assume it to mean) that its safe to cherry-pick just mkinitcpio from testing? Or does the tester need to 'know' to -Syu from testing totally? Nothing specifically at you, Thomas, more a general question (hence I'm changing the title, its a different thread).
Am 11.02.2010 16:35, schrieb Ng Oon-Ee:
I've seen that advise come up sometimes from a package maintainer. Can this be assumed to mean (as I'm sure some will assume it to mean) that its safe to cherry-pick just mkinitcpio from testing? Or does the tester need to 'know' to -Syu from testing totally?
Nothing specifically at you, Thomas, more a general question (hence I'm changing the title, its a different thread).
In this case, it is safe (you will probably have to upgrade device-mapper,lvm2,mdadm,cryptsetup,dmraid as well if they are installed because pacman will otherwise abort due to conflicts). In general, it is not always safe to do so, I guess the package maintainer who suggests cherry-picking probably knows best. However, testing is virtually empty now: there's 16 packages in there, so the harm should be minimal in any case.
# pacman -S testing/mkinitcpio resolving dependencies... looking for inter-conflicts... Targets (2): mkinitcpio-busybox-1.15.3-4 mkinitcpio-0.5.99.5-1 Total Download Size: 0.00 MB Total Installed Size: 0.44 MB Proceed with installation? [Y/n] checking package integrity... (2/2) checking for file conflicts [#####################] 100% error: failed to commit transaction (conflicting files) mkinitcpio: /lib/initcpio/hooks/keymap exists in filesystem mkinitcpio: /lib/initcpio/hooks/udev exists in filesystem mkinitcpio: /lib/initcpio/install/keymap exists in filesystem mkinitcpio: /lib/initcpio/install/udev exists in filesystem mkinitcpio: /lib/initcpio/udev/load-modules.sh exists in filesystem Errors occurred, no packages were upgraded. Is it right?? Can I use f to force install? Does it really needs mkinitcpio-busybox?? -- Tomás A. Schertel ---------------------------------------------- Linux Registered User #304838 Arch Linux User http://www.archlinux-br.org/ ---------------------------------------------- On Thu, Feb 11, 2010 at 13:25, Thomas Bächler <thomas@archlinux.org> wrote:
Am 11.02.2010 15:32, schrieb Tomás Acauan Schertel:
This is the second time it happens. When upgrading kernel, I got this message:
:: Parsing hook [autodetect] /lib/initcpio/install/autodetect: line 17: other:swap:2: command not found :: Parsing hook [pata]
Am I the only one seeing this?
Cheers.
Can you install testing/mkinitcpio to see if this is fixed, please?
On 02/11/2010 02:47 PM, Tomás Acauan Schertel wrote:
# pacman -S testing/mkinitcpio resolving dependencies... looking for inter-conflicts...
Targets (2): mkinitcpio-busybox-1.15.3-4 mkinitcpio-0.5.99.5-1
Total Download Size: 0.00 MB Total Installed Size: 0.44 MB
Proceed with installation? [Y/n] checking package integrity... (2/2) checking for file conflicts [#####################] 100% error: failed to commit transaction (conflicting files) mkinitcpio: /lib/initcpio/hooks/keymap exists in filesystem mkinitcpio: /lib/initcpio/hooks/udev exists in filesystem mkinitcpio: /lib/initcpio/install/keymap exists in filesystem mkinitcpio: /lib/initcpio/install/udev exists in filesystem mkinitcpio: /lib/initcpio/udev/load-modules.sh exists in filesystem Errors occurred, no packages were upgraded.
Is it right?? Can I use f to force install? Does it really needs mkinitcpio-busybox??
Or full-upgrade (as brain0 said before there are few packages) _recomended_ Or first remove all klibc stuff, install mkinitcpio, then run again mkinitcpio -p kernel26 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Am 11.02.2010 18:47, schrieb Tomás Acauan Schertel:
# pacman -S testing/mkinitcpio resolving dependencies... looking for inter-conflicts...
Targets (2): mkinitcpio-busybox-1.15.3-4 mkinitcpio-0.5.99.5-1
Total Download Size: 0.00 MB Total Installed Size: 0.44 MB
Proceed with installation? [Y/n] checking package integrity... (2/2) checking for file conflicts [#####################] 100% error: failed to commit transaction (conflicting files) mkinitcpio: /lib/initcpio/hooks/keymap exists in filesystem mkinitcpio: /lib/initcpio/hooks/udev exists in filesystem mkinitcpio: /lib/initcpio/install/keymap exists in filesystem mkinitcpio: /lib/initcpio/install/udev exists in filesystem mkinitcpio: /lib/initcpio/udev/load-modules.sh exists in filesystem Errors occurred, no packages were upgraded.
Is it right?? Can I use f to force install? Does it really needs mkinitcpio-busybox??
I thought replaces was handled by -S already, seems it is only done by -Su.
On Thu, Feb 11, 2010 at 12:51 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 11.02.2010 18:47, schrieb Tomás Acauan Schertel:
# pacman -S testing/mkinitcpio resolving dependencies... looking for inter-conflicts...
Targets (2): mkinitcpio-busybox-1.15.3-4 mkinitcpio-0.5.99.5-1
Total Download Size: 0.00 MB Total Installed Size: 0.44 MB
Proceed with installation? [Y/n] checking package integrity... (2/2) checking for file conflicts [#####################] 100% error: failed to commit transaction (conflicting files) mkinitcpio: /lib/initcpio/hooks/keymap exists in filesystem mkinitcpio: /lib/initcpio/hooks/udev exists in filesystem mkinitcpio: /lib/initcpio/install/keymap exists in filesystem mkinitcpio: /lib/initcpio/install/udev exists in filesystem mkinitcpio: /lib/initcpio/udev/load-modules.sh exists in filesystem Errors occurred, no packages were upgraded.
Is it right?? Can I use f to force install? Does it really needs mkinitcpio-busybox??
I thought replaces was handled by -S already, seems it is only done by -Su.
I think we may have this fixed in pacman-git, but Nagy or Xavier would know for sure... -Dan
On Thu, Feb 11, 2010 at 10:27 PM, Dan McGee <dpmcgee@gmail.com> wrote:
I think we may have this fixed in pacman-git, but Nagy or Xavier would know for sure...
That documentation from man PKGBUILD still applies, I don't think we ever considered it as a bug/problem : replaces (array) An array of packages that this package should replace, and can be used to handle renamed/combined packages. For example, if the j2re package is renamed to jre, this directive allows future upgrades to continue as expected even though the package has moved. Sysupgrade is currently the only pacman operation that utilizes this field, a normal sync will not use its value. But now I am wondering if replaces could imply conflicts/provides. Implicit fields means less control and power to the user/packager though.
I still got error message after using packages from [testing]. Am I doing something wrong?? -- Tomás A. Schertel ---------------------------------------------- Linux Registered User #304838 Arch Linux User http://www.archlinux-br.org/ ---------------------------------------------- On Thu, Feb 11, 2010 at 22:46, Xavier Chantry <chantry.xavier@gmail.com>wrote:
On Thu, Feb 11, 2010 at 10:27 PM, Dan McGee <dpmcgee@gmail.com> wrote:
I think we may have this fixed in pacman-git, but Nagy or Xavier would know for sure...
That documentation from man PKGBUILD still applies, I don't think we ever considered it as a bug/problem :
replaces (array) An array of packages that this package should replace, and can be used to handle renamed/combined packages. For example, if the j2re package is renamed to jre, this directive allows future upgrades to continue as expected even though the package has moved. Sysupgrade is currently the only pacman operation that utilizes this field, a normal sync will not use its value.
But now I am wondering if replaces could imply conflicts/provides. Implicit fields means less control and power to the user/packager though.
On 02/11/2010 11:26 PM, Tomás Acauan Schertel wrote:
I still got error message after using packages from [testing]. Am I doing something wrong??
what of error message? conflicts files in pacman? or when mkinitcpio generates the image? PS: Please avoid top-response. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Fri, Feb 12, 2010 at 00:57, Gerardo Exequiel Pozzi < vmlinuz386@yahoo.com.ar> wrote:
On 02/11/2010 11:26 PM, Tomás Acauan Schertel wrote:
I still got error message after using packages from [testing]. Am I doing something wrong??
what of error message? conflicts files in pacman? or when mkinitcpio generates the image?
mkinitcpio generating the image
PS: Please avoid top-response.
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On 02/12/2010 01:03 AM, Tomás Acauan Schertel wrote:
On Fri, Feb 12, 2010 at 00:57, Gerardo Exequiel Pozzi< vmlinuz386@yahoo.com.ar> wrote:
On 02/11/2010 11:26 PM, Tomás Acauan Schertel wrote:
I still got error message after using packages from [testing]. Am I doing something wrong??
what of error message? conflicts files in pacman? or when mkinitcpio generates the image?
mkinitcpio generating the image
OK. What returns this command (this is what are around line 17)? # as root, in this case shuld view the error message for blkdev in $(find /dev -type b | grep -v -e /dev/loop -e /dev/ram -e /dev/fd); do (eval $(/sbin/blkid -o udev -p "${blkdev}"); [ "${ID_FS_USAGE}" = "filesystem" ] && echo $ID_FS_TYPE) done in that case, execute this for blkdev in $(find /dev -type b | grep -v -e /dev/loop -e /dev/ram -e /dev/fd); do /sbin/blkid -o udev -p "${blkdev}" done -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Am 12.02.2010 03:26, schrieb Tomás Acauan Schertel:
I still got error message after using packages from [testing]. Am I doing something wrong??
Is the line number still 17?
On Fri, Feb 12, 2010 at 3:02 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 12.02.2010 03:26, schrieb Tomás Acauan Schertel:
I still got error message after using packages from [testing]. Am I doing something wrong??
Is the line number still 17?
I was surprised to still see this autodetect error after upgrading to the glibc-based mkinitcpio, so apparently Pierre's fix wasn't the whole fix. I have an understanding of why I saw it now: blkid detected my swap as a VFAT filesystem (which used to be there before), and so it had a very short UUID (something like 3030-3030). Apparently the autodetect hook doesn't like that. I dd'ed zeros over the swap and re-created it, so that it now has a "normal" UUID and the right type given by blkid, changed UUID in fstab, and the autodetect error went away. I don't know if this is something we really care about. Probably it's worth making it work for UUIDs of strange lengths, but no so interesting to cover over problems from people (like me, apparently) who just have wrong data written on their disks.
Am 14.02.2010 17:38, schrieb Ray Kohler:
On Fri, Feb 12, 2010 at 3:02 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 12.02.2010 03:26, schrieb Tomás Acauan Schertel:
I still got error message after using packages from [testing]. Am I doing something wrong??
Is the line number still 17?
I was surprised to still see this autodetect error after upgrading to the glibc-based mkinitcpio, so apparently Pierre's fix wasn't the whole fix.
I have an understanding of why I saw it now: blkid detected my swap as a VFAT filesystem (which used to be there before), and so it had a very short UUID (something like 3030-3030). Apparently the autodetect hook doesn't like that. I dd'ed zeros over the swap and re-created it, so that it now has a "normal" UUID and the right type given by blkid, changed UUID in fstab, and the autodetect error went away.
I don't know if this is something we really care about. Probably it's worth making it work for UUIDs of strange lengths, but no so interesting to cover over problems from people (like me, apparently) who just have wrong data written on their disks.
It is a very old story that has been discussed at length on the util-linux-ng mailing list: Some file system creation tools (in particular cryptsetup and mkswap) didn't overwrite file system signatures left behind by other file systems. This lead to data corruption, destroyed file systems and the like. Thus, blkid refuses to detect file systems if it finds signatures for more than one file system. The command "blkid -o udev -p /dev/XXX" will print: ID_FS_AMBIVALEN=filesystem:vfat:1 other:swap:2 and eval'ing that line will (due to the lack of quotes) result in your error message (I just found this out a few minutes ago, and thus can now explain your error message). This is particularly bad if your root file system is affected: The old vol_id from udev just used the first signature it found and we could thus mount it, but we use blkid in initramfs now: Your file system type won't be detected on boot and mounting will fail, thus booting will fail. Just a few minutes ago, I investigated a case where there was an ambiguity between minix and ext3. We also had discussions about this when udev first switched from vol_id to blkid, because /dev/disk/by-{uuid,label} entries were missing for the same reason. Suffice it to say, current versions of cryptsetup and mkswap do overwrite other file system signatures properly. But old volumes might still suffer from these problems.
participants (7)
-
Dan McGee
-
Gerardo Exequiel Pozzi
-
Ng Oon-Ee
-
Ray Kohler
-
Thomas Bächler
-
Tomás Acauan Schertel
-
Xavier Chantry