OS on usb stick
-
You’ll probably need to disconnect the hard drive. USB sticks should show up as a drive under linux, so it should work, but I could be wrong.
If you’re using single disk mode then it will only image the first storage device which in your case will always be the HDD (as it has precedence over USB devices)
As for the second issue, I believe if the HDD is still disconnected it will boot fine, however if you do need the hard drive then you’ll either need to add a new boot option to specify booting of it or you’ll need to modify the existing one (is this possible? haven’t tried it)
You’ll have to change the IP manually as far as I know, of course if you have full control over the DHCP server you could simply define the MAC addresses of the NUCs to be static in there and not have to worry about it.
-
the thing is that I don’t want to disconnect the HDD because it would mean that I would have to open the “box” which I don’t want to at the end
-
@kortnor Then you have to try using the All Disks option for the image as far as I know. There’s nothing on the HDD yet so it’s not a problem that it also gets imaged.
-
@kortnor A couple of tricky questions you got there. Quazz has already answered but I might add some notes as well.
- You can always force FOG to capture an image from a drive you want it to capture from using the “Host Primary Disk” setting for that particular host. Sure you need to find out which device the USB stick gets detected as first. If you are lazy just try
/dev/sdb
for example. But if you are keen to find out you better boot one of your client in debug upload mode. Then runlsblk -lpno KNAME,TYPE
to display disk devices (including the partitions). Setting the “Primary Disk” option should work with “Single Disk Resizable” AFAIK. - When booting to the FOG menu iPXE is in control at that moment. iPXE can hand back control to the BIOS in different ways. See the host’s “Host Bios Exit Type” (or “Host EFI Exit Type” if your clients have UEFI enabled). The only available option that might work in your case is “EXIT” I reckon. Just try all of them and see of any one of those work. If all of those fail you can try using GRUB’s map function. We’ve been using this in our labs where we had several OSes installed on two disks. Add a new iPXE menu entry (web gui -> FOG configuration -> iPXE New Menu Entry):
- Menu Item: fog.bootusb
- Description: Boot from USB key
- Parameters:
chain -ar http://${fog-ip}/${fog-webroot}/service/ipxe/grub.exe --config-file="rootnoverify (hd1);map (hd1) (hd0);chainloader (hd1)+1" || MENU
- Default Item: YES (if you want that)
- Menu Show With: All Hosts
- Changing to a static network configuration on the client should be possible using postdownload scripts. You can find a general example here. Sure you’d need a different shell script to do what you want but this example should give you an idea. There is still a minor issue with this. You want different IPs on the clients I guess. So you need to distinguish between the clients. I’d do this using the shell variable
$hostname
. If you configure the clients to be calledNUC-23
for example you could doip="192.168.1.$(echo $hostname | cut -d'-' -f 2)"
- You can always force FOG to capture an image from a drive you want it to capture from using the “Host Primary Disk” setting for that particular host. Sure you need to find out which device the USB stick gets detected as first. If you are lazy just try
-
if you know the USB device’s name, I think you could put that in the host’s
Host Primary Disk
field. Just a thought. -
@Sebastian-Roth
Due to the recent event in Brussel, I’vent had the time to try anything.
I’ll take the time this weekend to apply your suggestion I’ll keep you posted. -
So I’ve been able to capture the usb stick by following your instruction:
- Specify the host primary disk on the host manager ==> I simply added the /dev/sdc
- Also choose to GRUB_FURST_HDD to hostbios exist. Which allowed the client to boot the the usb stick if no task were scheduled.
I still need to create a postdownload script but it seems to be manageable.
Now I’ve another question. How can I reduce the image size that has been captured. the images saved has the size of the whole usb stick ( 16 gigs). Should I change the image type? I’ve actually chosen Multiple partition image- Single disk (2)
edit: on the client side, I can see tat the / partition is 13 gigs and there is actually 4 gigs used, however, the image stored on the fog server is 10gigs -
@kortnor said:
How can I reduce the image size that has been captured. the images saved has the size of the whole usb stick ( 16 gigs). Should I change the image type? I’ve actually chosen Multiple partition image- Single disk (2)
edit: on the client side, I can see tat the / partition is 13 gigs and there is actually 4 gigs used, however, the image stored on the fog server is 10gigsThe image type is ok! The size of the captured image depends in the filesystem on the source disk (USB stick in your case). Known filesystems (ext2/3/4, xfs, vfat, ntfs and others) are captured by only copying the data. But if you have unknown filesystems then FOG can only capture the whole partition in RAW mode. On capture you can see which mode is used in the blue partclone screens. See if it says RAW or EXT3 for example. Even better you could schedule a debug upload task and before running it check the filesystem types like this:
sfdisk -d /dev/sdc ... blkid -po udev /dev/sdc1 | grep FS_TYPE ... blkid -po udev /dev/sdc2 | grep FS_TYPE ...
Please post a picture of the screen with all the outputs! You should see
ID_FS_TYPE=ext4
for example! If there is no output from that command on one of the partitions it means that there es no known filesystem on that partition (will be copied RAW then). -
@Sebastian-Roth hereunder the requested extraction
I suppose that my issue is coming from the fact that my /dev/sdc2 is configured has a lvm_2_member.
EDIT: after It will be applied on usb stick pf 128 gb which is a lot to store on a VM afterward[root@laptop pla]# sfdisk -d /dev/sdc label: dos label-id: 0xf156c07c device: /dev/sdc unit: sectors /dev/sdc1 : start= 2048, size= 1024000, type=83, bootable /dev/sdc2 : start= 1026048, size= 30240768, type=8e [root@laptop pla]# blkid -po udev /dev/sdc1 | grep FS_TYPE ID_FS_TYPE=ext4 [root@laptop pla]# blkid -po udev /dev/sdc2 | grep FS_TYPE ID_FS_TYPE=LVM2_member [root@laptop pla]# [root@laptop pla]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 5.8G 0 5.8G 0% /dev tmpfs 5.8G 420K 5.8G 1% /dev/shm tmpfs 5.8G 1.6M 5.8G 1% /run tmpfs 5.8G 0 5.8G 0% /sys/fs/cgroup /dev/mapper/fedora-root 13G 3.8G 8.2G 32% / tmpfs 5.8G 84K 5.8G 1% /tmp /dev/sdc1 477M 108M 340M 25% /boot tmpfs 1.2G 8.0K 1.2G 1% /run/user/42 tmpfs 1.2G 24K 1.2G 1% /run/user/1000 /dev/sdd1 932G 897G 36G 97% /run/media/pla/Elements```
-
@kortnor said:
I suppose that my issue is coming from the fact that my /dev/sdc2 is configured has a lvm_2_member.
Unfortunately yes! AFAIK we don’t support LVM. We definitely did not in FOG 1.2.0 and I don’t remember anyone having had enough time and energy to add this to FOG. Maybe you can look into this and try adding full LVM support?!? You are most welcome to.
The other (and most probably way easier) path is to install fedora without LVM…
-
@Sebastian-Roth
this is quite a challenge ahaha I don’t have enough knowledge in lvm management but I can take a look at it definitelyAnyway thank you for your time and effort.