My system: brand-new, recently installed, stable amd64. # emerge -av memtest86+ [...] --- /usr/ --- /usr/share/ --- /usr/share/doc/ >>> /usr/share/doc/memtest86+-2.01/ >>> /usr/share/doc/memtest86+-2.01/README.build-process.bz2 >>> /usr/share/doc/memtest86+-2.01/README.bz2 --- /boot/ >>> /boot/memtest86plus/ >>> /boot/memtest86plus/memtest.bin * * memtest.bin has been installed in /boot/memtest86plus/ * You may wish to update your bootloader configs * by adding these lines: /var/tmp/portage/sys-apps/memtest86+-2.01/temp/environment: line 2100: 6 0-1: syntax error in expression (error token is "0-1") !!! FAILED postinst: 1 This is the line 2100 of that file: root="(hd${root:0:1},$((${root:1:3}-1)))"; Which is one of the pkg_postinst lines.
Please post your `emerge --info' and attach the environment file.
Created attachment 184020 [details] emerge --info
Created attachment 184022 [details] environment /var/tmp/portage/sys-apps/memtest86+-2.01/temp/environment
It's probably a good idea to attach /etc/fstab as well.
Created attachment 184069 [details] fstab
Now I understand it. Using UUID= or LABEL= in /etc/fstab breaks the postinst script. I wonder if looking at /proc/mounts, or /etc/mtab, or at the output of "mount" command could be better. But, also, if someone had a line like this: #/dev/bootdevice /boot ext2 noatime 1 2 It would still break current script logic. Since memtest86+ is installed at /boot, which is the same place as the kernel, I bet the user already has the required lines to boot the kernel, and thus already knows the correct (hd?,?) string. Maybe the entire logic could be dropped and a simple message printed instead, forcing the user to fix the '?' characters. Or maybe that message could be just a fallback. If you still want to fix that logic for UUID/LABEL, look at /dev/disk/by-uuid/ or 'blkid' command. But personally I still think that logic can fail in some cases, because I'm not sure that Linux device name ([sh]d[a-z][0-9]) can be translated correctly to grub devices (hd[0-9],[0-9]) for all systems using that simple substitution.
There's a lot of valid block devices beyond [sh]d[a-z]+[0-9]+. Maybe better to look at the grub device.map cache? Or better, since we require that /boot is mounted, we could just look at it for the current kernel and hence find the current root argument. But as you say, putting some placeholder in, and just letting the user update grub.conf is probably fine. What I don't follow, is why the entire postinst block bailed out. The rc value at the end should have been already.
(In reply to comment #7) > Maybe better to look at the grub device.map cache? Maybe not everyone might be using grub (the postinst message explains how to configure grub and lilo), so this would only be a bonus feature if the user had grub, but shouldn't do anything if the user doesn't. But, still, the simple generic and dumb placeholder would probably be fine.
I completely agree that removing this code should be OK from the users' POV. I thus removed the code in CVS and replaced it with a generic einfo line with placeholders.
Hey, I just checked... sys-apps/memtest86 is also affected by this bug. Sorry to reopen this bug, I should have checked this before, to save you time. On the other hand, I think there is no need for a new bug.
(In reply to comment #10) > Hey, I just checked... sys-apps/memtest86 is also affected by this bug. Right, fixed that one too. Thanks!
