Re: Booting GPT part table via BIOS, bootable flag required in protective MBR

[Juri Grabowski]

Hello Mike, 

it looks for me like a BIOS problem if it works on another machines. Can you 
look for BIOS Update for this laptop?
I have similar setups without such problems.
As a workaround you can use in class/

cat <<'EOF'>21-edu-board_name
#! /bin/bash
# assign classes to hosts based on their board_name
echo -n EDU_AUTO_BOARD_;egrep -o '^\w*' /sys/devices/virtual/dmi/id/board_name 
|tr 'a-z' 'A-Z'
exit 0
EOF

cat <<'EOF'>21-edu-product_name
#! /bin/bash
# assign classes to hosts based on their product_name
echo -n EDU_AUTO_PRODUCT_;egrep -o '^\w*' 
/sys/devices/virtual/dmi/id/product_name |tr 'a-z' 'A-Z'
exit 0
EOF

cat <<'EOF'>21-edu-sysvendor
#! /bin/bash
# assign classes to hosts based on their SYS VENDOR
echo -n EDU_AUTO_VENDOR_;egrep -o '^\w*' /sys/devices/virtual/dmi/id/sys_vendor 
|tr 'a-z' 'A-Z'
exit 0
EOF

cat <<'EOF'>85-auto_product_HP_
#! /bin/bash
ifclass EDU_AUTO_PRODUCT_HP_ && echo LVM_EDU_ROAMING_MBR
EOF

chmod +x 21-edu-board_name 21-edu-product_name 21-edu-sysvendor 
85-auto_product_HP_*

and define your disk_config LVM_EDU_ROAMING_MBR

Best Regards,
Juri Grabowski

Booting GPT part table via BIOS, bootable flag required in protective MBR

[Mike Gabriel via linux-fai]

Diese Nachricht wurde eingewickelt um DMARC-kompatibel zu sein. Die
eigentliche Nachricht steht dadurch in einem Anhang.

This message was wrapped to be DMARC compliant. The actual message
text is therefore in an attachment.--- Begin Message ---

Hi all, hi Thomas esp.,

for a school customer we set up a FAI environment recently and  
stumbled over a phenomenon that might required an adjust in FAI's  
partitioning tool.


We installed an HP notebook via BIOS mode using the partitioning rules  
given below. After FAI installation was successful, the notebook would  
not boot into the installed system. The notebook BIOS acted as if  
there was no system installed on the hard drive / SSD.


What fixed the problem was toggling the boot flag (i.e. enabling) on  
the first partition of the protective MBR (see at the very end of this  
mail).


The below data has been obtained from a VM installation. On the VM,  
the booting also works without above named bootable flag being set.


Is this something, we should amend in FAI's set-storage tool?

Mike



Our disk config we use is this:

```
disk_config  disk1  disklabel:gpt-bios bootable:1 fstabkey:uuid
primary  /boot/efi   512M vfatrw
primary  /boot   512M-2G  ext4rw
primary  -   0-   -   -

disk_config lvm
vg  vg_system  disk1.3
vg_system-root   /  2G-4G ext4  errors=remount-ro
vg_system-swap_1 swap   RAM:150%  swap  sw
vg_system-usr/usr   28G-36G   ext4  defaults
vg_system-var/var   8G-10Gext4  defaults
```

A resulting partition table for this config is this:

```
root@test-workstation:~# fdisk -l  /dev/vda
Disk /dev/vda: 64 GiB, 68719476736 bytes, 134217728 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D35E0D51-44FC-42A5-AA8E-6F6EF5F42837

Device   Start   End   Sectors  Size Type
/dev/vda1 4096   1052671   1048576  512M EFI System
/dev/vda2  1052672   5126858   4074187  1.9G Linux filesystem
/dev/vda3  5126859 134215646 129088788 61.6G Linux LVM
/dev/vda4 2048  4095  20481M BIOS boot

Partition table entries are not in disk order.
```

For the same partition table the format.log looks like this:

```
root@test-workstation:~# cat /tmp/fai/format.log
Starting setup-storage 2.3
Using config file: /var/lib/fai/config/disk_config/LVM_EDU_ROAMING
Executing: wipefs -af /dev/vda4
Executing: wipefs -af /dev/vda1
Executing: wipefs -af /dev/vda2
Executing: vgchange -a y vg_system
Executing: wipefs -a /dev/vg_system/swap_1
Executing: lvremove -f /dev/vg_system/swap_1
Executing: vgchange -a y vg_system
Executing: wipefs -a /dev/vg_system/var
Executing: lvremove -f /dev/vg_system/var
Executing: vgchange -a y vg_system
Executing: wipefs -a /dev/vg_system/home
Executing: lvremove -f /dev/vg_system/home
Executing: vgchange -a y vg_system
Executing: wipefs -a /dev/vg_system/usr
Executing: lvremove -f /dev/vg_system/usr
Executing: vgchange -a y vg_system
Executing: wipefs -a /dev/vg_system/root
Executing: lvremove -f /dev/vg_system/root
Executing: vgchange -a n vg_system
Executing: vgremove vg_system
Executing: pvremove  /dev/vda3
Executing: wipefs -af /dev/vda3
Executing: wipefs -af /dev/vda3
Executing: parted -s /dev/vda mklabel gpt
Executing: parted -s /dev/vda mkpart primary "fat32" 2097152B 538968063B
Executing: parted -s /dev/vda set 1 boot on
Executing: parted -s /dev/vda mkpart primary "ext3" 538968064B 2624951807B
Executing: parted -s /dev/vda mkpart primary "" 2624951808B 68718411263B
Executing: parted -s /dev/vda mkpart primary "" 1048576B 2097151B
Executing: parted -s /dev/vda set 4 bios_grub on
Executing: mkfs.vfat  /dev/vda1
Executing: mkfs.ext4  /dev/vda2
Executing: parted -s /dev/vda set 3 lvm on
Executing: parted /dev/vda set 1 boot on
Executing: pvcreate -ff -y  /dev/vda3
Executing: vgcreate  vg_system  /dev/vda3
Executing: vgchange -a y vg_system
Executing: lvcreate  --yes -n root -L 2615.39721762767 vg_system
Executing: mkfs.ext4  /dev/vg_system/root
Executing: lvcreate  --yes -n swap_1 -L 2973.955078125 vg_system
Executing: mkswap  /dev/vg_system/swap_1
Executing: lvcreate  --yes -n usr -L 30941.5888705107 vg_system
Executing: mkfs.ext4  /dev/vg_system/usr
Executing: lvcreate  --yes -n var -L 10807.3972176276 vg_system
Executing: mkfs.ext4  /dev/vg_system/var
Executing: lvcreate  --yes -n home -L 15062.9800340777 vg_system
Executing: mkfs.ext4  /dev/vg_system/home
/dev/vda2 UUID=3463e974-58a5-4195-97b3-91a63c348ca3
/dev/vda1 UUID=B803-DF11
/dev/vg_system/home UUID=67fe2d5a-06cf-4bb1-bded-59fcab454e95
/dev/vg_system/var UUID=476eca23-14c3-49d9-9a98-b32d2dc068f6
/dev/vg_system/swap_1 UUID=3af7d13f-6b7f-4676-afc0-24273ad45477
/dev/vg_system/root UUID=40eb465f-0de1-400f-8fe1-59506e5f563d
/dev/vg_system/usr UUID=14d51891-168e-4227-a925-6def80496da4

```

This fixes the boot problem with GPT-

Re: UEFI + Legacy BIOS TFTP/PXELINUX

[Thomas Lange]

Ok, I found a bug. My Thinkpad X230 does not work correctly using
UEFI. Using a Dell notebook shows, that my tftp, DHCP setup is correct
and loads ldlinux.e64 and then the pxelinux.cfg/. config files.

-- 
regards Thomas

Re: UEFI + Legacy BIOS TFTP/PXELINUX

[John G Heim]

Yeah, I'm sure. The syslinux-efi package works as advertized. I mean, 
you cannot boot an EFI machine via pxelinux.0. That would hang.


Are you saying that you're not seeing a request for ldlinux.e64 right 
after the request for syslinux.efi? There's no error message in the tftp 
logs? File not found, permission denied, something? I can't explain 
that. But after all, this isn't exactly an FAI problem. When I started 
experimenting with the syslinux-efi package, I set it up to boot into 
the ubuntu installer. In fact, that's how I made my base file for FAI 
installs of bionic. But fai isn't really involved up to this point. It 
has to be some kind of problem with tftp.


You can run a tftp client and get all the files you need during a pxe 
boot .On the server, I say, "tail -f /var/log/syslog | grep tftp" and 
then on the target machine (assuming linux is installed somehow), I run 
the tftp client and get the bootloader, either pxelinux.0 or 
syslinux.efi, the library file ldlinux.e64, and the config file. You 
ought to see the log entries scroll by on the fai server.






On 07/10/2018 06:02 AM, Thomas Lange wrote:

Hi John,

I didn't manage to get network booting using UEFI without grub but
with syslinux running. I copied the syslinux.efi and ldlinux.e64 into
my tftp directory. Using tcpdump I see that the UEFI is getting the
syslinux.efi file (even I use a different name and a symlink). I do
not see any request for the ldlinux.e64 file.

In your setup, are you really getting syslinux with UEFI use the
config from fai-chboot? Maybe your computer has still CSM (the legacy
mode) enabled, and you are still using pxelinux.

Re: UEFI + Legacy BIOS TFTP/PXELINUX

[Thomas Lange]

Hi John,

I didn't manage to get network booting using UEFI without grub but
with syslinux running. I copied the syslinux.efi and ldlinux.e64 into
my tftp directory. Using tcpdump I see that the UEFI is getting the
syslinux.efi file (even I use a different name and a symlink). I do
not see any request for the ldlinux.e64 file.

In your setup, are you really getting syslinux with UEFI use the
config from fai-chboot? Maybe your computer has still CSM (the legacy
mode) enabled, and you are still using pxelinux.

-- 
regards Thomas

Re: UEFI + Legacy BIOS TFTP/PXELINUX

[Rémy Dernat]

Hi,

Yes ! Thanks ! It works after modifying the file "60-misc" like described
by Thomas and this line :

```
primary /boot/efi 204800K vfat rw
```
to
```
primary /boot/efi 204800K vfat rw createopts="-s2 -F32"
```

Thank you very much.

Best regards,
Rémy.

Le lun. 9 juil. 2018 à 15:39, Thomas Lange 
a écrit :

> The current version of 60-misc now uses this
> code
>
> if [ -d /sys/firmware/efi ]; then
> echo GRUB_EFI
> elif ifclass -o I386 AMD64 ; then
> echo GRUB_PC
> fi
>
>
> --
> regards Thomas
>

Re: UEFI + Legacy BIOS TFTP/PXELINUX

[Thomas Lange]

The current version of 60-misc now uses this
code

if [ -d /sys/firmware/efi ]; then
echo GRUB_EFI
elif ifclass -o I386 AMD64 ; then
echo GRUB_PC
fi


-- 
regards Thomas

Re: UEFI + Legacy BIOS TFTP/PXELINUX

[Rémy Dernat]

Hi John, Toomas,

Thank you very much.

I changed my config to match your config, John, however, I still have an
error (which is a new one).

First of all, it boots fine (the first time), launching the install,
retrieving syslinux.efi, but it detects the class "GRUB_PC" instead of
"GRUB_EFI" (obviously, it should load GRUB_EFI !).

```
root@faiserv:/srv/fai/config# grep -r GRUB_PC .
./package_config/DEBIAN:PACKAGES install GRUB_PC
./package_config/UBUNTU:PACKAGES install GRUB_PC
./class/60-misc:ifclass -o GRUB_PC GRUB_EFI ||echo GRUB_PC

root@faiserv:/srv/fai/config# find . -name GRUB_PC
./scripts/GRUB_PC
./disk_config/GRUB_PC

root@faiserv:/srv/fai/config# grep -r GRUB_EFI .
./package_config/GRUB_EFI:PACKAGES aptitude GRUB_EFI
./package_config/DEBIAN:PACKAGES install GRUB_EFI
./package_config/UBUNTU:PACKAGES install GRUB_EFI
./class/60-misc:ifclass -o GRUB_PC GRUB_EFI ||echo GRUB_PC

root@faiserv:/srv/fai/config# find . -name GRUB_EFI
./package_config/GRUB_EFI
./scripts/GRUB_EFI
./disk_config/GRUB_EFI
```

I am a bit lost (...); I do not why it is loading GRUB_PC instead of
GRUB_EFI.

I also tried to switch to the DEMO class to check if it comes from my
defined class; I get the same result: it load also the GRUB_PC class.

My 60-misc class is :
```
cat class/60-misc
#! /bin/bash

ifclass -o CENTOS SLC && exit 0
if ifclass -o I386 AMD64 ; then
ifclass -o GRUB_PC GRUB_EFI ||echo GRUB_PC
fi
```

Best regards,
Rémy.


Le ven. 6 juil. 2018 à 17:14, John G Heim  a écrit :

> Sorry to reply to your posts out of order but I would not follow the
> advice in that message. It is at least out dated. You do not have to
> change your dhcp config after each install and you can continue to use
> your fai-chboot config files.  Syslinux does support EFI booting. It's
> in the syslinux-efi package.
>
> Here is the code in my dhcp config file that sets the filename option
> depending on EFI/BIOS boot:
>
> === begin ===
> # tell a kernel how to boot via PXE or NFS
> server-name faiserver;
> next-server faiserver;
> # Check pxe boot code #93 to determine whether we are booting via BIOS
> or EFI
> # 2018-07-04: jheim
> option architecture-type code 93 = unsigned integer 16;
> class "pxeclients" {
> match if substring (option vendor-class-identifier, 0, 9) =
> "PXEClient";
> if option architecture-type = 00:00 {
> filename "fai/pxelinux.0";
> } else {
> filename "fai/syslinux.efi64";
> }
> }
> === end ===
>
> The file syslinux.efi64 is from the debian syslinux-efi package. It's
> original name/path was /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi. I
> renamed it syslinux.efi64 to distinguish it from the 32-bit syslinux.efi
> file. Then I decided not to bother with 32-bit EFI boots. You also need
> some libs in your tftp directory to support EFI booting via syslinux. I
> think if you modify your dhcp config as abobe, copy the necessary files
> from the syslinux-efi package to your tftp space, you'll successfully
> boot into the FAI install. You will also need to create new disk config
> files to partition via gpt instead of msdos. (More on that below.)
>
> 1. Cut/passte above code into your dhcp config.
> 2. apt-get install syslinux-efi
> 3a. cp /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi /srv/tftp/fai/
> 3b. cp /usr/lib/syslinux/modules/efi64/ldlinux.e64 /srv/tftp/fai/
>
> Done with the boot stuff. Now the disk config stuff.  Code that detects
> whether you have booted via BIOS or EFI already exists in the fai-doc
> examples. It's in a class script called 60-grub. It creates either
> GRUB_PC or GRUB_EFI class. You have to retain your old BIOS disk config
> files for older machines. I used to create a class called LARGEDISK for
> disks large enough to partition into /, /var/ usr, ... So I just renamed
> that GRUB_PC.  Then I copied that file to GRUB_EFI andmodified it for
> gpt partitioning and EFI boot. It looks like this:
>
> === begin ===
> # 2018-07-04: jheim
> disk_config disk1 disklabel:gpt fstabkey:label align-at:1
> primary /boot/efi 204800K vfat rw
> primary/usr/local  157286400Kext4 rw,relatime
> createopts="-L LOCALFS"
> primary/   72G-  ext4 rw,relatime
> createopts="-L ROOTFS"
> primary    swap8Gswap rw
> createopts="-L SWAPFS"
> # EOF
> === end ===
>
>
>
>
>
>
>
> On 07/06/2018 07:27 AM, Rémy Dernat wrote:
> > Hi,
> >
> > I am trying to set up an UEFI boot pxe mainly because our hardware
> > servers do not support full legacy BIOS anymore (particularly hard disk
> > plugin on those servers).
> >
> > Our legacy pxelinux works just fine 

Re: UEFI + Legacy BIOS TFTP/PXELINUX

[John G Heim]

Sorry to reply to your posts out of order but I would not follow the 
advice in that message. It is at least out dated. You do not have to 
change your dhcp config after each install and you can continue to use 
your fai-chboot config files.  Syslinux does support EFI booting. It's 
in the syslinux-efi package.


Here is the code in my dhcp config file that sets the filename option 
depending on EFI/BIOS boot:


=== begin ===
# tell a kernel how to boot via PXE or NFS
server-name faiserver;
next-server faiserver;
# Check pxe boot code #93 to determine whether we are booting via BIOS 
or EFI

# 2018-07-04: jheim
option architecture-type code 93 = unsigned integer 16;
class "pxeclients" {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
if option architecture-type = 00:00 {
filename "fai/pxelinux.0";
} else {
filename "fai/syslinux.efi64";
}
}
=== end ===

The file syslinux.efi64 is from the debian syslinux-efi package. It's 
original name/path was /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi. I 
renamed it syslinux.efi64 to distinguish it from the 32-bit syslinux.efi 
file. Then I decided not to bother with 32-bit EFI boots. You also need 
some libs in your tftp directory to support EFI booting via syslinux. I 
think if you modify your dhcp config as abobe, copy the necessary files 
from the syslinux-efi package to your tftp space, you'll successfully 
boot into the FAI install. You will also need to create new disk config 
files to partition via gpt instead of msdos. (More on that below.)


1. Cut/passte above code into your dhcp config.
2. apt-get install syslinux-efi
3a. cp /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi /srv/tftp/fai/
3b. cp /usr/lib/syslinux/modules/efi64/ldlinux.e64 /srv/tftp/fai/

Done with the boot stuff. Now the disk config stuff.  Code that detects 
whether you have booted via BIOS or EFI already exists in the fai-doc 
examples. It's in a class script called 60-grub. It creates either 
GRUB_PC or GRUB_EFI class. You have to retain your old BIOS disk config 
files for older machines. I used to create a class called LARGEDISK for 
disks large enough to partition into /, /var/ usr, ... So I just renamed 
that GRUB_PC.  Then I copied that file to GRUB_EFI andmodified it for 
gpt partitioning and EFI boot. It looks like this:


=== begin ===
# 2018-07-04: jheim
disk_config disk1 disklabel:gpt fstabkey:label align-at:1
primary /boot/efi 204800K vfat rw
primary/usr/local  157286400Kext4 rw,relatime 
createopts="-L LOCALFS"
primary/   72G-  ext4 rw,relatime 
createopts="-L ROOTFS"
primaryswap8Gswap rw 
createopts="-L SWAPFS"

# EOF
=== end ===







On 07/06/2018 07:27 AM, Rémy Dernat wrote:

Hi,

I am trying to set up an UEFI boot pxe mainly because our hardware 
servers do not support full legacy BIOS anymore (particularly hard disk 
plugin on those servers).


Our legacy pxelinux works just fine from a while now (and thanks for it).

I followed this link : 
https://lists.uni-koeln.de/pipermail/linux-fai/2014-February/010294.html
... with no luck. I created an "UEFI" specific class to avoid the erase 
of DEFAULT, and put everything in that new class, because we will need 
to keep the pxelinux config.


My tftp fai folder is organised like this:
```
root@faiserv:/srv# tree -L 2
.
├── fai
│   ├── config
│   └── nfsroot
├── nfs4
└── tftp
     └── fai

root@faiserv:/srv/tftp/fai# tree -L 2
.
├── c2960s-universalk9-tar.150-2a.SE9.tar
├── cisco-ios-150-2a.tar -> c2960s-universalk9-tar.150-2a.SE9.tar
├── efi
│   ├── fonts
│   ├── grub.cfg
│   ├── grub.cfg.nok
│   ├── i386-pc
│   ├── locale
│   ├── pxelinux.cfg -> ../pxelinux.cfg
│   ├── unicode.pf2
│   └── x86_64-efi
├── gpxelinux.0
├── initrd.img-3.16.0-4-amd64
├── initrd.img-3.16.0-6-amd64
├── ldlinux.c32
├── lpxelinux.0
├── pxelinux.0
├── pxelinux.0.back
├── pxelinux.cfg
│   ├── 0A01FD03
│   ├── 0A01FFF2
│   ├── A226B5A1.disable
│   ├── A226B5A2.disable
│   ├── A226B5A3.disable
│   ├── A226B5A4.disable
│   ├── A226B5A5.disable
│   ├── A226B5A6.disable
│   ├── A226B5A7.disable
│   ├── A226B5A9
│   ├── A226B5AA.disable
│   ├── A226B5AB.disable
│   ├── A226B5B0.disable
│   ├── A226B5B4.disable
│   ├── A226B5B8
│   └── default
├── syslinux.efi
├── vmlinuz-3.16.0-4-amd64
└── vmlinuz-3.16.0-6-amd64

```

I do not know if the UEFI is also searching for a filename matching its 
IP address with the hexa value, so I created a symbolic link to the 
pxelinux.cfg parent directory...



I have no problem with DHCP, and my client is loading the grub.cfg menu. 
However, it fails while searching for the nfsroot. The error I get (with 
debug=all) is (replacing sensitive informations):

```
kern/disk.c:196 : Opening `tftp,IP.IP.IP.IP'...
disk/efi/efidisk.c:461 : opening tftp
kern/disk.c: 281: Opening `tftp,IP.IP.IP.IP' failed.
kern

Re: UEFI + Legacy BIOS TFTP/PXELINUX

[John G Heim]

Are you sure the problem isn't in the boot sequence on your host? If you 
have pxe/net boot before disk, it is going to pxe boot over and over. 
The reason I ask is that in my experience, if the disk is partitioned, 
the reboot whil hang. I work 100% will Dell computers in my job so maybe 
other EFI/BIOS detect an unbootable disk differently. But in my 
experience, it does not matter if the disk does not have a bootable 
partition, as long as there is a partition table on the disk, it won't 
move on to pxe boot again.


There is sample code in the fai-doc package that creates the classes 
GRUB_PC and GRUB_EFI during the install. Then there are scripts to 
properly install/configure grub depending on whether you are booting via 
BIOS or EFI. If grub is not getting installed correctly, you should 
check if those classes are properly being created during your FAI installs.


Another thing that might be wrong is your disk config. You have to use 
gpt and configure an EFI boot partition in your setup-storage config 
file in the disk_config sub directory.




On 07/06/2018 08:25 AM, Rémy Dernat wrote:
Hmmm Now it is installing fine, but it is trying to reinstall at 
each reboot, because the boot from the local disk failed (although the 
entry is well written is the UEFI boot menu).


My grub.cfg is now:
```
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
set timeout=5
# for debug:
#set pager=1
#set debug=all

insmod efi_gop
insmod efi_uga
if loadfont ${prefix}/unicode.pf2
then
     insmod gfxterm
     set gfxmode=auto
     set gfxpayload=keep
     terminal_output gfxterm
fi

menuentry "Install from FAI" {
      linux  vmlinuz-3.16.0-6-amd64 ip=dhcp aufs rw root=/dev/nfs 
nfsroot=IP.IP.IP.IP:/srv/fai/nfsroot 
FAI_FLAGS=verbose,sshd,createvt,reboot FAI_ACTION=install 
server=faiserv.acme.ltd FAI_CONFIG_SRC=nfs://faiserv.acme.ltd/srv/fai/config

      initrd initrd.img-3.16.0-6-amd64
}
```

It looks like FAI install is just loading the FAIBASE class. I think 
that "FAI_CONFIG_SRC=nfs://faiserv.acme.ltd/srv/fai/config" is not 
loading at the install step. Maybe I have some syntax error...


Best regards,
Rémy.

Le ven. 6 juil. 2018 à 14:27, Rémy Dernat <mailto:remy...@gmail.com>> a écrit :


Hi,

I am trying to set up an UEFI boot pxe mainly because our hardware
servers do not support full legacy BIOS anymore (particularly hard
disk plugin on those servers).

Our legacy pxelinux works just fine from a while now (and thanks for
it).

I followed this link :
https://lists.uni-koeln.de/pipermail/linux-fai/2014-February/010294.html
... with no luck. I created an "UEFI" specific class to avoid the
erase of DEFAULT, and put everything in that new class, because we
will need to keep the pxelinux config.

My tftp fai folder is organised like this:
```
root@faiserv:/srv# tree -L 2
.
├── fai
│   ├── config
│   └── nfsroot
├── nfs4
└── tftp
     └── fai

root@faiserv:/srv/tftp/fai# tree -L 2
.
├── c2960s-universalk9-tar.150-2a.SE9.tar
├── cisco-ios-150-2a.tar -> c2960s-universalk9-tar.150-2a.SE9.tar
├── efi
│   ├── fonts
│   ├── grub.cfg
│   ├── grub.cfg.nok
│   ├── i386-pc
│   ├── locale
│   ├── pxelinux.cfg -> ../pxelinux.cfg
│   ├── unicode.pf2
│   └── x86_64-efi
├── gpxelinux.0
├── initrd.img-3.16.0-4-amd64
├── initrd.img-3.16.0-6-amd64
├── ldlinux.c32
├── lpxelinux.0
├── pxelinux.0
├── pxelinux.0.back
├── pxelinux.cfg
│   ├── 0A01FD03
│   ├── 0A01FFF2
│   ├── A226B5A1.disable
│   ├── A226B5A2.disable
│   ├── A226B5A3.disable
│   ├── A226B5A4.disable
│   ├── A226B5A5.disable
│   ├── A226B5A6.disable
│   ├── A226B5A7.disable
│   ├── A226B5A9
│   ├── A226B5AA.disable
│   ├── A226B5AB.disable
│   ├── A226B5B0.disable
│   ├── A226B5B4.disable
│   ├── A226B5B8
│   └── default
├── syslinux.efi
├── vmlinuz-3.16.0-4-amd64
└── vmlinuz-3.16.0-6-amd64

```

I do not know if the UEFI is also searching for a filename matching
its IP address with the hexa value, so I created a symbolic link to
the pxelinux.cfg parent directory...


I have no problem with DHCP, and my client is loading the grub.cfg
menu. However, it fails while searching for the nfsroot. The error I
get (with debug=all) is (replacing sensitive informations):
```
kern/disk.c:196 : Opening `tftp,IP.IP.IP.IP'...
disk/efi/efidisk.c:461 : opening tftp
kern/disk.c: 281: Opening `tftp,IP.IP.IP.IP' failed.
kern/disk.c: 295: Closing `tftp'.
```


Here is my grub.cfg config :
```
root@faiserv:/srv/tftp/fai/efi# cat grub.cfg
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
set timeout=5
# for debug:
#set pager=1
set debug=all

insmod efi_go

Re: UEFI + Legacy BIOS TFTP/PXELINUX

[John G Heim]

Just a note ... You can still use syslinux/pxelinux to do FAI installs 
for both EFI and BIOS. In other words, you don't have to switch to grub, 
you can still use the syslinux pxe config files you created via fai-chboot.


Here is a link to an article that shows how to get isc-dhcp-server to 
detect whether you are booting via EFI or BIOS and set the filename 
option appropriately:

https://www.syslinux.org/archives/2014-October/022683.html

I just modified my faiserver to support both EFI and BIOS yesterday. It 
turned out being way easier than I expected. The only changed I had to 
make to my various configurations were the following:
1: Make the dhcp server detect EFI boot vs BIOS and set filename option 
appropriately (see above).
2: Rename my FAI setup-storage config files (in the disk_config sub 
directory) based on the classes FAI already creates, GRUB_PC and GRUB_EFI.

3: Modify the GRUB_EFI setup_storage config file:
3a.  Chage thedisklabel from msdos to gpt
3b: Change all logical partitions to primary.

There is sample code in the fai-docs package that shows how to create 
those classes, GRUB_PC and GRUB_EFI. I'd guess most people are already 
using that. So the only change I had to make to my FAI config was to 
rename my disk_config files to match those classes and then make some 
minor changes to the disk-config file to work with gpt instead of msdos.




On 07/06/2018 08:19 AM, tt-...@kky.ttu.ee wrote:

Hi!

Just went through setting up UEFI boot over PXE and TFTP. Of great help 
in figuring out what was going on was to add logging to the TFTP server:


Kill the tftp server started at boot and manually start one with

# /usr/sbin/in.tftpd –vvv --listen --user tftp --address 0.0.0.0:69 
--secure /srv/fai


or similar (check the startup script of in.tftpd, add –v’s generously).

Then you will see in the syslog, which files are being requested and 
whether they are actually being transmitted.


A successful UEFI boot with grub generates about 15 TFTP requests, 
starting with:


Jun 30 18:22:40 server in.tftpd[11435]: RRQ from 172.24.0.68 filename 
fai/efi/x86_64-efi/core.efi


Jun 30 18:22:40 server in.tftpd[11436]: RRQ from 172.24.0.68 filename 
/fai/efi/x86_64-efi/normal.mod


Jun 30 18:22:40 server in.tftpd[11437]: RRQ from 172.24.0.68 filename 
/fai/efi/x86_64-efi/extcmd.mod


[…]

A missing or misplaced file will show up as

Jun 30 18:22:40 server in.tftpd[11449]: RRQ from 172.24.0.68 filename 
/fai/efi/grub.cfg


Jun 30 18:22:40 server in.tftpd[11449]: sending NAK (1, File not found) 
to 172.24.0.68


Hoping this helps,

Toomas

*From:*linux-fai  *On Behalf Of *Rémy Dernat
*Sent:* Friday, July 6, 2018 3:28 PM
*To:* linux-fai@uni-koeln.de
*Subject:* UEFI + Legacy BIOS TFTP/PXELINUX

Hi,

I am trying to set up an UEFI boot pxe mainly because our hardware 
servers do not support full legacy BIOS anymore (particularly hard disk 
plugin on those servers).


Our legacy pxelinux works just fine from a while now (and thanks for it).

I followed this link : 
https://lists.uni-koeln.de/pipermail/linux-fai/2014-February/010294.html


... with no luck. I created an "UEFI" specific class to avoid the erase 
of DEFAULT, and put everything in that new class, because we will need 
to keep the pxelinux config.


My tftp fai folder is organised like this:

```

root@faiserv:/srv# tree -L 2

.

├── fai

│   ├── config

│   └── nfsroot

├── nfs4

└── tftp

     └── fai

root@faiserv:/srv/tftp/fai# tree -L 2

.

├── c2960s-universalk9-tar.150-2a.SE9.tar

├── cisco-ios-150-2a.tar -> c2960s-universalk9-tar.150-2a.SE9.tar

├── efi

│   ├── fonts

│   ├── grub.cfg

│   ├── grub.cfg.nok

│   ├── i386-pc

│   ├── locale

│   ├── pxelinux.cfg -> ../pxelinux.cfg

│   ├── unicode.pf2

│   └── x86_64-efi

├── gpxelinux.0

├── initrd.img-3.16.0-4-amd64

├── initrd.img-3.16.0-6-amd64

├── ldlinux.c32

├── lpxelinux.0

├── pxelinux.0

├── pxelinux.0.back

├── pxelinux.cfg

│   ├── 0A01FD03

│   ├── 0A01FFF2

│   ├── A226B5A1.disable

│   ├── A226B5A2.disable

│   ├── A226B5A3.disable

│   ├── A226B5A4.disable

│   ├── A226B5A5.disable

│   ├── A226B5A6.disable

│   ├── A226B5A7.disable

│   ├── A226B5A9

│   ├── A226B5AA.disable

│   ├── A226B5AB.disable

│   ├── A226B5B0.disable

│   ├── A226B5B4.disable

│   ├── A226B5B8

│   └── default

├── syslinux.efi

├── vmlinuz-3.16.0-4-amd64

└── vmlinuz-3.16.0-6-amd64

```

I do not know if the UEFI is also searching for a filename matching its 
IP address with the hexa value, so I created a symbolic link to the 
pxelinux.cfg parent directory...


I have no problem with DHCP, and my client is loading the grub.cfg menu. 
However, it fails while searching for the nfsroot. The error I get (with 
debug=all) is (replacing sensitive informations):


```

kern/disk.c:196 : Opening `tftp,IP.IP.IP.IP'...

disk/efi/efidisk.c:461 : opening tftp

kern/disk.c: 281: Opening `tftp,IP.IP.IP.IP' failed.

kern/disk.c: 295: Closing `tftp'.

```

Here is my grub.cfg config :

`

Re: UEFI + Legacy BIOS TFTP/PXELINUX

[Rémy Dernat]

Hmmm Now it is installing fine, but it is trying to reinstall at each
reboot, because the boot from the local disk failed (although the entry is
well written is the UEFI boot menu).

My grub.cfg is now:
```
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
set timeout=5
# for debug:
#set pager=1
#set debug=all

insmod efi_gop
insmod efi_uga
if loadfont ${prefix}/unicode.pf2
then
insmod gfxterm
set gfxmode=auto
set gfxpayload=keep
terminal_output gfxterm
fi

menuentry "Install from FAI" {
 linux  vmlinuz-3.16.0-6-amd64 ip=dhcp aufs rw root=/dev/nfs
nfsroot=IP.IP.IP.IP:/srv/fai/nfsroot FAI_FLAGS=verbose,sshd,createvt,reboot
FAI_ACTION=install server=faiserv.acme.ltd
FAI_CONFIG_SRC=nfs://faiserv.acme.ltd/srv/fai/config
 initrd initrd.img-3.16.0-6-amd64
}
```

It looks like FAI install is just loading the FAIBASE class. I think that
"FAI_CONFIG_SRC=nfs://faiserv.acme.ltd/srv/fai/config" is not loading at
the install step. Maybe I have some syntax error...

Best regards,
Rémy.

Le ven. 6 juil. 2018 à 14:27, Rémy Dernat  a écrit :

> Hi,
>
> I am trying to set up an UEFI boot pxe mainly because our hardware servers
> do not support full legacy BIOS anymore (particularly hard disk plugin on
> those servers).
>
> Our legacy pxelinux works just fine from a while now (and thanks for it).
>
> I followed this link :
> https://lists.uni-koeln.de/pipermail/linux-fai/2014-February/010294.html
> ... with no luck. I created an "UEFI" specific class to avoid the erase of
> DEFAULT, and put everything in that new class, because we will need to keep
> the pxelinux config.
>
> My tftp fai folder is organised like this:
> ```
> root@faiserv:/srv# tree -L 2
> .
> ├── fai
> │   ├── config
> │   └── nfsroot
> ├── nfs4
> └── tftp
> └── fai
>
> root@faiserv:/srv/tftp/fai# tree -L 2
> .
> ├── c2960s-universalk9-tar.150-2a.SE9.tar
> ├── cisco-ios-150-2a.tar -> c2960s-universalk9-tar.150-2a.SE9.tar
> ├── efi
> │   ├── fonts
> │   ├── grub.cfg
> │   ├── grub.cfg.nok
> │   ├── i386-pc
> │   ├── locale
> │   ├── pxelinux.cfg -> ../pxelinux.cfg
> │   ├── unicode.pf2
> │   └── x86_64-efi
> ├── gpxelinux.0
> ├── initrd.img-3.16.0-4-amd64
> ├── initrd.img-3.16.0-6-amd64
> ├── ldlinux.c32
> ├── lpxelinux.0
> ├── pxelinux.0
> ├── pxelinux.0.back
> ├── pxelinux.cfg
> │   ├── 0A01FD03
> │   ├── 0A01FFF2
> │   ├── A226B5A1.disable
> │   ├── A226B5A2.disable
> │   ├── A226B5A3.disable
> │   ├── A226B5A4.disable
> │   ├── A226B5A5.disable
> │   ├── A226B5A6.disable
> │   ├── A226B5A7.disable
> │   ├── A226B5A9
> │   ├── A226B5AA.disable
> │   ├── A226B5AB.disable
> │   ├── A226B5B0.disable
> │   ├── A226B5B4.disable
> │   ├── A226B5B8
> │   └── default
> ├── syslinux.efi
> ├── vmlinuz-3.16.0-4-amd64
> └── vmlinuz-3.16.0-6-amd64
>
> ```
>
> I do not know if the UEFI is also searching for a filename matching its IP
> address with the hexa value, so I created a symbolic link to the
> pxelinux.cfg parent directory...
>
>
> I have no problem with DHCP, and my client is loading the grub.cfg menu.
> However, it fails while searching for the nfsroot. The error I get (with
> debug=all) is (replacing sensitive informations):
> ```
> kern/disk.c:196 : Opening `tftp,IP.IP.IP.IP'...
> disk/efi/efidisk.c:461 : opening tftp
> kern/disk.c: 281: Opening `tftp,IP.IP.IP.IP' failed.
> kern/disk.c: 295: Closing `tftp'.
> ```
>
>
> Here is my grub.cfg config :
> ```
> root@faiserv:/srv/tftp/fai/efi# cat grub.cfg
> set menu_color_normal=white/black
> set menu_color_highlight=black/light-gray
> set timeout=5
> # for debug:
> #set pager=1
> set debug=all
>
> insmod efi_gop
> insmod efi_uga
> if loadfont ${prefix}/unicode.pf2
> then
> insmod gfxterm
> set gfxmode=auto
> set gfxpayload=keep
> terminal_output gfxterm
> fi
>
> menuentry "Install from FAI" {
>  linux  vmlinuz-3.16.0-6-amd64 rw ip=dhcp root=/dev/nfs
> nfsroot=IP.IP.IP.IP:/srv/fai/nfsroot FAI_FLAGS=verbose,sshd,createvt,reboot
> FAI_ACTION=install server=faiserv.acme.ltd
> FAI_CONFIG_SRC=nfs://faiserv.acme.ltd/srv/fai/config
>  initrd initrd.img-3.16.0-6-amd64
> }
>
> ```
>
>
> Any help would be greatly appreciated.
>
> Thanks,
> Rémy
>

RE: UEFI + Legacy BIOS TFTP/PXELINUX

[tt-fai]

Hi!

 

Just went through setting up UEFI boot over PXE and TFTP. Of great help in 
figuring out what was going on was to add logging to the TFTP server:

Kill the tftp server started at boot and manually start one with

# /usr/sbin/in.tftpd –vvv --listen --user tftp --address 0.0.0.0:69 --secure 
/srv/fai

or similar (check the startup script of in.tftpd, add –v’s generously).

 

Then you will see in the syslog, which files are being requested and whether 
they are actually being transmitted.

A successful UEFI boot with grub generates about 15 TFTP requests, starting 
with:

Jun 30 18:22:40 server in.tftpd[11435]: RRQ from 172.24.0.68 filename 
fai/efi/x86_64-efi/core.efi

Jun 30 18:22:40 server in.tftpd[11436]: RRQ from 172.24.0.68 filename 
/fai/efi/x86_64-efi/normal.mod

Jun 30 18:22:40 server in.tftpd[11437]: RRQ from 172.24.0.68 filename 
/fai/efi/x86_64-efi/extcmd.mod

[…]

 

A missing or misplaced file will show up as 

Jun 30 18:22:40 server in.tftpd[11449]: RRQ from 172.24.0.68 filename 
/fai/efi/grub.cfg

Jun 30 18:22:40 server in.tftpd[11449]: sending NAK (1, File not found) to 
172.24.0.68

 

Hoping this helps,

Toomas

 

From: linux-fai  On Behalf Of Rémy Dernat
Sent: Friday, July 6, 2018 3:28 PM
To: linux-fai@uni-koeln.de
Subject: UEFI + Legacy BIOS TFTP/PXELINUX

 

Hi,

 

I am trying to set up an UEFI boot pxe mainly because our hardware servers do 
not support full legacy BIOS anymore (particularly hard disk plugin on those 
servers).

 

Our legacy pxelinux works just fine from a while now (and thanks for it).

 

I followed this link : 
https://lists.uni-koeln.de/pipermail/linux-fai/2014-February/010294.html

... with no luck. I created an "UEFI" specific class to avoid the erase of 
DEFAULT, and put everything in that new class, because we will need to keep the 
pxelinux config.

 

My tftp fai folder is organised like this:

```

root@faiserv:/srv# tree -L 2

.

├── fai

│   ├── config

│   └── nfsroot

├── nfs4

└── tftp

└── fai

 

root@faiserv:/srv/tftp/fai# tree -L 2

.

├── c2960s-universalk9-tar.150-2a.SE9.tar

├── cisco-ios-150-2a.tar -> c2960s-universalk9-tar.150-2a.SE9.tar

├── efi

│   ├── fonts

│   ├── grub.cfg

│   ├── grub.cfg.nok

│   ├── i386-pc

│   ├── locale

│   ├── pxelinux.cfg -> ../pxelinux.cfg

│   ├── unicode.pf2

│   └── x86_64-efi

├── gpxelinux.0

├── initrd.img-3.16.0-4-amd64

├── initrd.img-3.16.0-6-amd64

├── ldlinux.c32

├── lpxelinux.0

├── pxelinux.0

├── pxelinux.0.back

├── pxelinux.cfg

│   ├── 0A01FD03

│   ├── 0A01FFF2

│   ├── A226B5A1.disable

│   ├── A226B5A2.disable

│   ├── A226B5A3.disable

│   ├── A226B5A4.disable

│   ├── A226B5A5.disable

│   ├── A226B5A6.disable

│   ├── A226B5A7.disable

│   ├── A226B5A9

│   ├── A226B5AA.disable

│   ├── A226B5AB.disable

│   ├── A226B5B0.disable

│   ├── A226B5B4.disable

│   ├── A226B5B8

│   └── default

├── syslinux.efi

├── vmlinuz-3.16.0-4-amd64

└── vmlinuz-3.16.0-6-amd64

 

```

 

I do not know if the UEFI is also searching for a filename matching its IP 
address with the hexa value, so I created a symbolic link to the pxelinux.cfg 
parent directory...

 

 

I have no problem with DHCP, and my client is loading the grub.cfg menu. 
However, it fails while searching for the nfsroot. The error I get (with 
debug=all) is (replacing sensitive informations): 

```

kern/disk.c:196 : Opening `tftp,IP.IP.IP.IP'...

disk/efi/efidisk.c:461 : opening tftp

kern/disk.c: 281: Opening `tftp,IP.IP.IP.IP' failed.

kern/disk.c: 295: Closing `tftp'.

```

 

 

Here is my grub.cfg config :

```

root@faiserv:/srv/tftp/fai/efi# cat grub.cfg

set menu_color_normal=white/black

set menu_color_highlight=black/light-gray

set timeout=5

# for debug:

#set pager=1

set debug=all

 

insmod efi_gop

insmod efi_uga

if loadfont ${prefix}/unicode.pf2

then

insmod gfxterm

set gfxmode=auto

set gfxpayload=keep

terminal_output gfxterm

fi

 

menuentry "Install from FAI" {

 linux  vmlinuz-3.16.0-6-amd64 rw ip=dhcp root=/dev/nfs 
nfsroot=IP.IP.IP.IP:/srv/fai/nfsroot FAI_FLAGS=verbose,sshd,createvt,reboot 
FAI_ACTION=install server=faiserv.acme.ltd 
FAI_CONFIG_SRC=nfs://faiserv.acme.ltd/srv/fai/config

 initrd initrd.img-3.16.0-6-amd64

}

 

```

 

 

Any help would be greatly appreciated.

 

Thanks,

Rémy

UEFI + Legacy BIOS TFTP/PXELINUX

[Rémy Dernat]

Hi,

I am trying to set up an UEFI boot pxe mainly because our hardware servers
do not support full legacy BIOS anymore (particularly hard disk plugin on
those servers).

Our legacy pxelinux works just fine from a while now (and thanks for it).

I followed this link :
https://lists.uni-koeln.de/pipermail/linux-fai/2014-February/010294.html
... with no luck. I created an "UEFI" specific class to avoid the erase of
DEFAULT, and put everything in that new class, because we will need to keep
the pxelinux config.

My tftp fai folder is organised like this:
```
root@faiserv:/srv# tree -L 2
.
├── fai
│   ├── config
│   └── nfsroot
├── nfs4
└── tftp
└── fai

root@faiserv:/srv/tftp/fai# tree -L 2
.
├── c2960s-universalk9-tar.150-2a.SE9.tar
├── cisco-ios-150-2a.tar -> c2960s-universalk9-tar.150-2a.SE9.tar
├── efi
│   ├── fonts
│   ├── grub.cfg
│   ├── grub.cfg.nok
│   ├── i386-pc
│   ├── locale
│   ├── pxelinux.cfg -> ../pxelinux.cfg
│   ├── unicode.pf2
│   └── x86_64-efi
├── gpxelinux.0
├── initrd.img-3.16.0-4-amd64
├── initrd.img-3.16.0-6-amd64
├── ldlinux.c32
├── lpxelinux.0
├── pxelinux.0
├── pxelinux.0.back
├── pxelinux.cfg
│   ├── 0A01FD03
│   ├── 0A01FFF2
│   ├── A226B5A1.disable
│   ├── A226B5A2.disable
│   ├── A226B5A3.disable
│   ├── A226B5A4.disable
│   ├── A226B5A5.disable
│   ├── A226B5A6.disable
│   ├── A226B5A7.disable
│   ├── A226B5A9
│   ├── A226B5AA.disable
│   ├── A226B5AB.disable
│   ├── A226B5B0.disable
│   ├── A226B5B4.disable
│   ├── A226B5B8
│   └── default
├── syslinux.efi
├── vmlinuz-3.16.0-4-amd64
└── vmlinuz-3.16.0-6-amd64

```

I do not know if the UEFI is also searching for a filename matching its IP
address with the hexa value, so I created a symbolic link to the
pxelinux.cfg parent directory...


I have no problem with DHCP, and my client is loading the grub.cfg menu.
However, it fails while searching for the nfsroot. The error I get (with
debug=all) is (replacing sensitive informations):
```
kern/disk.c:196 : Opening `tftp,IP.IP.IP.IP'...
disk/efi/efidisk.c:461 : opening tftp
kern/disk.c: 281: Opening `tftp,IP.IP.IP.IP' failed.
kern/disk.c: 295: Closing `tftp'.
```


Here is my grub.cfg config :
```
root@faiserv:/srv/tftp/fai/efi# cat grub.cfg
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
set timeout=5
# for debug:
#set pager=1
set debug=all

insmod efi_gop
insmod efi_uga
if loadfont ${prefix}/unicode.pf2
then
insmod gfxterm
set gfxmode=auto
set gfxpayload=keep
terminal_output gfxterm
fi

menuentry "Install from FAI" {
 linux  vmlinuz-3.16.0-6-amd64 rw ip=dhcp root=/dev/nfs
nfsroot=IP.IP.IP.IP:/srv/fai/nfsroot FAI_FLAGS=verbose,sshd,createvt,reboot
FAI_ACTION=install server=faiserv.acme.ltd
FAI_CONFIG_SRC=nfs://faiserv.acme.ltd/srv/fai/config
 initrd initrd.img-3.16.0-6-amd64
}

```


Any help would be greatly appreciated.

Thanks,
Rémy

Re: FAI installation on new PCs with UEFI BIOS -- reloaded

[Wolfgang Walkowiak]

Hi Juri,

thank you for the useful hint.  We'll try this if we encounter issues with 
some BIOSes not booting using the chain loader.


Cheers,

w.w.

On Tue, 19 Sep 2017, fai...@lihas.de wrote:


Hello,

it exist one lua script for pxelinux, which one can solve your problem
generally. If not please report issue against 
https://github.com/IServ-GmbH/localboot.lua

Mit freundlichen Gruessen,
   Juri Grabowski




==2017-09-19==08:08==

  Dr. Wolfgang Walkowiak Phone: +49-271-740-3889
  Fakultaet IV / Physik  Fax  : +49-271-740-3886
  Emmy Noether Campus
  Universitaet Siegen--> wolfgang.walkow...@hep.physik.uni-siegen.de
  Walter-Flex-Str. 3 wolfgang.walkow...@gmx.net
  57068 Siegen
  Germany

=

Re: FAI installation on new PCs with UEFI BIOS -- reloaded

[fai-ml]

Hello,

it exist one lua script for pxelinux, which one can solve your problem
generally. If not please report issue against 
https://github.com/IServ-GmbH/localboot.lua

Mit freundlichen Gruessen,
Juri Grabowski

FAI installation on new PCs with UEFI BIOS -- reloaded

[Wolfgang Walkowiak]

Hi,

today we expericened a new problem with a new PC (having an ASUS UEFI
BIOS vers. 2.17.1246) and our cluster's FAI installation.

Similar to what I had described (and solved by a workaround) in an earlier 
thread 
(http://linux-fai.uni-koeln.narkive.com/Qd1zAQEJ/fai-installation-on-new-pcs-with-uefi-bios)
we again experienced that we couldn't boot into the local harddrive 
from the pxelinux boot menu after the installation of the system 
completed.  As I wrote back then, after activating the PXE-boot in the 
UEFI-BIOS the FAI installation runs fine.  However, after reboot, when 
the pxelinux menu points to the "boot from the local harddisk" entry, the 
system just simnply reboots when the PXE ROM exits, and then loads the 
first BIOS boot entry, ie the pxelinux boot menu again.  Even using
the "LOCALBOOT -1" trick (described in the thread linked above) which 
worked earlier didn't work any more.


A bit of research, together with a colleague (Thanks!), resulted in the 
following solution for the local disk pxelinux menu entry:


  label local1
  MENU LABEL BOOT FROM ^LOCAL HARDDISK (chain)
  # request booting from local disk
  KERNEL c32/chain.c32
  APPEND hd0 0

Basically, instead of using the LOCALBOOT stanca, we are now chain-loading 
the first disk's MBR.  This works for our system now.


This post is for reference.  In case someone else will find it helpful.
Comments are welcome of course.

Best wishes,,

w.w.

==2017-09-15==16:16==

  Dr. Wolfgang Walkowiak Phone: +49-271-740-3889
  Fakultaet IV / Physik  Fax  : +49-271-740-3886
  Emmy Noether Campus
  Universitaet Siegen--> wolfgang.walkow...@hep.physik.uni-siegen.de
  Walter-Flex-Str. 3 wolfgang.walkow...@gmx.net
  57068 Siegen
  Germany

=

R: Problem with Serial ATA RAID (aka "fake RAID" or "BIOS RAID")

[Giorgio Buffa]

Hi Thomas,
thank you for your reply!

> I would try to avoid RST, and just use software raid.
> In your shell.log you have this line:
> 
> ERROR: Found Software RAID, but the mdadm package was not installed
> 
> You need the mdadm package installed, if you use software raid.
> 
> Try again with the package mdadm added, but I guess the fake raid is the
cause
> of your problem.

I've tried with the package mdadm added. The error in log files disappeared,
but the RAID1 array was damaged (it was marked as degraded, since the first
disk was expelled from the array itself).

So I've made another try (by re-installing from scratch without the mdadm
package). After the installation, I've followed the procedure in [1] and it
worked.
It basically states to use debian-installer to boot a rescue system with
"dmraid=true" kernel parameter (experimental! [2]), which is used to
re-configure and re-install the GRUB bootloader on the fake RAID volume.

Probably you're right to just use software RAID: it seems to be more
flexible, easier to use and better supported.

Kind regards,
Giorgio B.

[1] https://wiki.debian.org/DebianInstaller/SataRaid
[2]
https://www.debian.org/releases/jessie/amd64/ch05s03.html.en#installer-args

 

Re: Problem with Serial ATA RAID (aka "fake RAID" or "BIOS RAID")

[Thomas Lange]

I would try to avoid RST, and just use software raid.
In your shell.log you have this line:

ERROR: Found Software RAID, but the mdadm package was not installed

You need the mdadm package installed, if you use software raid.

Try again with the package mdadm added, but I guess the fake raid is
the cause of your problem.

-- 
regards Thomas

Problem with Serial ATA RAID (aka "fake RAID" or "BIOS RAID")

[Giorgio Buffa]

Hello list,

I've tried a client standalone installation via a USB stick (created from
the FAI ISO large image) using the "Simple" profile from the examples.
During the installation some errors were reported (see files attached).

 

The problem is the following: my system has 2 HDDs that I've put into a
single RAID1 array (mirroring) prior to the installation using the
capabilities provided by Intel Rapid Storage Technology (RST), which is a
sort of SATA/fake/BIOS RAID. After the installation, the system doesn't
boot, i.e. GRUB is not executed.

 

My feeling is that I have to modify my USB stick by (i) adding the mdadm
package and (ii) updating the script that configures GRUB.

Do you have any sort of experience with that kind of setup? In general, is
it better to avoid Intel RST in place of a pure software RAID using mdadm?

 

Thank you in advance for any suggestion and best regards,

Giorgio B.



fai.log
Description: Binary data


error.log
Description: Binary data


shell.log
Description: Binary data

Re: Problem with GPT Bios Partition

[Denny Bortfeldt]

Hello everyone,

just a follow-up. With the help from Kerim I could managed my setup.
The disk-label "gpt-bios" will create this special 2MB Bios-Partition at
the end of the part-layout. It's not neccessary to define it in the
disk_config-File.

So to create my layout as I mention in the first mail my disk_config looks
like this now:


#

disk_config disk1 disklabel:gpt-bios bootable:3 fstabkey:uuid

primary swap 8192 swap rw
primary /boot 512 ext4 rw,noatime,errors=remount-ro
primary / 15360 ext4 rw,noatime,errors=remount-ro




Thanks everyone for helping me out!


Best regards,
Denny


2015-11-26 18:39 GMT+01:00 Kerim Gueney <kgue...@uni-koeln.de>:

> Hey Denny,
>
> Type 4 is 16-bit FAT (up to 32M), I see there's some Microsoft partitions.
> Is the first partition perhaps an MBR that was installed along some
> previous Windows installation? I only ever see it when I installed Windows
> on my machine prior to Linux. Maybe you could do the following:
>
> disk_config disk1 disklabel:gpt-bios bootable:1 fstabkey:uuid
> primary - 2048 msdos rw # (msdos is fat16)
> primary swap 8192 swap rw
> primary /boot 512 ext4 rw,noatime,errors=remount-ro
> primary / 15360 ext4 rw,noatime,errors=remount-ro
> logical - 1- - -
>
>
> Best regards
> Kerim
>
>
>
> On 26.11.2015 18:14, Denny Bortfeldt wrote:
>
> Hey Kerim,
>
> no not really - my disk_config could be/is wrong.
> The following schema need to be created by FAI disk_config:
>
> GPT /dev/sda1 2048 6143 2M BIOS boot partition /dev/sda2 6144 16783359 8G
> Linux swap /dev/sda3 16783360 17831935 512M Microsoft basic data /boot
> /dev/sda4 17831936 49289215 15G Microsoft basic data / /dev/sda5 49289216
> 7812456414 3.6T Linux LVM
>
> But here's the problem: I don't know how.
> The /dev/sda1 partition don't have got a mount point and is a type "4" in
> fdisk/gdisk - so I don't know what I need to write in my disk_config so
> that FAI will use "type 4" in partition layout.
> /dev/sda2, /dev/sda3 and /dev/sda4 is clear - everything is "primary" and
> swap or ext4.
>
>
> So what do I need to enter in my disk_config that the result will look
> like:
>
> /dev/sda1 2048 6143 2M BIOS boot partition
>
> Thanks in advance :)
>
> Best regards,
> Denny
>
> 2015-11-26 17:48 GMT+01:00 Kerim Güney <kgue...@uni-koeln.de>:
>
>> Hi Denny,
>>
>> there seems to be a mismatch of sorts between your desired schema and
>> what you're actually describing. I am going to assume you want an EFI
>> partition that you're going to boot off of.
>>
>> To do so, this should work:
>>
>> disk_config disk1 disklabel:gpt-bios bootable:1 fstabkey:uuid
>>
>> primary /boot/efi 2048 vfat rw
>> primary swap 8192 swap rw
>> primary /boot 512 ext4 rw,noatime,errors=remount-ro
>> primary / 15360 ext4 rw,noatime,errors=remount-ro
>> logical - 1- - -
>>
>>
>> Best regards
>> Kerim
>>
>>
>> On 26/11/15 16:19, Denny Bortfeldt wrote:
>>
>> Hello everyone,
>>
>> I'm using FAI 5.0 and need a special partition layout for our centos kvm
>> installation.
>>
>> The partition schema need to be like this:
>>
>> GPT /dev/sda1 2048 6143 2M BIOS boot partition /dev/sda2 6144 16783359 8G
>> Linux swap /dev/sda3 16783360 17831935 512M Microsoft basic data /boot
>> /dev/sda4 17831936 49289215 15G Microsoft basic data / /dev/sda5 49289216
>> 7812456414 3.6T Linux LVM
>> Unfortunately I'm unable to create /dev/sda1 and /dev/sda5 with the
>> disk_config.
>> I don't know what "fstype" I have to enter, that FAI will partitionate
>> /dev/sda1 to "BIOS boot partition" (fdisk type "4").
>> fstype "efi" and "bios" will run into an error:
>> https://data.bortfeldt.net/f/d9b3239df0/
>> My current config_disk-File looks like this:
>> #
>>
>> disk_config disk1 disklabel:gpt-bios bootable:3 fstabkey:uuid
>>
>> primary - 2 efi -
>> primary swap 8192 swap rw
>> primary /boot 512 ext4 rw,noatime,errors=remount-ro
>> primary / 15360 ext4 rw,noatime,errors=remount-ro
>> logical - 1- - -
>>
>>
>> So is anyone here who can help me out with my disk_configuration so that
>> FAI will partitionate like the schema above?
>>
>> Thanks in advance.
>>
>> Best regards,
>> Denny
>>
>>
>> --
>>  Kerim Güney
>>
>>  Institut für InformatikJunior Sysadmin
>>  Universität zu KölnLehrstuhl Prof. Dr. M. Jünger
>> Weyertal 121
>>   50931 Köln
>>
>>
>
>

Problem with GPT Bios Partition

[Denny Bortfeldt]

Hello everyone,

I'm using FAI 5.0 and need a special partition layout for our centos kvm
installation.

The partition schema need to be like this:

GPT /dev/sda1 2048 6143 2M BIOS boot partition /dev/sda2 6144 16783359 8G
Linux swap /dev/sda3 16783360 17831935 512M Microsoft basic data /boot
/dev/sda4 17831936 49289215 15G Microsoft basic data / /dev/sda5 49289216
7812456414 3.6T Linux LVM


Unfortunately I'm unable to create /dev/sda1 and /dev/sda5 with the
disk_config.

I don't know what "fstype" I have to enter, that FAI will partitionate
/dev/sda1 to "BIOS boot partition" (fdisk type "4").
fstype "efi" and "bios" will run into an error:
https://data.bortfeldt.net/f/d9b3239df0/


My current config_disk-File looks like this:

#

disk_config disk1 disklabel:gpt-bios bootable:3 fstabkey:uuid

primary - 2 efi -
primary swap 8192 swap rw
primary /boot 512 ext4 rw,noatime,errors=remount-ro
primary / 15360 ext4 rw,noatime,errors=remount-ro
logical - 1- - -


So is anyone here who can help me out with my disk_configuration so that
FAI will partitionate like the schema above?

Thanks in advance.

Best regards,
Denny

Re: Problem with GPT Bios Partition

[Kerim Güney]

Hi Denny,

there seems to be a mismatch of sorts between your desired schema and 
what you're actually describing. I am going to assume you want an EFI 
partition that you're going to boot off of.


To do so, this should work:

disk_config disk1 disklabel:gpt-bios bootable:1 fstabkey:uuid

primary /boot/efi2048vfatrw
primaryswap8192swaprw
primary /boot512ext4rw,noatime,errors=remount-ro
primary /15360ext4rw,noatime,errors=remount-ro
logical-1---


Best regards
Kerim

On 26/11/15 16:19, Denny Bortfeldt wrote:

Hello everyone,

I'm using FAI 5.0 and need a special partition layout for our centos 
kvm installation.


The partition schema need to be like this:

GPT /dev/sda1 2048 6143 2M BIOS boot partition /dev/sda2 6144 16783359 
8G Linux swap /dev/sda3 16783360 17831935 512M Microsoft basic data 
/boot /dev/sda4 17831936 49289215 15G Microsoft basic data / /dev/sda5 
49289216 7812456414 3.6T Linux LVM
Unfortunately I'm unable to create /dev/sda1 and /dev/sda5 with the 
disk_config.
I don't know what "fstype" I have to enter, that FAI will partitionate 
/dev/sda1 to "BIOS boot partition" (fdisk type "4").
fstype "efi" and "bios" will run into an error: 
https://data.bortfeldt.net/f/d9b3239df0/

My current config_disk-File looks like this:
#

disk_config disk1 disklabel:gpt-bios bootable:3 fstabkey:uuid

primary -2efi-
primaryswap8192swaprw
primary /boot512ext4rw,noatime,errors=remount-ro
primary /15360ext4rw,noatime,errors=remount-ro
logical-1---


So is anyone here who can help me out with my disk_configuration so 
that FAI will partitionate like the schema above?


Thanks in advance.

Best regards,
Denny


--
 Kerim Güney

 Institut für InformatikJunior Sysadmin
 Universität zu KölnLehrstuhl Prof. Dr. M. Jünger
Weyertal 121
  50931 Köln

Re: Problem with GPT Bios Partition

[Denny Bortfeldt]

Hey Kerim,

no not really - my disk_config could be/is wrong.
The following schema need to be created by FAI disk_config:

GPT /dev/sda1 2048 6143 2M BIOS boot partition /dev/sda2 6144 16783359 8G
Linux swap /dev/sda3 16783360 17831935 512M Microsoft basic data /boot
/dev/sda4 17831936 49289215 15G Microsoft basic data / /dev/sda5 49289216
7812456414 3.6T Linux LVM

But here's the problem: I don't know how.
The /dev/sda1 partition don't have got a mount point and is a type "4" in
fdisk/gdisk - so I don't know what I need to write in my disk_config so
that FAI will use "type 4" in partition layout.
/dev/sda2, /dev/sda3 and /dev/sda4 is clear - everything is "primary" and
swap or ext4.


So what do I need to enter in my disk_config that the result will look like:

/dev/sda1 2048 6143 2M BIOS boot partition

Thanks in advance :)

Best regards,
Denny

2015-11-26 17:48 GMT+01:00 Kerim Güney <kgue...@uni-koeln.de>:

> Hi Denny,
>
> there seems to be a mismatch of sorts between your desired schema and what
> you're actually describing. I am going to assume you want an EFI partition
> that you're going to boot off of.
>
> To do so, this should work:
>
> disk_config disk1 disklabel:gpt-bios bootable:1 fstabkey:uuid
>
> primary /boot/efi 2048 vfat rw
> primary swap 8192 swap rw
> primary /boot 512 ext4 rw,noatime,errors=remount-ro
> primary / 15360 ext4 rw,noatime,errors=remount-ro
> logical - 1- - -
>
>
> Best regards
> Kerim
>
>
> On 26/11/15 16:19, Denny Bortfeldt wrote:
>
> Hello everyone,
>
> I'm using FAI 5.0 and need a special partition layout for our centos kvm
> installation.
>
> The partition schema need to be like this:
>
> GPT /dev/sda1 2048 6143 2M BIOS boot partition /dev/sda2 6144 16783359 8G
> Linux swap /dev/sda3 16783360 17831935 512M Microsoft basic data /boot
> /dev/sda4 17831936 49289215 15G Microsoft basic data / /dev/sda5 49289216
> 7812456414 3.6T Linux LVM
> Unfortunately I'm unable to create /dev/sda1 and /dev/sda5 with the
> disk_config.
> I don't know what "fstype" I have to enter, that FAI will partitionate
> /dev/sda1 to "BIOS boot partition" (fdisk type "4").
> fstype "efi" and "bios" will run into an error:
> https://data.bortfeldt.net/f/d9b3239df0/
> My current config_disk-File looks like this:
> #
>
> disk_config disk1 disklabel:gpt-bios bootable:3 fstabkey:uuid
>
> primary - 2 efi -
> primary swap 8192 swap rw
> primary /boot 512 ext4 rw,noatime,errors=remount-ro
> primary / 15360 ext4 rw,noatime,errors=remount-ro
> logical - 1- - -
>
>
> So is anyone here who can help me out with my disk_configuration so that
> FAI will partitionate like the schema above?
>
> Thanks in advance.
>
> Best regards,
> Denny
>
>
> --
>  Kerim Güney
>
>  Institut für InformatikJunior Sysadmin
>  Universität zu KölnLehrstuhl Prof. Dr. M. Jünger
> Weyertal 121
>   50931 Köln
>
>

Re: Problem with GPT Bios Partition

[Kerim Gueney]

Hey Denny,

Type 4 is 16-bit FAT (up to 32M), I see there's some Microsoft 
partitions. Is the first partition perhaps an MBR that was installed 
along some previous Windows installation? I only ever see it when I 
installed Windows on my machine prior to Linux. Maybe you could do the 
following:


disk_config disk1 disklabel:gpt-bios bootable:1 fstabkey:uuid
primary - 2048msdosrw # (msdos is fat16)
primaryswap8192swaprw
primary /boot512ext4rw,noatime,errors=remount-ro
primary /15360ext4rw,noatime,errors=remount-ro
logical-1---


Best regards
Kerim


On 26.11.2015 18:14, Denny Bortfeldt wrote:

Hey Kerim,

no not really - my disk_config could be/is wrong.
The following schema need to be created by FAI disk_config:

GPT /dev/sda1 2048 6143 2M BIOS boot partition /dev/sda2 6144 
16783359 8G Linux swap /dev/sda3 16783360 17831935 512M Microsoft 
basic data /boot /dev/sda4 17831936 49289215 15G Microsoft basic data 
/ /dev/sda5 49289216 7812456414 3.6T Linux LVM

But here's the problem: I don't know how.
The /dev/sda1 partition don't have got a mount point and is a type "4" 
in fdisk/gdisk - so I don't know what I need to write in my 
disk_config so that FAI will use "type 4" in partition layout.
/dev/sda2, /dev/sda3 and /dev/sda4 is clear - everything is "primary" 
and swap or ext4.



So what do I need to enter in my disk_config that the result will look 
like:

/dev/sda1 2048 6143 2M BIOS boot partition


Thanks in advance :)

Best regards,
Denny

2015-11-26 17:48 GMT+01:00 Kerim Güney <kgue...@uni-koeln.de 
<mailto:kgue...@uni-koeln.de>>:


Hi Denny,

there seems to be a mismatch of sorts between your desired schema
and what you're actually describing. I am going to assume you want
an EFI partition that you're going to boot off of.

To do so, this should work:

disk_config disk1 disklabel:gpt-bios bootable:1 fstabkey:uuid

primary /boot/efi2048vfatrw
primaryswap8192swaprw
primary /boot512ext4rw,noatime,errors=remount-ro
primary /15360ext4rw,noatime,errors=remount-ro
logical-1---


Best regards
Kerim


On 26/11/15 16:19, Denny Bortfeldt wrote:

Hello everyone,

I'm using FAI 5.0 and need a special partition layout for our
centos kvm installation.

The partition schema need to be like this:

GPT /dev/sda1 2048 6143 2M BIOS boot partition /dev/sda2 6144
16783359 8G Linux swap /dev/sda3 16783360 17831935 512M Microsoft
basic data /boot /dev/sda4 17831936 49289215 15G Microsoft basic
data / /dev/sda5 49289216 7812456414 3.6T Linux LVM
Unfortunately I'm unable to create /dev/sda1 and /dev/sda5 with
the disk_config.
I don't know what "fstype" I have to enter, that FAI will
partitionate /dev/sda1 to "BIOS boot partition" (fdisk type "4").
fstype "efi" and "bios" will run into an error:
https://data.bortfeldt.net/f/d9b3239df0/
My current config_disk-File looks like this:
#

disk_config disk1 disklabel:gpt-bios bootable:3 fstabkey:uuid

primary -2efi-
primaryswap8192swaprw
primary /boot512ext4rw,noatime,errors=remount-ro
primary /15360ext4rw,noatime,errors=remount-ro
logical-1---


So is anyone here who can help me out with my disk_configuration
so that FAI will partitionate like the schema above?

Thanks in advance.

Best regards,
Denny


-- 
  Kerim Güney


  Institut für InformatikJunior Sysadmin
  Universität zu KölnLehrstuhl Prof. Dr. M. Jünger
 Weyertal 121
   50931 Köln

Re: FAI installation on new PCs with UEFI BIOS

[Thomas Lange]

> On Tue, 1 Sep 2015 10:35:27 +0200, Wolfgang Walkowiak 
>  said:

> Basically it suggests to replace the stanca
>LOCALBOOT 0
> by
>LOCALBOOT -1
Hi Wolfgang,

I tested this with three of my hardware boxes, and I had no
problems. I will change this also in FAI as the new default
value. Thanks for your help.

-- 
regards Thomas

Re: FAI installation on new PCs with UEFI BIOS

[Wolfgang Walkowiak]

Hi Thomas (et al.),

thanks.  I just discovered a work-around for my issue with the UEFI 
BIOS looking at

  http://www.syslinux.org/wiki/index.php/SYSLINUX#LOCALBOOT_type

Basically it suggests to replace the stanca
  LOCALBOOT 0
by
  LOCALBOOT -1
in the appropriate PXELINUX menu.  This causes the BIOS (and also the UEFI 
BIOS of the ASUS motherboard we have) to accept the failure of the PXE 
boot and move on to the next entry in the boot order.  I tested it also 
with one of our older PCs without UEFI BIOS for which it worked as well.


This trick saves me from spending some time on debugging a combination of 
pxelinux and syslinux boot menus.  (Sorry, no recipe for that.)


Cheers,

w.w.

P.S.: Here are the contents of my localboot.inc snippet:

# localboot.inc
label local
MENU LABEL BOOT FROM ^LOCAL HARDDISK
# request booting from local disk -- has issue with UEFI-BIOS
## LOCALBOOT 0
# set LOCALBOOT to -1 to signal failure instead
LOCALBOOT -1


On Mon, 31 Aug 2015, Thomas Lange wrote:


On Mon, 31 Aug 2015 19:39:50 +0200, Wolfgang Walkowiak 
<walkow...@hep.physik.uni-siegen.de> said:


   > Or do I have to have a parallel syslinux TFTP boot menu setup as suggested
   > here: http://www.syslinux.org/wiki/index.php/PXELINUX#UEFI ?

   > I wonder whether the problem I ran into is specific to the mainboard
   > (ASUS H81M-(D) Plus 3) or more generic.
IMO this seems to be a general UEFI problem^Wfeature. All my install
clients still use the legacy BIOS mode. But I know new computers may
not support the legacy mode. I guess syslinux is the best source for
fixing this problem.
I would be happy if you could post your solution here.
--
regards Thomas




==2015-09-01==10:27==

  Dr. Wolfgang Walkowiak Phone: +49-271-740-3889
  Fakultaet IV / Physik  Fax  : +49-271-740-3886
  Emmy Noether Campus
  Universitaet Siegen--> wolfgang.walkow...@hep.physik.uni-siegen.de
  Walter-Flex-Str. 3 wolfgang.walkow...@gmx.net
  57068 Siegen
  Germany

=

Re: Creating GPT BIOS partition with FAI 4.0.6

[Soos Arpad]

Thomas Neumann wrote:

setup-storage will create a new partition and mark it and the location of this
'boot'-partition is at the beginning of the disk, but the partition index is
the next after the last defined partition, e.g.:

disk_config disk1 disklabel:gpt-bios
primary /   200M  ext3  rw,errors=panic
primary -   400M  swap  -

will result in

1) sda3 - biosboot
2) sda1 - /
3) sda2 - swap

Yes this is mostly a cosmetical issue. I can understand why it has been done
this way. Still don't like 'out of order' partitioning. There's a workaround
to achieve 'ordered' partitions.

disk_config disk1 disklabel:gpt
primary -   1M- -
primary /   200M  ext3  rw,errors=panic
primary -   400M  swap  -

However you _must_ set the required flag manually after the partitioning has
been done and before grub is being installed.


Well this is not at all a cosmetical issue as far my problems are 
concerned. So I have to ask which programm ist doing the paetitioning.
And why it is not possible to manage it with a personal decission, 
wether to do automatic paritioning or do it manually.


I´d like do have all clients trying netboot and if there's no server 
using their normal installation. And if there is a fai-server, making

it possible to do fai boot but no pationing or do it on the other side.
So, partitioning is not at all just a cosmetical issue.

Sorry for dissenting :-)
Arpad

Re: Creating GPT BIOS partition with FAI 4.0.6

[Thomas Neumann]

On Wednesday, March 27, 2013 09:24:43 AM Soos Arpad wrote:
 Well this is not at all a cosmetical issue as far my problems are
 concerned.

Sorry, but I fail to see the connection. I'm going to answer you further 
comments step-by-step.

 So I have to ask which programm ist doing the paetitioning.

'setup-storage', but normally you don't have any direct contact with that. 
Configuration is done via config space/disk_config/classname and performed 
by the 'partition' task.

 And why it is not possible to manage it with a personal decission,
 wether to do automatic paritioning or do it manually.

You can.

automatic: disklabel:gpt-bios
manual: disklabel:gpt

However 'gpt-bios' will result in a 'out-of-order' partition naming, like 
described in my previous post.
 
 I´d like do have all clients trying netboot and if there's no server
 using their normal installation.

???

This has absolutely nothing to do with this thread.

 And if there is a fai-server, making it possible to do fai boot but no
 pationing or do it on the other side.

I don't understand. FAI isn't very useful if you netboot into a FAI-client 
but don't perform some kind of partitioning. ('Keep  reuse all existing 
partitions' is a special case, but it is also handled via the partitioning 
task.)

 So, partitioning is not at all just a cosmetical issue.

I was referring only to the 'out-of-order' issue. This was not a general 
comment. Maybe that's where the misunderstanding comes from?

bye
thomas

Re: Creating GPT BIOS partition with FAI 4.0.6

[Bob Apodaca]

On 03/19/2013 11:16 AM, andrew bezella wrote:

unless this has changed in fai4, you would want to use
disklabel:gpt-bios instead of gpt.  the necessary bios_grub
partition should then be created automatically.


That's what I need to know. Thank you.

Re: Creating GPT BIOS partition with FAI 4.0.6

[Thomas Neumann]

On Tuesday, March 19, 2013 07:16:38 PM andrew bezella wrote:
 On Tue, 2013-03-19 at 10:59 -0700, Bob Apodaca wrote:
 disk_config disk1 disklabel:gpt bootable:1 fstabkey:uuid
 
 unless this has changed in fai4, you would want to use
 disklabel:gpt-bios instead of gpt.  the necessary bios_grub
 partition should then be created automatically.

Yes this works. (But I don't like how it works.)

setup-storage will create a new partition and mark it and the location of this 
'boot'-partition is at the beginning of the disk, but the partition index is 
the next after the last defined partition, e.g.:

disk_config disk1 disklabel:gpt-bios
primary /   200M  ext3  rw,errors=panic
primary -   400M  swap  -

will result in

1) sda3 - biosboot
2) sda1 - /
3) sda2 - swap

Yes this is mostly a cosmetical issue. I can understand why it has been done 
this way. Still don't like 'out of order' partitioning. There's a workaround 
to achieve 'ordered' partitions.

disk_config disk1 disklabel:gpt
primary -   1M- -
primary /   200M  ext3  rw,errors=panic
primary -   400M  swap  -

However you _must_ set the required flag manually after the partitioning has 
been done and before grub is being installed.

@Bob:

The reason why 'primary - 8  bios_grub' does not work is that setup-storage 
only provides 'filesystem creation'- and 'filesystem mount'-options. But this 
is not a filesystem issue. The required flag belongs to the partition layer.

bye
thomas

Re: whole disk RAID partitioned directly, with Grub BIOS partition

[David Dreezer]

How about something like


# example of new config file for setup-storage
#
# type mountpoint size   fs type mount options misc options

disk_config disk1 align-at:32256B
primary -   128 -   -
logical -   2048-   -
logical -   2048-   -
logical -   5120-   -
logical -   2048-   -
logical -   5120-   -
logical -   2000-   -   -

disk_config disk2 align-at:32256B
primary -   128 -   -
logical -   2048-   -
logical -   2048-   -
logical -   5120-   -
logical -   2048-   -
logical -   5120-   -
logical -   2000-   -   -

disk_config raid
raid1   /boot   disk1.1,disk2.1 ext3rw,noatime
raid1   swapdisk1.5,disk2.5 swapsw
raid1   /   disk1.6,disk2.6 ext3rw,errors=remount-ro
raid1   /vardisk1.7,disk2.7 ext3rw,noatime
raid1   /tmpdisk1.8,disk2.8 ext3rw,noatime
raid1   /usrdisk1.9,disk2.9 ext3rw,noatime
raid1   /appdisk1.10,disk2.10   ext3rw,noatime

This is a working config on our 4.0 install for MD raid. Perhaps it gives you a 
place to start from?

David Dreezer
 
 We couldn't see an updated manual for FAI 4.0. Is any of this in there? 
 Alternatively, has there been any work done to implement any of the above, 
 and if not would you accept a patch if we take our stab at adding support for 
 this?
 
 Many thanks!
 
 Iordan Iordanov
 CDF System Administrator,
 University of Toronto

Re: whole disk RAID partitioned directly, with Grub BIOS partition

[andrew bezella]

On Wed, 2012-05-23 at 16:32 -0400, Iordan Iordanov wrote:
[...] 
 2) We would like to give options to mdadm (e.g. to set metadata to 0.9),

mdcreateopts can be used in a disk_config: 
raid1   -   sdc1,sdd1   -   -   
mdcreateopts=--metadata=0.9

 3) We would like to be able to give options to parted (e.g. to create a 
 GRUB BIOS boot partition). The option to parted needs to be of the form 
 set N bios_grub on, where N is the partition number.

for this it may make sense to use disklabel:gpt-bios.  it creates an
add'l partition for bios_grub.

-- 
andrew bezella abeze...@archive.org
Internet Archive

Re: gpt-bios from setup-storage - does it really work?

[Steffen Grunewald]

On Tue, Dec 20, 2011 at 01:37:24PM +0100, Carsten Aulbert wrote:
 Hi
 
 I'm trying to partition a machine with the following disk configuration:
 
 disk_config /dev/disk/by-id/scsi-3600050e0f065*[A-Z0-9_][A-Z0-9_][A-Z0-9_] 
 fstabkey:uuid disklabel:gpt-bios bootable:1
 
 primary  /boot 256  ext2 rw,errors=remount-ro 
 primary  / 1   ext3  rw
 primary  swap  8192swap sw
 primary  /var 2xfsrw
 primary  /opt 5xfsrw
 primary  /tmp 2048 xfsrw
 primary  /local1000-   xfs rw
 
 all seems fine, but GRUB won't start after the reboot as is not able to reach 
 the gpt-bios partition:
 
 GNU Parted 2.3
 Using /dev/sdb
 Welcome to GNU Parted! Type 'help' to view a list of commands.
 (parted) p
 Model: AMCC 9690SA-4I DISK (scsi)
 Disk /dev/sdb: 3000GB
 Sector size (logical/physical): 512B/512B
 Partition Table: gpt
 
 Number  Start   End SizeFile system Name Flags
  1  32.3kB  268MB   268MB   ext2primary  boot

32.3KB - does this mean 63 sectors? AFAIK a GPT needs 34 sectors,
both at the beginning and the end of the disk...

  2  268MB   10.8GB  10.5GB  ext3primary
  3  10.8GB  19.3GB  8590MB  linux-swap(v1)  primary
  4  19.3GB  40.3GB  21.0GB  xfs primary
  5  40.3GB  92.7GB  52.4GB  xfs primary
  6  92.7GB  94.9GB  2147MB  xfs primary
  7  94.9GB  3000GB  2905GB  xfs primary
  8  3000GB  3000GB  123kB   primary  bios_grub
 
 as this one is beyond the 2TB border...
 
 Is there a nice way to reserve this partition right at the beginning?

What about splitting the large volume into two at the raid controller level,
and having a normal boot partition (and a normal grub installation at
the beginning of a small-sized volume)?

S

Re: Changing the BIOS boot order in linux

[Tim Cutts]

On 21 Jul 2009, at 1:51 pm, Joel Merrick wrote:


There might be a dirty way:

Write a FAI script or a hook for the final part of the installation.
This script changes the pxe configuration in such a way that the node
does not boot locally but it boots a DOS image.
This DOS image contains tools for setting the NVRAM and CMOS.  
Create a

CMOS-image which has the right boot order. After the next reboot the
nodes boots from a local disk.


This is intriguing, I take it you can use this method for BOIS updates
too (on hardware that it'll work with of course..)



Yep, used to do that on RLX blade servers all the time circa 2002,  
since they had no removable media at all, and the only way the  
firmware could be updated was to PXE boot a DOS floppy.  It was  
actually built into the RLX Control Tower software; its OS deployment  
method also used a PXE booted DOS boot floppy to SMB mount the Control  
Tower server's exported filesystems, which contained OS images which  
could be unpacked onto the disks of the machine.  The process was  
fairly analogous to the way FAI works today, but much less  
customisable.  SMB was used rather than NFS to make deploying Windows  
onto the blades easier (not that I heard of many RLX customers that  
were using Windows).


Even though RLX is long since a defunct company, Control Tower still  
exists as a product, only now it's owned by HP and goes by the name of  
Insight Control Linux Edition, which some of you may have seen.  It's  
had some fairly substantial rewriting since the days of Control Tower  
3 on the original RLX blade products, though.


Back to the question at hand, updating BIOS settings is frequently a  
hardware specific issue, and difficult to automate.  It's one of the  
principal reasons why I'm a fan of blade server architectures.  For  
example, on our HP c-Class blades, to PXE boot (and hence hand to FAI)  
a chassis of machines, I just log into the chassis onboard  
administrator using ssh, and then type:


set server boot once pxe all
reboot server all

Obviously if I only want to do a subset of blades, I can change all  
to be whichever blades I want to reboot.  Simple as that.  No messing  
about with PXE boot floppies and all that nonsense.


Tim


--
The Wellcome Trust Sanger Institute is operated by Genome Research 
Limited, a charity registered in England with number 1021457 and a 
company registered in England with number 2742969, whose registered 
office is 215 Euston Road, London, NW1 2BE. 

Changing the BIOS boot order in linux

[Sridhar Kumar Kotturu]

Hello,
I'm working on a project to do automatic Cent OS installation.
I've done all the things successfully except manual intervention in BIOS
boot order change.

I'm using PXE boot server, DHCP, tftp, syslinux, kickstart configuration for
the OS installation.

It seems in the Linux, it is NOT possible to change BIOS boot order in
running LINUX box.

How 'linux-fai' is doing this boot order change?

I've read the FAI guide, section 7.10 Changing the boot device, but did
NOT get the complete picture.

Any pointers/suggestions etc on how to boot from local hard disk after the
OS installation is done would be greatly appreciated.

Thanks in Advance,
Sridhar Kotturu.

Re: Changing the BIOS boot order in linux

[Thomas Lange]

 On Sat, 18 Jul 2009 18:29:34 +0530, Sridhar Kumar Kotturu 
 sridhar.kott...@gmail.com said:

 It seems in the Linux, it is NOT possible to change BIOS boot order in
 running LINUX box.
AFAIK it's not possible. There may be some hacks, but these don't work
on all machines. In FAI, the machines always boot from network via PXE
(so no changes in the BIOS) and get different configs that told them
to do the installation or to boot from local disk after the
installation finished.

-- 
regards Thomas

Re: BIOS

[Carsten Aulbert]

Hi Holger,

Holger Levsen wrote:
 
 Are you aware that you can flash many bioses from linux now? Read
 http://www.hermann-uwe.de/blog/flashing-a-bios-the-linux-way-tm-using-flashrom
  
 to learn more, it's packaged and in sid, but a backport to etch is trivial.

We have seen Uwe's planet post about this and it works for many boards.
Nice thing, however, there is the uncertainty that after flashing the
BIOS from within Linux the settings (nvram/cmos/whatever you want to
call it) might be screwed up. Most importantly, if the boot order during
flashing is reset, we would be screwed. Since the next reboot would most
certainly not have PXE as is first boot option.

Especially, the SuperMicro boards store settings out of reach for
/dev/nvram thus we would need the DOS image stuff anyways :(

But thanks for the pointer.

Carsten

Re: BIOS

[Holger Levsen]

Hi,

On Thursday 09 August 2007 09:37, Henning Fehrmann wrote:
 we are interested in flashing a BIOS image and in manipulating the NVRAM of
 the motherboard automatically.

Are you aware that you can flash many bioses from linux now? Read
http://www.hermann-uwe.de/blog/flashing-a-bios-the-linux-way-tm-using-flashrom 
to learn more, it's packaged and in sid, but a backport to etch is trivial.


regards,
Holger


pgpEabIzLOIRA.pgp
Description: PGP signature

Re: BIOS

[Henning Fehrmann]

Hello,
 
 This IMHO could be done without touching a real disk's MBR using a file 
 (untested).

Copying the MBR was basically the first method which worked.
According to the docu of memdisk, if you want to use arbitrary image
sizes, it has to be hd image with mbr and partition table.

 
 IIRC loopback mount has an option to skip to an offset inside the image... 
 man mount

Works fine, thanx.
mount  -o loop,blocksize=512,offset=32256 hd.img /mnt/dos

  
  * WATT-32 (TCP/IP stack for DOS) http://www.bgnett.no/~giva/ 
 
 Is there a binary version I have missed when I last looked?

We just build every thing from scratch. I guess this is the standard
tcp/ip stack used for freedos.

  * card driverhttp://www.georgpotthast.de/sioux/packet.htm
 
 You might also use the UNDI driver that sits on top of the PXE in the card's 
 firmware.
I will take a look.

 Of course that's a more elegant solution than having a fake TFTP request 
 which would
 trigger an action on the server side. Why didn't you go for a simple rsh 
 instead, which
 is already a prerequisite for FAI (writeback of install logs)?
 
Unfortunately, the only rsh version I found was from drdos and not free.
 
 If you don't mind I'd like to have a look at your image.
 I'd suggest to have 
 an interface to the possible tasks as clean as possible so that changes to
 the payload have to be done in only one place (our vendor for example uses
 a zip file that contains the payload, which is unpacked into a ramdisk, and
 it's setup.bat is started - this way the autoexec.bat stays unmodified if
 you replace the payload) - KISS :-)
 (My images are in CVS, faiconfig/files/boot/fai/floppy-images/)

Of course, but I will not attach it to this email, since it is compressed 13MB.
If it is in good shape (without a private sshkey), I will put it on a server 
and make a deb package
out of it. Is somebody of the FAI developer team interested?

Regards
Henning

Re: BIOS

[Thomas Lange]

 On Thu, 9 Aug 2007 11:03:10 +0200, Steffen Grunewald [EMAIL PROTECTED] 
 said:

 That's the problem: to get a reasonable message *somewhere* you'd need a 
TCP/IP
 stack. Or am I missing something?
No, you are right. TCP/IP is needed.

-- 
regards Thomas

[Fwd: Re: BIOS]

[Carsten Aulbert]

Sorry, used wrong from address (twice)

 Original Message 
Subject: Re: BIOS
Date: Thu, 09 Aug 2007 10:49:06 +0200
From: Carsten Aulbert [EMAIL PROTECTED]
Organization: Max Planck Institute for Gravitational Physics
To: linux-fai linux-fai@uni-koeln.de
References: [EMAIL PROTECTED] 
[EMAIL PROTECTED]


Hi

Thomas Lange wrote:
 we are interested in flashing a BIOS image and in manipulating the NVRAM of the motherboard 
 automatically.

Wow. Do you really need this?


Unfortunately, it looks that way. Especially if a new BIOS version comes
out, which fixes a problem and you don't want to run around with a
USB-floppy drive - if that is supported at all.


You can boot a DOS or floppy image using PXE. This is how a
pxelinux.cfg looks like for booting a floppy image: 


default dos
label dos
 kernel memdisk
 append keeppxe initrd=floppy.img

But AFAIR I had no success, because the dos flashing utilities seems
to wanna have a real floppy, not a fake of a floppy.


That already works (thanks to Steffen G.'s work and testing). Most newer
BIOS tools seem work fine even from a RAM disk.

 Optimally, using the DOS environment flashes the BIOS, sets the 
 NVRAM and sends a message to the FAI server to prepare the next boot of the clients for the

 installation.
You could send a message to the faimond which can change the pxelinux 
configuration.


How would we do that? So far we have not yet succeeded in putting TCP/IP
into FreeDOS. But we are working on that.


 In the worst case, the DOS environment is working autonomously and the 
FAI server is 'guessing'
 whether the BIOS is flashed or not, e.g., by analyzing the DHCP logs, but 
this is not what we really want.

Guessing if something has changed could easily be done using dmidecode,
which will give you the version of the BIOS.


Yes, but it won't tell us if setting out wanted CMOS settings worked. On
certain SM boards (which apparently use 256 bytes for storing stuff)
they seem to keep also some dates in there, thus even a md5sum on
/dev/nvram would tell you if it worked. Even with a patched nvram kernel
module this would differ from one node to the other.

Cheers

Carsten

[Fwd: Re: BIOS]

[Carsten Aulbert]

again

 Original Message 
Subject: Re: BIOS
Date: Thu, 09 Aug 2007 11:29:40 +0200
From: Carsten Aulbert [EMAIL PROTECTED]
Organization: Max Planck Institute for Gravitational Physics
To: linux-fai@uni-koeln.de
References: [EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED]


Hi Tim,

Tim Cutts wrote:
RLX got around this with their blade deployment system in a very hacky 
way; the DOS image they used included the Windows for Workgroups TCP/IP 
stack, and therefore SMB support, and they used this to update a status 
file for the node being deployed back on the Control Tower DHCP server.  
Nasty, but it worked.


You make me shudder despite the not too cold weather ;)

We are currently looking into the package offered here:

http://www.bgnett.no/~giva/index.html

More to come.

Carsten

Re: BIOS

[Oliver Osburg]

Hi,

Flashing a large number of BIOSes is done regularly by members of the
linuxbios (http://linuxbios.org)or openbios(www.openbios.org) project. I
think Stefan Reinauer ([EMAIL PROTECTED]) can answer you a lot of
your questions.

Hth and kind regards,

Oliver



* Thomas Lange [EMAIL PROTECTED] [070809 10:42]:
  On Thu, 9 Aug 2007 09:37:02 +0200, Henning Fehrmann [EMAIL PROTECTED] 
  said:
 
  we are interested in flashing a BIOS image and in manipulating the 
 NVRAM of the motherboard 
  automatically.
 Wow. Do you really need this?
 
  Unfortunately, using certain vendors, the access to the NVRAM is not 
 straightforward.
  These vendors are offering DOS tools only, to write in the NVRAM, 
 hence, we have to boot
  a DOS image and here starts the trouble.
 You can boot a DOS or floppy image using PXE. This is how a
 pxelinux.cfg looks like for booting a floppy image: 
 
 default dos
 label dos
  kernel memdisk
  append keeppxe initrd=floppy.img
 
 But AFAIR I had no success, because the dos flashing utilities seems
 to wanna have a real floppy, not a fake of a floppy.
 
 
  Optimally, using the DOS environment flashes the BIOS, sets the 
  NVRAM and sends a message to the FAI server to prepare the next boot of 
 the clients for the
  installation.
 You could send a message to the faimond which can change the pxelinux 
 configuration.
 
 
  In the worst case, the DOS environment is working autonomously and the 
 FAI server is 'guessing'
  whether the BIOS is flashed or not, e.g., by analyzing the DHCP logs, 
 but this is not what we really want.
 
 Guessing if something has changed could easily be done using dmidecode,
 which will give you the version of the BIOS.
 
 -- 
 regards Thomas
--
 *   Oliver Osburg   -  Administrator E-lingo PH Freiburg   *
 *  email: [EMAIL PROTECTED] phone: +49761682164 *
 *   note: All above is my opinion unless said otherwise*
 *   One Unix to rule them all, One Resolver to find them,  *
 *   One IP to bring them all and in the zone bind them.*

Re: BIOS

[Mario Fetka]

Am Donnerstag, 9. August 2007 11:26:05 schrieb Tim Cutts:
 On 9 Aug 2007, at 10:03 am, Steffen Grunewald wrote:
  On Thu, Aug 09, 2007 at 10:42:41AM +0200, Thomas Lange wrote:
  On Thu, 9 Aug 2007 09:37:02 +0200, Henning Fehrmann
  [EMAIL PROTECTED] said:
 
  we are interested in flashing a BIOS image and in manipulating
  the NVRAM of the motherboard
  automatically.
 
  Wow. Do you really need this?
 
  Unfortunately, using certain vendors, the access to the NVRAM is
  not straightforward.
  These vendors are offering DOS tools only, to write in the NVRAM,
  hence, we have to boot
  a DOS image and here starts the trouble.
 
  You can boot a DOS or floppy image using PXE. This is how a
  pxelinux.cfg looks like for booting a floppy image:
 
  default dos
  label dos
   kernel memdisk
   append keeppxe initrd=floppy.img
 
  But AFAIR I had no success, because the dos flashing utilities seems
  to wanna have a real floppy, not a fake of a floppy.
 
  It worked here, but I think that's something Henning has got
  running too.
  The problem is to tell the server to swap its PXE config file for
  this particular
  machine *after* the flash has been completed but *before* rebooting
  (automatically
  or by power cycle/IPMI reset). It'd be necessary to send some kind
  of signal
  to the server (a dummy tftp request is what I've done in the past,
  at least from
  a tomsrtbt image I used to perform some partitioning magic).
  Therefore, it would
  be nice to have a network stack under freedos (which the BIOS flash
  disks nowadays
  are based on).

 RLX got around this with their blade deployment system in a very
 hacky way; the DOS image they used included the Windows for
 Workgroups TCP/IP stack, and therefore SMB support, and they used
 this to update a status file for the node being deployed back on the
 Control Tower DHCP server.  Nasty, but it worked.

 Tim

we are using the mars-nwe (netware 3 simularor) with the pipe filesystem it is 
profiding
the great thing is there is a file in the netware share that is a script on 
the server witch will be exec with the infos written to it as parameter.
the bad thing is it requires ipx on the server activated.
also bad only the old 16bit client will work (drivers) with mars. 

wfg
Mario


signature.asc
Description: This is a digitally signed message part.

Re: [Fwd: Re: BIOS]

[Steffen Grunewald]

On Thu, Aug 09, 2007 at 11:45:43AM +0200, Carsten Aulbert wrote:
 We are currently looking into the package offered here:
 
 http://www.bgnett.no/~giva/index.html

That's the 32-bit version of WatTCP, isn't it? I couldn't get a proper
documentation (and a binary build!) when I last looked... If you succeed, 
please share ...

Cheers
 Steffen