gujin-users

Re: [Gujin-users] Multiboot USB keys with ISO images

[Adrien C. <adr...@gl...>]

Le 28/04/2014 13:31, eti...@gu... a écrit :
> I would say the status of that feature is complete inside Gujin.
> At the point where the Linux system wants to mount the root filesystem,
> Gujin has long gone. Gujin has left some memory bytes for the Linux
> system describing which file to mount (-o loop) as root, but the script
> to mount that *.iso file as root needs to be modified inside the ISO itself.
> Such modification has already been written as a patch, for instance
> google "gujin casper" or see:
> https://code.launchpad.net/~etienne-lorrain/casper/gujin
> But no user seem to be even remotely interrested, not even a single
> comment, so nobody want to spend time to merge the patch.
Too bad… It's such a shame not to have a working multiboot solution.

> If you select something else than "El-Torito" booting, i.e. Gujin trying
> to find by himself the Linux kernel and initrd (by their name, at run time
> "mounting" the *.iso file), Gujin will try to recognise the distribution
> and try to guess which "bootfrom=", "isofrom=", "fromiso=" ... parameter
> to give at the Linux command line, and that may succeed.
> The Linux command line is only available if you bypass El-Torito boot,
> because El-Torito has no "parameter" you can set to be forwarded to Linux.
>
Thanks for the explanation. I've managed to found this, but it's better
to hear it from you.

> To boot El-Torito, Gujin needs to leave a TSR (Terminate and Stay Resident)
> to simulate a BIOS disk, and the address of that TSR memory (the code itself)
> is a bit difficult to get right. If you want to know more, have a look at EBDA
> memory format for what should work, Gujin is not using that because I did
> not get it to work on my PC.
OK, I'll leave it for now. It's just about one kind of PC we have, so it
is not that important.

> Sorry for the late answer, I did not see very quickly your mail...
The answer was not so late, since I'm not working on week-ends ;) And it
is lengthy enough. Thank you.

Adrien

Re: [Gujin-users] Multiboot USB keys with ISO images

[<eti...@gu...>]

On 25 Apr 2014 at 13:14, Adrien CLERC wrote:
> Hi,
> First of all: many thanks for Gujin. I'm looking for a solution for a
> multiboot USB key, using ISO image, and none of them are perfect, since
> they just want to extract the files within the ISO, and get rid of the
> syslinux configuration.

 Hi Adrien,

Yes, extracting files from the ISO image to boot, and have a single
"root" to mount whatever the ISO selected  is not a clean solution.

> Many tutorial on the Web explains how to use Gujin and ISO files: create
> one unformatted partition for each ISO file, and use cat (or dd). I'm
> quite OK with that, but I've read that Gujin is able to boot from an ISO
> even if it is a file on formatted partition. What is the status of that
> features? I've tried it, but it doesn't go far: using ElTorito booting,
> the underlying system is unable to find its own root partition, and
> fails. I've tried so far Clonezilla and GParted live cds.

I would say the status of that feature is complete inside Gujin.
At the point where the Linux system wants to mount the root filesystem,
Gujin has long gone. Gujin has left some memory bytes for the Linux
system describing which file to mount (-o loop) as root, but the script
to mount that *.iso file as root needs to be modified inside the ISO itself.
Such modification has already been written as a patch, for instance
google "gujin casper" or see:
https://code.launchpad.net/~etienne-lorrain/casper/gujin
But no user seem to be even remotely interrested, not even a single
comment, so nobody want to spend time to merge the patch.

If you select something else than "El-Torito" booting, i.e. Gujin trying
to find by himself the Linux kernel and initrd (by their name, at run time
"mounting" the *.iso file), Gujin will try to recognise the distribution
and try to guess which "bootfrom=", "isofrom=", "fromiso=" ... parameter
to give at the Linux command line, and that may succeed.
The Linux command line is only available if you bypass El-Torito boot,
because El-Torito has no "parameter" you can set to be forwarded to Linux.

> I also have a PC (Fujitsu) that have a strange behavior. Gujin boots
> fine, but when choosing an ElTorito image (which relies on its own
> partition, copied with cat), the PC outputs "Machine check error" and
> reboot. This setup works fine in qemu and on other laptops I have here.
> Do you know what went wrong?

To boot El-Torito, Gujin needs to leave a TSR (Terminate and Stay Resident)
to simulate a BIOS disk, and the address of that TSR memory (the code itself)
is a bit difficult to get right. If you want to know more, have a look at EBDA
memory format for what should work, Gujin is not using that because I did
not get it to work on my PC.

> Thanks for your answer,
> 
> Adrien

Sorry for the late answer, I did not see very quickly your mail...

Cheers,
Etienne.

[Gujin-users] Multiboot USB keys with ISO images

[Adrien C. <adr...@gl...>]

Hi,

First of all: many thanks for Gujin. I'm looking for a solution for a
multiboot USB key, using ISO image, and none of them are perfect, since
they just want to extract the files within the ISO, and get rid of the
syslinux configuration.

Many tutorial on the Web explains how to use Gujin and ISO files: create
one unformatted partition for each ISO file, and use cat (or dd). I'm
quite OK with that, but I've read that Gujin is able to boot from an ISO
even if it is a file on formatted partition. What is the status of that
features? I've tried it, but it doesn't go far: using ElTorito booting,
the underlying system is unable to find its own root partition, and
fails. I've tried so far Clonezilla and GParted live cds.

I also have a PC (Fujitsu) that have a strange behavior. Gujin boots
fine, but when choosing an ElTorito image (which relies on its own
partition, copied with cat), the PC outputs "Machine check error" and
reboot. This setup works fine in qemu and on other laptops I have here.
Do you know what went wrong?

Thanks for your answer,

Adrien

Re: [Gujin-users] 2.8.7 and gpt disk

[Richard K. <rk...@ya...>]

--------------------------------------------
On Mon, 1/20/14, Etienne Lorrain wrote:

 Subject: Re: [Gujin-users] 2.8.7 and gpt disk
 To: guj...@li...
 Date: Monday, January 20, 2014, 7:00 AM
 
 On 18 Jan 2014 at 2:26, Richard
 Kweskin wrote:
 > ...
 >  Found valid GPT with protective MBR; using GPT.
 >  Disk /dev/sda: 40020624 sectors, 19.1 GiB
 >  Logical sector size: 512 bytes
 >  Disk identifier (GUID):
 >  5FE3AAB4-1A4E-47D1-9803-71753AD9B7F2
 >  Partition table holds up to 128 entries
 >  First usable sector is 34, last usable sector is
 40020590
 >  Partitions will be aligned on 2-sector
 boundaries
 >  Total free space is 0 sectors (0 bytes)
 >
 >  Number  Start    End   
       Size         Code  Name
 >     1          34     
 2047       1007.0 KiB  EF02  BIOS boot
 partition
 >     2         2048 
  8390655      4.0 GiB     8200 
 Linux swap
 >     3      8390656 
 40020590   15.1 GiB   8300  64bitisos
--------------------------------------------------------------------------------------------------------------- 
 Seem to be a small bug there, the first partition size
 should be 1006.5 Kb,
 ((2047-34) * 512), the first "1" dropped...
---------------------------------------------------------------------------------------------------------------

Sorry, my mistake in copy/paste. I fixed it above, now.
---------------------------------------------------------------------------------------------------------------
 
 > ...
 > Because I had installed a minimal Debian Jessie 64amd
 without any
 > bootloader and rebooted using a Gujin cd and added
 Gujin to this disk
 > using dpkg -i gujin_2.8.7_amd64.deb it left Gujin in
 partition 1. With
 > a new partition 3 I formatted and again installed a
 minimal Debian
 > Jessie 64amd without any bootloader.
---------------------------------------------------------------------------------------------------------------- 
 Gujin can be installed on a 1000 Kbytes partition, no
 problem.
----------------------------------------------------------------------------------------------------------------
Yes, I see. What is new here (to me) is that partition 1 is without format.
It seems it plays the role that the mbr was playing in the older format.
---------------------------------------------------------------------------------------------------------------- 
 You just also confirmed that Gujin handle GPT partitions
 containing
 ISO images, I did not expect any bug there but did not try
 myself.
----------------------------------------------------------------------------------------------------------------
The other interesting part was that the "problem" of the wrong UUID
is no longer troubling. It now finds the kernel and the file system
of the minimal install (not any iso, yet) of Debian just with the simple press
of the F1-key.
---------------------------------------------------------------------------------------------------------------- 
 I think I have not been complete in my explanations and I
 would like to
 add something:
 Gujin can, if asked to in its options, look inside the /BOOT
 directory of the
 ISOFS filesystem inside a *.iso regular file.
 That means Gujin can start *some* CD/DVD-ROM images files
 inside
 a filesystem, *if* it finds the kernel and initrd (they have
 to be regular
 names inside a /BOOT directory) and they have to have a
 "magic"
 Linux kernel option like "fromiso=".
 So, some distributions will work, some other will not work
 when you copy
 the *.iso file in your /boot partition.
 You can recognise this way of booting because Gujin will
 display in its
 menu something like:
 EBIOS disk 0x80 part 3
 /boot/distribution.iso:/BOOT/VMLINUZ,INITRD
 instead of something like:
 EBIOS disk 0x80 part 3 /boot/distribution.iso:El-Torito
 
 Cheers, Etienne.
-----------------------------------------------------------------------------------------------------------
Thank you again for your help.

Richard

Re: [Gujin-users] 2.8.7 and gpt disk

[<eti...@gu...>]

On 18 Jan 2014 at 2:26, Richard Kweskin wrote:
> ...
>  Found valid GPT with protective MBR; using GPT.
>  Disk /dev/sda: 40020624 sectors, 19.1 GiB
>  Logical sector size: 512 bytes
>  Disk identifier (GUID):
>  5FE3AAB4-1A4E-47D1-9803-71753AD9B7F2
>  Partition table holds up to 128 entries
>  First usable sector is 34, last usable sector is 40020590
>  Partitions will be aligned on 2-sector boundaries
>  Total free space is 0 sectors (0 bytes)
>  
>  Number  Start    End          Size         Code  Name
>     1          34      2047       007.0 KiB  EF02  BIOS boot partition
>     2         2048   8390655      4.0 GiB     8200  Linux swap
>     3      8390656  40020590   15.1 GiB   8300  64bitisos

Seem to be a small bug there, the first partition size should be 1006.5 Kb,
((2047-34) * 512), the first "1" dropped...

> ...
> Because I had installed a minimal Debian Jessie 64amd without any
> bootloader and rebooted using a Gujin cd and added Gujin to this disk
> using dpkg -i gujin_2.8.7_amd64.deb it left Gujin in partition 1. With
> a new partition 3 I formatted and again installed a minimal Debian
> Jessie 64amd without any bootloader.

Gujin can be installed on a 1000 Kbytes partition, no problem.

>  Be well, all of you!!
>  
>  Richard Kweskin
>  Athens, Greece

You just also confirmed that Gujin handle GPT partitions containing
ISO images, I did not expect any bug there but did not try myself.

I think I have not been complete in my explanations and I would like to
add something:
Gujin can, if asked to in its options, look inside the /BOOT directory of the
ISOFS filesystem inside a *.iso regular file.
That means Gujin can start *some* CD/DVD-ROM images files inside
a filesystem, *if* it finds the kernel and initrd (they have to be regular
names inside a /BOOT directory) and they have to have a "magic"
Linux kernel option like "fromiso=".
So, some distributions will work, some other will not work when you copy
the *.iso file in your /boot partition.
You can recognise this way of booting because Gujin will display in its
menu something like:
EBIOS disk 0x80 part 3 /boot/distribution.iso:/BOOT/VMLINUZ,INITRD
instead of something like:
EBIOS disk 0x80 part 3 /boot/distribution.iso:El-Torito

Cheers, Etienne.

Re: [Gujin-users] 2.8.7 and gpt disk

[Richard K. <rk...@ya...>]

I have a further interesting development.

To recap, the disk used was a normal ide internal 20 GB disk.
It was not a usb flash disk.

In my ignorance I had assumed that I could create one large
partition and put many iso images and use Gujin to boot them.

This was the setup I used then:

 GPT fdisk (gdisk) version 0.8.8

 Partition table scan:
   MBR: protective
   BSD: not present
   APM: not present
   GPT: present
 
 Found valid GPT with protective MBR; using GPT.
 Disk /dev/sda: 40020624 sectors, 19.1 GiB
 Logical sector size: 512 bytes
 Disk identifier (GUID):
 5FE3AAB4-1A4E-47D1-9803-71753AD9B7F2
 Partition table holds up to 128 entries
 First usable sector is 34, last usable sector is 40020590
 Partitions will be aligned on 2-sector boundaries
 Total free space is 0 sectors (0 bytes)
 
 Number  Start    End          Size         Code  Name
    1          34      2047       007.0 KiB  EF02  BIOS boot partition
    2         2048   8390655      4.0 GiB     8200  Linux swap
    3      8390656  40020590   15.1 GiB   8300  64bitisos

Once I understood that this won't work I removed the large partition
3 and created two smaller ones (3 and 4) and still left plenty of space
for more.

Ok, so far this is normal and not interesting. However, the following
is interesting:

Because I had installed a minimal Debian Jessie 64amd without any
bootloader and rebooted using a Gujin cd and added Gujin to this disk
using dpkg -i gujin_2.8.7_amd64.deb it left Gujin in partition 1. With
a new partition 3 I formatted and again installed a minimal Debian
Jessie 64amd without any bootloader.

It was not necessary to use a Gujin cd to boot this since the previous
Gujin left in partition 1 went into action and found the kernel and so
the system started normally.

Another interesting development was that this did not need the intervention
of Ctrl-key + F1. No, I had not followed the steps of using End-key to save
any change to how Gujin was looking for the kernel in partition 3.

 
 Be well, all of you!!
 
 Richard Kweskin
 Athens, Greece

Re: [Gujin-users] 2.8.7 and gpt disk

[Richard K. <rk...@ya...>]

On Tue, 1/7/14, Etienne Lorrain wrote:
 
> So basically you can delete the ef02 partition, it will not
> be used.
> And anyway GPT partitions usually start at 2048, so keep it
> that way.
> So, because your USB key is booting without any other
> device,
> you have on the root partition (named 64bitisos) the two
> files
> "/boot/gujin.ebios" and "/boot/gujin.cmd".

I didn't know that. Thank you.
 
> So Gujin will propose you to boot either Debian Jessie or
> any of the *.iso
> files that Gujin will find (Gujin looks in the root
> filesystem and in /boot
> directory).
> Note the usual warning about booting an *.iso file: it does
> work, Gujin
> will pass control to the bootloader of the *.iso file
> (called the El-Torito
> bootloader, usually isolinux) and that bootloader will load
> the Linux
> kernel (or any other kernel) and run it successfully.
> Then that Linux kernel will want to find it's own filesystem
> on a physical
> CD/DVD-ROM or in some cases on a complete partition, but
> will not probe
> every *.iso files accessible to see if it is the right one.
> Some Linux installation *.iso image (for instance Debian
> install disks)
> do not need their "own filesystem" so they work with Gujin
> as you expect,
> but most *iso do not (they fail to run at this last stage).
> It is not possible for Gujin to tell ISOLINUX to add
> parameters to the Linux
> command line so that it knows which *.iso file to use, no
> such interface exists.

I did notice that iso's were failing at the last stage as you describe.
Thank you for clearing that up for me.

> What people have tried and used sucessfully is to copy the
> *.iso file
> in a partition and not have it as a file: create multiple
> partitions with
> a size bigger than your CD/DVD-ROM, for instance:
> - one Debian Jessie partition, where you can also add Debian
> installation
> netinstall cdrom
> - one swap if needed (for suspend to disk)
> - one Knoppix 5 Gb partition
> - one <insert a distribution name> 1 Gb partition
> - ... as many as you want.
> Even using GPT partitions, that is probably working without
> problem.

So that is the secret! Thank you.
 
> To be able to really boot *.iso files as you want to, a
> change has to be done
> in the initialisation scripts of the distribution itself: if
> no physical CD/DVD-ROM
> is found, if no partition is found, then use the information
> Gujin leaves
> (after INT13 vector) to get the right *.iso file to mount as
> root instead of
> crashing or running busybox.
> The patch do exist: I did even create a branch with all the
> stuff there:
> https://code.launchpad.net/~etienne-lorrain/casper/gujin
> It does work for me, but nobody did express any interest of
> supporting
> it or even testing it - so I did not push. It is true that
> this solution only
> works for Gujin (I still think it is better than crashing
> but...).

I will look at this also.
 
> I do not really like UUID but you can use them on Gujin
> default command
> line or file /boot/gujin.cmd, but I have nothing against
> GPT.

I prefer label myself.

> Not exactly, once you pressed the Shift-Fn you can manually
> change
> but that is not saved, what is saved locally is when you go
> to the end
> of Gujin menu (pressing space when Gujin is running and then
> the End
> key) you can edit the default command line with one of the
> options,
> and another option is to enable "write to disks".
> Alternatively you can edit /boot/gujin.cmd under Linux, I
> hope the syntax
> is simple enough.
>
> Etienne.

This, also, I did not know. You have helped me over several
difficulties with this mail. I am truly grateful that you have taken
so much time and have been so patient in explaining my many
mistakes!!

Once I have completed it all successfully I will report back to
this list.

Richard

Re: [Gujin-users] 2.8.7 and gpt disk

[<eti...@gu...>]

On 6 Jan 2014 at 14:56, Richard Kweskin wrote:
> I apologise for the confusion. I only mentioned that the
> partition type ef02 can be used by bootloaders such as Grub.
> In fact I installed Debian Jessie without any bootloader, leaving
> partion 1 without any code in it and without it being formatted at
> all.

So basically you can delete the ef02 partition, it will not be used.
And anyway GPT partitions usually start at 2048, so keep it that way.
So, because your USB key is booting without any other device,
you have on the root partition (named 64bitisos) the two files
"/boot/gujin.ebios" and "/boot/gujin.cmd".

> My plan is to put many iso files in the / folder in partition 3 together with
> the minimal Debian Jessie. This is why I decided not to install
> another bootloader, only Gujin.

So Gujin will propose you to boot either Debian Jessie or any of the *.iso
files that Gujin will find (Gujin looks in the root filesystem and in /boot
directory).
Note the usual warning about booting an *.iso file: it does work, Gujin
will pass control to the bootloader of the *.iso file (called the El-Torito
bootloader, usually isolinux) and that bootloader will load the Linux
kernel (or any other kernel) and run it successfully.
Then that Linux kernel will want to find it's own filesystem on a physical
CD/DVD-ROM or in some cases on a complete partition, but will not probe
every *.iso files accessible to see if it is the right one.
Some Linux installation *.iso image (for instance Debian install disks)
do not need their "own filesystem" so they work with Gujin as you expect,
but most *iso do not (they fail to run at this last stage).
It is not possible for Gujin to tell ISOLINUX to add parameters to the Linux
command line so that it knows which *.iso file to use, no such interface exists.

What people have tried and used sucessfully is to copy the *.iso file
in a partition and not have it as a file: create multiple partitions with
a size bigger than your CD/DVD-ROM, for instance:
- one Debian Jessie partition, where you can also add Debian installation
netinstall cdrom
- one swap if needed (for suspend to disk)
- one Knoppix 5 Gb partition
- one <insert a distribution name> 1 Gb partition
- ... as many as you want.
Even using GPT partitions, that is probably working without problem.

To be able to really boot *.iso files as you want to, a change has to be done
in the initialisation scripts of the distribution itself: if no physical CD/DVD-ROM
is found, if no partition is found, then use the information Gujin leaves
(after INT13 vector) to get the right *.iso file to mount as root instead of
crashing or running busybox.
The patch do exist: I did even create a branch with all the stuff there:
https://code.launchpad.net/~etienne-lorrain/casper/gujin
It does work for me, but nobody did express any interest of supporting
it or even testing it - so I did not push. It is true that this solution only
works for Gujin (I still think it is better than crashing but...).

> As it was the first time I tried to install Gujin on a gpt disk it was
> a happy surprise for me to see that it was able to boot the kernel.
> Since you have explained that you never intended Gujin to use
> the uuid of any partition I am not sure why it appeared at all.

I do not really like UUID but you can use them on Gujin default command
line or file /boot/gujin.cmd, but I have nothing against GPT.

> However, as you also explained that once I choose the F-key together
> with the shift-key and I change the parameter to /dev/sda3 I can save
> this, I will try it also.

Not exactly, once you pressed the Shift-Fn you can manually change
but that is not saved, what is saved locally is when you go to the end
of Gujin menu (pressing space when Gujin is running and then the End
key) you can edit the default command line with one of the options,
and another option is to enable "write to disks".
Alternatively you can edit /boot/gujin.cmd under Linux, I hope the syntax
is simple enough.

Etienne.

Re: [Gujin-users] 2.8.7 and gpt disk

[Richard K. <rk...@ya...>]

On Mon, 1/6/14, Etienne Lorrain wrote:

 Subject: Re: [Gujin-users] 2.8.7 and gpt disk
 Date: Monday, January 6, 2014, 5:15 AM

snip
 
> Hello Richard,
 
> I cannot answer where dpkg -i gujin*.deb did put the
> bootloader, depending on at which point 
> during the distribution install you executed the Gujin
> installation.

After the install without the boot loader I then rebooted
with a cd containing Gujin. Once it successfully arrived
at command line I then installed the deb binary for Gujin.

> You can find where it is, by looking for "/boot/gujin.ebios"
> file, anyway I assume it does work
> because you say you are booting.
> With GPT, usually the first sector used in the first
> partition is 2048,

Yes. I use gdisk to first put partitions 2 and 3. Then since all
sectors after 2047 are then "taken", I put the partition 1 last
and gdisk then puts it at sector 34. Since this partition is never
formatted and is used in a computer which does not have uefi
I then set partition 1 to type ef02 which allows bootloaders like
grub to put their code. It was an experiment for me to see if
Gujin was happy with this same arrangement and am very pleased
to be able to thank you by saying it works fine.

> and it is also possible
> to put Gujin on a 1.44 Mbytes floppy image not described in
> the partition table in this empty 
> space - just saying that because you name /dev/sda3
> "64bitisos" so you seem to want to play
> with ISO images.

I am not sure if I understand what you are saying here. Is it that you
suggest that instead of using a ready binary Debian package of
Gujin that there is also a floppy image that can be put in partition 1?

I imagine that dd could do this (if I knew the correct parameters,
which I do not) in spite of the partition not being formatted. I used
the ready deb binary because it required the least amount of knowledge
on my part. :))

> Gujin do not really use UUID, it will try to automatically
> give the /dev/sd* of the kernel file it
> is loading as a command line "root=", unless that partition
> is too small then it takes the next 
> partition. I had too many problems with UUID while trying to
> rescue failing HD and copying
> that failing HD to another HD bytes per bytes (so
> conflicting UUID in a system); myself I 
> better like to use partition labels which can be changed.
 
> Anyway you can disable Gujin root autodetection by providing
> a "root=" argument to the
> file "/boot/gujin.cmd" - and there you can use UUID, or you
> can change the embedded
> command line in Gujin menu (while Gujin is active) - just do
> allow Gujin to write to disks
> so that the latter change is saved for next reboot.
 
> Hopes it solves your problem,
> Cheers, Etienne.
 
Thank you again, Etienne, for your prompt reply and all your good work!!

Richard

Re: [Gujin-users] 2.8.7 and gpt disk

[<eti...@gu...>]

On 2 Jan 2014 at 5:22, Richard Kweskin wrote:
> I used Rod Smith's GPT fdisk (or gdisk for short) on an old 20 GB ide disk and created three partitions:
> ...
> Number  Start (sector)    End (sector)  Size       Code  Name
>    1              34            2047   1007.0 KiB  EF02  BIOS boot partition
>    2            2048         8390655   4.0 GiB     8200  Linux swap
>    3         8390656        40020590   15.1 GiB    8300  64bitisos
> 
> I then installed a minimal Debian Jessie 64amd without any bootloader and did a dpkg -i gujin_2.8.7_amd64.deb
> which puts the gujin code in the mbr (I suppose it was put in /dev/sda1 which I left raw, i.e. not formatted.)
> In any case the disk boots into gujin as I hoped and the kernel is found, but (and here is the reason I am
> writing all this here) it wants to use a uuid which is not matching the partition where I installed the system
> (nor does it match that of the swap partition.) Fortunately, with shift-F1 I replace the uuid with /dev/sda3 and all is well.
> 
> Ok, it boots, but if anyone can shed light on why or what can one do to get it to use either the correct uuid or (failing that) /dev/sda3.............
> 
> Be well, all of you!!
> 
> Richard Kweskin
> Athens, Greece

Hello Richard,

I cannot answer where dpkg -i gujin*.deb did put the bootloader, depending on at which point 
during the distribution install you executed the Gujin installation.
You can find where it is, by looking for "/boot/gujin.ebios" file, anyway I assume it does work
because you say you are booting.
With GPT, usually the first sector used in the first partition is 2048, and it is also possible
to put Gujin on a 1.44 Mbytes floppy image not described in the partition table in this empty 
space - just saying that because you name /dev/sda3 "64bitisos" so you seem to want to play
with ISO images.

Gujin do not really use UUID, it will try to automatically give the /dev/sd* of the kernel file it
is loading as a command line "root=", unless that partition is too small then it takes the next 
partition. I had too many problems with UUID while trying to rescue failing HD and copying
that failing HD to another HD bytes per bytes (so conflicting UUID in a system); myself I 
better like to use partition labels which can be changed.

Anyway you can disable Gujin root autodetection by providing a "root=" argument to the
file "/boot/gujin.cmd" - and there you can use UUID, or you can change the embedded
command line in Gujin menu (while Gujin is active) - just do allow Gujin to write to disks
so that the latter change is saved for next reboot.

Hopes it solves your problem,
Cheers, Etienne.

[Gujin-users] 2.8.7 and gpt disk

[Richard K. <rk...@ya...>]

I used Rod Smith's GPT fdisk (or gdisk for short) on an old 20 GB ide disk and created three partitions:

root@debianisos:~# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 40020624 sectors, 19.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 5FE3AAB4-1A4E-47D1-9803-71753AD9B7F2
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 40020590
Partitions will be aligned on 2-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34            2047   1007.0 KiB  EF02  BIOS boot partition
   2            2048         8390655   4.0 GiB     8200  Linux swap
   3         8390656        40020590   15.1 GiB    8300  64bitisos

I then installed a minimal Debian Jessie 64amd without any bootloader and did a dpkg -i gujin_2.8.7_amd64.deb which puts the gujin code in the mbr (I suppose it was put in /dev/sda1 which I left raw, i.e. not formatted.) In any case the disk boots into gujin as I hoped and the kernel is found, but (and here is the reason I am writing all this here) it wants to use a uuid which is not matching the partition where I installed the system (nor does it match that of the swap partition.) Fortunately, with shift-F1 I replace the uuid with /dev/sda3 and all is well.

Ok, it boots, but if anyone can shed light on why or what can one do to get it to use either the correct uuid or (failing that) /dev/sda3.............

Be well, all of you!!

Richard Kweskin
Athens, Greece

Re: [Gujin-users] report option with non drive images

[<eti...@gu...>]

On 20 Nov 2012 at 19:21, Jörg Jenderek wrote:
> the ' --report' option of the installer should display info about the 
> mentioned device.
> That procedure seems to work also on floppy images like
> "boot2048" or "fdimg".
> I used gujin to produce some example files *.bcd and *.pic.
> when i try "./gujin --verbose --report " on that files the program 
> recognised nothing and the last error message is
> " (Not a Gujin bootloader?)" . I think a program should not be in doubt 
> about a file type it has produced itself.

Just a response to this part of the message, please read "note 1" of the
manual of Gujin, "man 8 gujin".
./gujin --report <param>
consider <param> being a device if it is bigger than 640 Kb (so 720 Kb floppy
do qualify) or consider being the bootloader file of a device if not (so will
analyse the container device).

Regards,
Etienne.

Re: [Gujin-users] automatic selection keyboard via LANGuage not on SUSE system

[<eti...@gu...>]

Hello Jörg,

> When i try to use  a command like "LANG=de ./gujin -w"  

LANG defines the display language used, but it is not always possible to deduce the 
keyboard used from that...

> Instead information about keyboard type is stored in the file /etc/sysconfig/keyboard with content like:

I am not a Suse user, but I made a patch to my development version to support that.

I do not really have a lot of contributions on Gujin so do not maintain an external repository 
system, and I like to read twice (or more) the total patch before releasing a new version,
but I could probably send the total patch / a temporary executable if you need.

> Hope my annotations can be applied in newer versions of gujin.

It is already in my development version.

>From your previous messages:

> I used gujin to produce some example files *.bcd and *.pic.
> when i try "./gujin --verbose --report " on that files the program
> recognised nothing and the last error message is " (Not a Gujin bootloader?)" .

It is because in most cases "./gujin --report filename" reports data about the bootloader of the 
disk which contains the filename given, and if that Gujin bootloader will load the file specified
(or if that file is not related, whatever its name).
I made a patch to display that "./gujin --report" loads the first sector of the disk.

> The Program should recognise that the stage1 boot loader is there and display
> the contained information and mention that stage 2 boot loader is missing.

I still did not do anything about it, still need to decide.

>  "set time offset" by pressing  my "+" or "-" key,

I need also more time to find a simple way to display keyboard, or have a default keyboard
linked to the language, or something else.

> i try to identify gujin boot loader files (especially in a form suited for the file command).

Could you explain why you are trying to do that, a bit of context?
Some Gujin file are difficult to recognise (mostly gujin.bcd) because Linux tools building
bootable ISO images will overwrite the first 64 bytes (search "Exact mapping of mkisofs"
in boot.c) and so the installer do not try to fill that region.
Also some HP BIOS recognise the hexadecimal values at offset 0xC in the MBR to decide
if the disk is bootable (they shall be those of Microsoft MBR)...

As I said I am a bit busy, but new Gujin version will come...
Etienne.

[Gujin-users] how do i identify gujin bootloader (magic pattern)

[Jörg J. <joe...@gm...>]

hello,
i try to identify gujin boot loader files (especially in a form suited for 
the file command).
Common for all version seems to be at offset 0 the assembler instruction 
JuMP (E9 yy zz  or EB yy NOP=0x90) (yy=0x3c,0x6f zz=0x0e) followed by 0x47 
"Gujin1" or 0x43 "CD", which lead to test expression:
ulelong&0xC961acEd=0x41002cE9
Another common token sequence i found at offset 384 with a range of 7
comma_msg,checksum_msg, which lead to a search string ",\ \0:\ ch",
because the content of checksum_msg differs from version to version
So if that string is followed by "ecksum\0\ ERROR!\0" it is version <1.1
and followed by "ksum\0\ ERROR!\0" it is version >1.0.
Then i try to find a way to get the version of the files. All seems to 
contains strings like "v0.7 (C) Etienne LORRAIN 2003" or "Gujin v2.8.6 (C) 
Etienne LORRAIN 2012" .  
The string part starting with copy-right sign is coded in boot.c after 
runloader2_endmsg label as assembler instruction instead as .ascii like in
runloader2_msg. So i had difficulties to find that entry.
I do not know if it a bug or feature.
Unfortunately that string occurs at different offsets. Especially for big 
USB stick images the string is found near the end. So is a pointer 
somewhere at the beginning stored with the address of the segment or 
similar for all versions.
Another approach to detect the version was the ".version" variable behind 
.magic=16980327 in structure gujin_param, but this seems to apply only for 
newer versions.
I also try to find a way to identify the type of loader. a good locations 
seem to be 0x036. For master boot records it contains "MBR    " and of 
course "FAT12   " for 12-bit DOS boot sectors and "FAT16   " for 16-bit 
DOS.
Unfortunately also .PCI and .SYS files contains the signature "FAT12".
As far as i known this 8 byte variable field_FAT16.FileSysName
contains ASCII characters not used for any calculation.
So it would be nice if the installer write something like "PIC-CODE" for 
.PCI files and "BOOT-XYZ" for .SYS files in that field

Could somebody verify my thoughts or give me more information concerning  
that point.

thanks
joerg
-- 
Jörg Jenderek	email:	joerg.jen.der.ek (at) gmx.net
Germany		PGP:	B9FE A356 283E 0048 6389  18BF AFF2 B1C9 421A D4D6

[Gujin-users] automatic selection keyboard via LANGuage not on SUSE system

[Jörg J. <joe...@gm...>]

hello,
the automatic selection of keyboard by LANGuage option does not work on 
SUSE system (11.4) .When i try to use  a command like "LANG=de ./gujin -w"  
i saw that the installer tries to open file /etc/default/keyboard with line 
like XKBLAYOUT="de". On a SUSE system this file does not exist.  Instead 
information about keyboard type is stored in the file 
/etc/sysconfig/keyboard with content like:
#
# Keyboard settings for the text console
#
# Keyboard mapping
# (/usr/share/kbd/keymaps/)
# e.g. KEYTABLE="de-latin1-nodeadkeys", "us" or empty for US settings
#
KEYTABLE="de-latin1-nodeadkeys.map.gz"
This configuration file is used by the kbd program during init process to 
switch the keyboard type.
So i create and edit file  /etc/default/keyboard manually and things works 
as expected.

Hope my annotations can be applied in newer versions of gujin.
thanks
joerg
-- 
Jörg Jenderek	email:	joerg.jen.der.ek (at) gmx.net
Germany		PGP:	B9FE A356 283E 0048 6389  18BF AFF2 B1C9 421A D4D6

Re: [Gujin-users] report option with non drive images

[<eti...@gu...>]

Sorry I noticed you two messages just today, I will try to reproduce the failure you describe - 
but it will take some time to fix (I am a bit busy at work and at home...)

Thanks, Etienne.

[Gujin-users] report option with non drive images

[Jörg J. <joe...@gm...>]

hello,
the ' --report' option of the installer should display info about the 
mentioned device.
That procedure seems to work also on floppy images like
"boot2048" or "fdimg".
I used gujin to produce some example files *.bcd and *.pic.
when i try "./gujin --verbose --report " on that files the program 
recognised nothing and the last error message is
" (Not a Gujin bootloader?)" . I think a program should not be in doubt 
about a file type it has produced itself.
i installed gujin on  a SD-card and it worked alright. Then i extracted and 
saved the mbr into a file by dd. When i run ""./gujin --verbose --report " 
on that *.mbr file nothing is found The Program should recognise that the 
stage1 boot loader is there and display the contained information and 
mention that stage 2 boot loader is missing.

Hope my annotations can be applied in newer versions of gujin.
thanks
joerg
-- 
Jörg Jenderek	email:	joerg.jen.der.ek (at) gmx.net
Germany		PGP:	B9FE A356 283E 0048 6389  18BF AFF2 B1C9 421A D4D6

[Gujin-users] language with non corresponding keyboard

[Jörg J. <joe...@gm...>]

hello,
when i use gujin for the first time i used ^T key sequences to
switch to my native language (German).

When i tried to "set time offset" by pressing  my "+" or "-" key,
nothing happens and gujin returns to the setup screen.
That was annoying.
At that moment the program should should jump to subroutine showing message
"unkown command (keycode 0xnnmm)" like in other wrongs key presses.
For normal PC users this information is nothing worth.
As i know 0xnn contains flags for which modifiers keys like shift, CRTL, 
ALT are pressed. The value of 0xmm seems to represents the ASCII value of 
the key. So it would be nice if an additional code sequence is there
expressed in the following example c coding like
	printf (" '%c'=0x%x" ,keycode[1],keycode[1])
Then a message like "unknown command (keycode=0xnnmm 'z'=0xmm)" 
gives the normal user a better feedback, what has happened.

Later i tried "change command line" and recognized that language is changed
to German but keyboard is obviously QWERTY. Then of course i used
menu entry "change keyboard type" to switch to german QWERTZ keyboard.
And keys works as expected.

So it would be nice if gujin would also show the active keyboard type
on the main screen nearby the "Lang" or "font" information. So that user
knows was is going on.

I would be nicer if guijn could chain the language with the corresponding
keyboard type. So when user switch from english to german language , also 
the keyboard type changes from QWERTY-uk to QWERTZ-de.

Hope my annotations can be applied in newer versions of gujin.
thanks
joerg
-- 
Jörg Jenderek	email:	joerg.jen.der.ek (at) gmx.net
Germany		PGP:	B9FE A356 283E 0048 6389  18BF AFF2 B1C9 421A D4D6

Re: [Gujin-users] (no subject)

[Etienne L. <eti...@gu...>]

Hello Pablo,

On Fri, 7 Jan 2011 18:06:24 +0100
Pablo <pa...@kl...> wrote:
> Hi there,
> 
> I'm going to make an usbstick with few iso's of my favorite LiveCD's.
> 
> Of course I need gujin to do it.
> 
> I made one small partition at the begging od stick (FAT16 - 16MB),
> nextly installed gujin:
> 
> sudo ./gujin-2.8.3/gujin /dev/sdb1 --mbr --disk=BIOS:0x80
> --cmdline="" \ --search_topdir_files=0 \
> --search_subdir_files=0 \
> --probe_file_in_iso_image=0 \
> --VGA_interface=1 \
> --VESA_interface=0 \
> --enable_VESA_hardwin=0 \
> --VESA2_interface=0 \
> --enable_joystick=0 \
> --probe_bios_floppy_disk=0 \
> --probe_cdrom=0 \
> 
> and put isos on the next few partitions with commands:
> 
> cat iso1 > /dev/sdb5
> cat iso2 > /dev/sdb6
> cat iso3 > /dev/sdb7
> 
> everything works great, I have now stick with Xen Livecd, backtrace
> and Xubuntu.
> 
> I would like to add to this stick iso of instalation disk with Windows
> XP, anybody know how to do it?
> 
> Standard way isn't working:
> gujin exits without errors, but nextly I see "Couldn't find NTLDR" and
> gujin restarts.
> 
> I suppose, that M$ made his install CD in diffrent way than other CDs.

I did not try myself, I am not installing Windows that often, but to
check if there is a problem with Gujin or if it is a problem with
the windows CD, you can try two things:
Fist, boot Gujin with your USB stick, then (and only then) insert the
real windows CD and reprobe all disks by typing Control-R.
You should see the choice to boot the CD, select it: does it work and
pass the "Couldn't find NTLDR"?
I am assuming you have a real CD drive, with a USB CD drive it may or
may not work.
If you can boot that way, there is no problem in the Gujin El-Torito
loader.
Then, boot Gujin with your USB stick, then (and only then) insert the
real windows CD - no need to reprobe. Then select to boot the partition
which contains the windows CDROM image.
If that way to boot works, it means something simple: the windows
loader bypass the El-Torito disk emulation as soon as possible and
directly access the CDROM using ATAPI commands.
Because Gujin just simulate a BIOS disk and cannot simulate a real
CDROM, that way to boot will not work (I think that is what happens
here).

Please report if I am wrong.

Regards,
Etienne.

[Gujin-users] (no subject)

[Pablo <pa...@kl...>]

Hi there,

I'm going to make an usbstick with few iso's of my favorite LiveCD's.

Of course I need gujin to do it.

I made one small partition at the begging od stick (FAT16 - 16MB),
nextly installed gujin:

sudo ./gujin-2.8.3/gujin /dev/sdb1 --mbr --disk=BIOS:0x80 --cmdline="" \
--search_topdir_files=0 \
--search_subdir_files=0 \
--probe_file_in_iso_image=0 \
--VGA_interface=1 \
--VESA_interface=0 \
--enable_VESA_hardwin=0 \
--VESA2_interface=0 \
--enable_joystick=0 \
--probe_bios_floppy_disk=0 \
--probe_cdrom=0 \

and put isos on the next few partitions with commands:

cat iso1 > /dev/sdb5
cat iso2 > /dev/sdb6
cat iso3 > /dev/sdb7

everything works great, I have now stick with Xen Livecd, backtrace and
Xubuntu.

I would like to add to this stick iso of instalation disk with Windows
XP, anybody know how to do it?

Standard way isn't working:
gujin exits without errors, but nextly I see "Couldn't find NTLDR" and
gujin restarts.

I suppose, that M$ made his install CD in diffrent way than other CDs.



-- 
Pablo
Linux/Debian user since "Potato".
XUbuntu 10.04, "Lucid Lynx" @ IBM/Lenovo Thinkpad X61s
Warsaw, Poland

[Gujin-users] You are welcomed to leave feedback on Gujin here, you will be read!

[Etienne L. <eti...@ya...>]

Hello to every Gujin user,

I am looking for feedback from users of Gujin, what is good, what is bad,
what can be improved...
I cannot guaranty to implement every request considering that Gujin is not
my real work, but I know sometimes anoying details can be fixed very
quickly - if they are not fixed it is probably because I am not aware of
them.
The messages excluded from this view are spam, I did not censor anybody.

Waiting to hear from you,
Cheers,
Etienne.


      

Re: [Gujin-users] Floppy disk boot loader.

[<eti...@gu...>]

> I'll try to find the file, it is in a seperate partition on the disk.
> The partition that the Unix image files are on is not the primary partit, and it is not marked as bootable.
> It doesn't show the file when I type 'dir c:/boot/vmlinuz' it returns file not found.

 If DOS cannot see the file (probably because your first partition is not FAT),
then tiny.exe will not work - it is small because it uses only DOS to access
the filesystem.
 You can try the full "boot.exe" which will analyse other filesystems like
ext2/3 usually present for Linux.
 The partition do not need to be primary nor to be marked as bootable.

>  The cat boot.144 to floppy did not work.  It returns: Error!

 That is usually due to bad sectors on the floppy, try to format it (umount
and mformat from mtools): if the format fails, you cannot write to the floppy
and you should try another floppy.
 Other reason may be that you are using the older 720 Kbytes floppy (only
one hole at the top of the floppy), or you are not using a real floppy - and your
BIOS do not map that floppy to BIOS disk number 0x00.
 The installer "instboot" will check what has been written if you try:
umount /dev/fd0
./instboot boot.bin /dev/fd0
 so it is safer than just a "cat boot.144 > /dev/fd0"
 If you are not using a real floppy, and the BIOS map that disk to number 0x80,
you can try:
./instboot boot.bin /dev/fd0 --disk=BIOS:0x80,auto

 Etienne.

Re: [Gujin-users] Floppy disk boot loader.

[<eti...@gu...>]

On 16 Feb 2009 at 0:59, jm...@tm... wrote:
> I am using this program which is supposed to be able to boot a Unix
> kernel image/OS on hard disc from a floppy disc.  I tried the
> instructions detailed for the install, creating a Dos boot disc, and
> adding files, then from the Dos prompt using Tiny.exe the location of
> the image vmlinuz and the ram disk image initrd.gz and the root device
> partition but the program cannot find the image files.  What files
> need to be added to the Dos boot disc in order to boot the Unix OS?

 Not knowing the exact error message does not help, but you may
have used too long filenames for the kernel and the initrd (Gujin/tiny.exe
could use more than 8+3 filenames but because DOS would refuse to
open those files with too long name it would not work anyway).
 Try renaming those file with 8+3 letters convention, and also check
you are using the latest version of Gujin/tiny.exe (at sourceforge.net)
 Gujin does not need more files than the bare DOS, i.e. if you have
a DOS prompt before running tiny.exe, it should work. Check that
you can see the kernel/initrd files by typing "dir".
 It would help to know which version of DOS you are using.
 Obviously the DOS operating system should be correctly installed so
that it is started, you can't just copy IO.SYS, MSDOS.SYS,
COMMAND.COM to a floppy to start DOS, you have to use format /S
from a DOS prompt - but that does not seem to be your problem.

 If you do not need DOS at all, I would advise you to try the direct
version of the bootloader: get file "boot.144" from sourceforge/gujin
in install.tar.gz and type in a shell:
su
umount /dev/fd0
cat boot.144 > /dev/fd0
 and reboot with this floppy disk inserted. It should work without
problem, as long as your floppy has no bad sectors.

 Etienne.

Re: [Gujin-users] Floppy disk boot loader.

[<eti...@gu...>]

On 16 Feb 2009 at 17:05, jm...@tm... wrote:
> The message is: Gujin1, gujin2++ go! V2.4 ERROR: file
> 'C:/boot/vmlinuz' does not exist. Exiting Gujin with error...

 Well, and if you do "dir C:\boot\vmlinuz", does it show the file?
Note that you have to use backslash as in the DOS world, and not slash
to separate directories in the pathname...

Etienne.

[Gujin-users] Floppy disk boot loader.

[<jm...@tm...>]

I am using this program which is supposed to be able to boot a Unix kernel image/OS on hard disc from a floppy disc.  I tried the instructions detailed for the install, creating a Dos boot disc, and adding files, then from the Dos prompt using Tiny.exe the location of the image vmlinuz and the ram disk image initrd.gz and the root device partition but the program cannot find the image files.  What files need to be added to the Dos boot disc in order to boot the Unix OS? 
Sent via BlackBerry from T-Mobile