Re: [arch-general] Error message on mkinitcpio
On Fri, Feb 12, 2010 at 3:02 AM, Thomas Bächler tho...@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.
Re: [arch-general] Error message on mkinitcpio
Am 14.02.2010 17:38, schrieb Ray Kohler:
On Fri, Feb 12, 2010 at 3:02 AM, Thomas Bächler tho...@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.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Error message on mkinitcpio
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? signature.asc Description: OpenPGP digital signature
[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/ --
Re: [arch-general] Error message on mkinitcpio
On Thu, Feb 11, 2010 at 9:32 AM, Tomás Acauan Schertel tscher...@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.
Re: [arch-general] Error message on mkinitcpio
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? signature.asc Description: OpenPGP digital signature
Re: [arch-general] Error message on mkinitcpio
On Thu, Feb 11, 2010 at 12:51 PM, Thomas Bächler tho...@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
Re: [arch-general] Error message on mkinitcpio
On Thu, Feb 11, 2010 at 10:27 PM, Dan McGee dpmc...@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.
Re: [arch-general] Error message on mkinitcpio
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.xav...@gmail.comwrote: On Thu, Feb 11, 2010 at 10:27 PM, Dan McGee dpmc...@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.
Re: [arch-general] Error message on mkinitcpio
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
Re: [arch-general] Error message on mkinitcpio
On Fri, Feb 12, 2010 at 00:57, Gerardo Exequiel Pozzi vmlinuz...@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
Re: [arch-general] Error message on mkinitcpio
On 02/12/2010 01:03 AM, Tomás Acauan Schertel wrote:
On Fri, Feb 12, 2010 at 00:57, Gerardo Exequiel Pozzi
vmlinuz...@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
