Hello,
I think I have figured out why this build refuses to boot in my system.
This is a very strange corner case.
1. Requirements to trigger the bug
1.1. First of all you need to have:
Either a brand-new HP 250 G6 at hand (e.g. no operating has been
installed despite what comes from HP itse
Hi,
adrian15 wrote:
> 2.1.1) The live cd media will be the first one to be found by the
> grub's search command. That's ok, that will work in most systems.
I always wondered why debian-cd and debian-live rely on file paths
with such low entropy. No individual distinction between versions is
reco
El 09/03/19 a las 13:46, Thomas Schmitt escribió:
>> 4) And, well, I might try an obvious patch that searches with regex both
>> /live/vmlinuz and /live/vmlinuz1 and give us more feedback about it.
>
> Or a dedicated unique identification file path ?
>
> An empty file in an alreay existing dir
Hi,
adrian15 wrote:
> Well, guess what happened... my obvious patch:
> if ! search --set=root --file /live/vmlinuz ; then
search --set=root --file /live/vmlinuz1
> does not boot in my computer because it's still finding /live/vmlinuz in
> the internal hard disk.
That's the second bad
El 09/03/19 a las 15:03, Thomas Schmitt escribió:
> Hi,
>
> adrian15 wrote:
>> Well, guess what happened... my obvious patch:
>> if ! search --set=root --file /live/vmlinuz ; then
>search --set=root --file /live/vmlinuz1
>> does not boot in my computer because it's still finding /live
El 09/03/19 a las 15:03, Thomas Schmitt escribió:
> Hi,
>
> adrian15 wrote:
>> Well, guess what happened... my obvious patch:
>> if ! search --set=root --file /live/vmlinuz ; then
>search --set=root --file /live/vmlinuz1
>> does not boot in my computer because it's still finding /live
I just wanted to write down that the label approach works for me.
This would be the patch/commit for this approach:
https://github.com/rescatux/live-build/commit/cf11816e64256d8028c4b2f10de2996de09328f2
replace:
search --set=root --file /live/vmlinuz
with:
search --set=root --label "${LB_ISO_
Hi,
adrian15 wrote:
> replace:
> search --set=root --file /live/vmlinuz
> with:
> search --set=root --label \"${LB_ISO_VOLUME}\"
This looks ok for me, as far as GRUB2's work is concerned.
But when the GNU/Linux comes up, it may again be necessary for software
in the initrd to locate the ISO file
El 09/03/19 a las 16:35, Thomas Schmitt escribió:
> Hi,
>
> adrian15 wrote:
>> replace:
>> search --set=root --file /live/vmlinuz
>> with:
>> search --set=root --label \"${LB_ISO_VOLUME}\"
>
> This looks ok for me, as far as GRUB2's work is concerned.
Yeah, it had TYPO but, yeah, as I said it wor
El 09/03/19 a las 15:03, Thomas Schmitt escribió:
> Hi,
>
> adrian15 wrote:
>> Well, guess what happened... my obvious patch:
>> if ! search --set=root --file /live/vmlinuz ; then
>search --set=root --file /live/vmlinuz1
>> does not boot in my computer because it's still finding /live
Hi,
adrian15 wrote:
> I think this is highly unlikely because when you build an image designed
> to be used in a hard disk you do not use mkisofs.
It's spelled x o r r i s o nowadays :))
There are use cases like Knoppix: An ISO partition, an EFI partition,
and a writable ReiserFS partition whi
11 matches
Mail list logo