|
Created on 2010-08-12.09:27:15 by dahlberg, last changed 2010-09-28.22:16:09 by mika.
msg3365 (view) |
Author: mika |
Date: 2010-09-28.22:16:08 |
|
We believe that your issue has been closed by the upload of
Version 0.9.28 of grml2usb from Michael Prokop <mika@grml.org>.
The explanation is attached below
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.8
Date: Tue, 28 Sep 2010 23:57:16 +0200
Source: grml2usb
Binary: grml2usb
Architecture: source all
Version: 0.9.28
Distribution: unstable
Urgency: low
Maintainer: Michael Prokop <mika@grml.org>
Changed-By: Michael Prokop <mika@grml.org>
Description:
grml2usb - install grml system / ISO to usb device
Changes:
grml2usb (0.9.28) unstable; urgency=low
.
[ Ulrich Dangel ]
* [7b4fa5c] Some code cleanup.
* [2a93d92] Copy bootloader files from /usr/lib/syslinux/
[Closes: issue894]
* [c0fd54e] Run grub-install without and with --force option.
* [1a5a6cd] bsd4grml was not copied correctly to the target device.
.
[ Christian Hofstaedtler ]
* [875b62b] Rename variables in update_grml_versions to be less
confusing.
* [791485b] Properly update grml-versions when updating a grml
flavour.
.
[ Michael Prokop ]
* [91529cc] Bump Standards-Version to 3.9.1.
Checksums-Sha1:
e5094f87e942ae7bc63d6a22dddf9d4452821449 884 grml2usb_0.9.28.dsc
2bfbd731b6e0071c45d2750db3954fab80c5273c 1242206 grml2usb_0.9.28.tar.gz
314008d2992538b8ccd8b5f2ef3b91b559084813 866138 grml2usb_0.9.28_all.deb
Checksums-Sha256:
9eec660fd87c6606d732d1a1d10def84b9ebadec74a8e04eaa2b618fef50d6e0 884 grml2usb_0.9.28.dsc
fedfb6d9788cf73be2e5100d449b23a0ed3eb60e8b80bcf59abcb374bf190e3b 1242206 grml2usb_0.9.28.tar.gz
757bbff21303d4d57cb6714a1b9f8c1ecbbbd3c240bda55ee3079c91bc49fdc0 866138 grml2usb_0.9.28_all.deb
Files:
19a8e1dd0f040c6f6d37a3098a7c0ad5 884 grml optional grml2usb_0.9.28.dsc
3b064fa3a609abdd1b1c3de7879c8267 1242206 grml optional grml2usb_0.9.28.tar.gz
0bf0b81f901a2806906abc1bf1dbac82 866138 grml optional grml2usb_0.9.28_all.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEUEARECAAYFAkyiZQoACgkQ2N9T+zficuiZnQCY29QuDcdPW/n9uqz99d/YQVBp
3QCfcxSd2rCSGx0QCxGiV6Y9RKB2sqY=
=GWjG
-----END PGP SIGNATURE-----
|
msg3332 (view) |
Author: mru |
Date: 2010-08-18.13:36:12 |
|
as syslinux-common is already a dependency for syslinux i changed the code so
that it will always try to copy *.c32 files from /usr/lib/sylinux/ to
/boot/syslinux
|
msg3330 (view) |
Author: dahlberg |
Date: 2010-08-12.14:34:45 |
|
Am Donnerstag, den 12.08.2010, 13:44 +0000 schrieb Ulrich Dangel:
> > So what is the problem with non-Debian distros? Unresolved dependencies
> > to syslinux-common and maybe differing locations of the modules?
>
> Yes. Mainly different locations. But maybe a combined approach like finding
> the modules, fallback to the 4.x modules within grml2usb and test if the
> modules on the directory match the isolinux version.
Let me try to get the things in order:
1. grml2usb uses the actual program call "syslinux" to install syslinux
2. The syslinux modules included in the iso file are matching the
version of the isos syslinux boot loader.
3. The version of the modules in the iso and the version of syslinux
used to install the bootloade do not necessarily match.
(3b. The version of the syslinux programm and the installed modules on
the installing system could possibly incompatible, too. But this
is the distros problem. Compare the aforementioned Debian bug
report, which is btw. solved by now.)
4. So if we try to install syslinux using the distros programm call,
we should ensure, we copy the (hopefully fitting) module too.
Otherwise installing an old GRML from a new system or a fresh GRML
from an older system will fail.
Seems for me to be solved easily. In pseudo shell code:
mount /dev/usbstick /tmp/grml2usbHASH # If not mounted already
[ -x /usr/lib/syslinux/vesamenu.c32 ] \
&& cp /usr/lib/syslinux/vesamenu.c32 /tmp/grml2usbHASH/boot/
[ -x /usr/lib/syslinux/ifcpu64.c32 ] \
&& cp /usr/lib/syslinux/ifcpu64.c32 /tmp/grml2usbHASH/boot/
[ -x /usr/lib/syslinux/hdt.c32 ] \
&& cp /usr/lib/syslinux/hdt.c32 /tmp/grml2usbHASH/boot/addons/
Just a little bit more wisely -> should be do in copy_bootloader_files
and copy_addons. If the versions of syslinux and the modules are not
matching then, we may blame it to the distribution ;-)
Cheers,
David
--
David Dahlberg <david.dahlberg@fkie.fraunhofer.de>
Fraunhofer FKIE, Dept. Communication Systems (KOM) | Tel: +49-228-9435-845
Neuenahrer Str. 20, 53343 Wachtberg, Germany | Fax: +49-228-856277
|
msg3328 (view) |
Author: mru |
Date: 2010-08-12.13:44:09 |
|
On Thursday 12 August 2010 15:13:31 David Dahlberg wrote:
> Hmm, one solution is adjusting the modules of the image to match the
> installed version of isolinux of the distribution. The other option
> would be to ship the matching isolinux version with the grml2usb
> package.
Yes, but shipping isolinux inside grml2usb should be IMHO the last option
(additional source code to maintain in the repo, including a static linked
binary is also no option)
> But I see a problem with this, if you want to support a lot of GRML
> images and not only the most recent one ...
As we currently have daily images for stable as well as testing&sid they
currently have different isolinux versions.
> So what is the problem with non-Debian distros? Unresolved dependencies
> to syslinux-common and maybe differing locations of the modules?
Yes. Mainly different locations. But maybe a combined approach like finding
the modules, fallback to the 4.x modules within grml2usb and test if the
modules on the directory match the isolinux version.
But i am not sure how important non-Debian distros are anyway :)
regards,
Ulrich
|
msg3327 (view) |
Author: dahlberg |
Date: 2010-08-12.13:13:31 |
|
Am Donnerstag, den 12.08.2010, 12:33 +0000 schrieb Ulrich Dangel:
> The correct solution for grml2usb could be to overwrite existing modules on
> the disk with the ones from the distribution. Unfortunately this only would
> work for debian based distributions. Or we can just ignore it as this happens
> rarely. But currently we have different isolinux versions in stable and
> testing and they require different modules...
Hmm, one solution is adjusting the modules of the image to match the
installed version of isolinux of the distribution. The other option
would be to ship the matching isolinux version with the grml2usb
package.
But I see a problem with this, if you want to support a lot of GRML
images and not only the most recent one ...
So what is the problem with non-Debian distros? Unresolved dependencies
to syslinux-common and maybe differing locations of the modules?
-dd
|
msg3323 (view) |
Author: mru |
Date: 2010-08-12.12:33:26 |
|
On Thursday 12 August 2010 11:27:16 David Dahlberg wrote:
Hi,
> If I install GRML 2010.04 to the second partition of an USB stick, using
> GRML2USB 0.9.27 and boot it in a i386 machine, the following happens:
>
> Syslinux gives error messages "vesamenu.c32: not a COM23R image" in regular
> intervals. But at least there get a "boot: " prompt, which boots "grml".
Hm, how did you install grml? Inside a running system or from your
distribution?
I think the problem is that you have syslinux 4 and the files (vesamenu.c32)
on grml 2010.04 are for syslinux 3. (See http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=591480)
As a workaround you can try to install grml from a running grml instance. Or
try to install it to a directory, replace all the .c32 and isolinux.bin files
in /boot/isolinux with the files from /usr/lib/syslinux/ (debian package
syslinux-common) and run grml2usb from that directory.
The correct solution for grml2usb could be to overwrite existing modules on
the disk with the ones from the distribution. Unfortunately this only would
work for debian based distributions. Or we can just ignore it as this happens
rarely. But currently we have different isolinux versions in stable and
testing and they require different modules...
Thanks for your bugreport,
Ulrich
|
msg3322 (view) |
Author: dahlberg |
Date: 2010-08-12.09:27:14 |
|
If I install GRML 2010.04 to the second partition of an USB stick, using
GRML2USB 0.9.27 and boot it in a i386 machine, the following happens:
Syslinux gives error messages "vesamenu.c32: not a COM23R image" in regular
intervals. But at least there get a "boot: " prompt, which boots "grml".
If I try to boot "hdt" syslinux gives a similar error: "/boot/addons/hdt.c32:
not a COM32R image". The same is true for "bsd", while "dos" boots for some
reason.
Strangely, the F1..F10 keys are not working (no error message) either, until I
enter "help".
Not much information but if you may tell me how to provide more, I'll do.
|
|
Date |
User |
Action |
Args |
2010-09-28 22:16:09 | mika | set | status: fixed-in-git -> resolved messages:
+ msg3365 |
2010-08-18 13:36:12 | mru | set | status: chatting -> fixed-in-git messages:
+ msg3332 |
2010-08-12 14:34:48 | dahlberg | set | messages:
+ msg3330 |
2010-08-12 13:44:11 | mru | set | messages:
+ msg3328 |
2010-08-12 13:13:31 | dahlberg | set | messages:
+ msg3327 |
2010-08-12 12:33:27 | mru | set | status: unread -> chatting messages:
+ msg3323 |
2010-08-12 09:27:15 | dahlberg | create | |
|