Thread: [Gujin-users] 2.8.7 and gpt disk
Brought to you by:
etienne_lorrain
Menu
▾
▴
gujin-users
|
From: Richard K. <rk...@ya...> - 2014-01-02 13:22:09
|
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 |
|
From: <eti...@gu...> - 2014-01-06 10:32:57
|
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. |
|
From: Richard K. <rk...@ya...> - 2014-01-06 11:53:37
|
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 |
|
From: Richard K. <rk...@ya...> - 2014-01-18 10:29:30
|
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 |
|
From: <eti...@gu...> - 2014-01-20 12:00:32
|
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. |
|
From: Richard K. <rk...@ya...> - 2014-01-20 16:52:35
|
-------------------------------------------- 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 |
Thanks for helping keep SourceForge clean.
X