PXE image looping
-
@Wayne-Workman Cool. I’ll look at that.
-
@Wayne-Workman Not sure if im using fdisk right. I run:
[root@localhost ~]# fdisk /dev/sdb1
and get
fdisk: cannot open /dev/sdb1: No such file or directory
Output of:
[root@localhost ~]# sudo fdisk -l Disk /dev/sda: 500.1 GB, 500074307584 bytes, 976707632 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 Disk label type: dos Disk identifier: 0x00018c75 Device Boot Start End Blocks Id System /dev/sda1 * 2048 1026047 512000 83 Linux /dev/sda2 1026048 976707583 487840768 8e Linux LVM
I have not used fdisk in like 12 years and that was in windows. I don’t want to screw something up.
-
@Wayne-Workman I’m an idiot. I was following the instructions on the wiki and was trying to use “sdb” instead of “sda” on my system. So did i do it right and why can’t I continue?
[root@localhost /]# fdisk /dev/sda1 Welcome to fdisk (util-linux 2.23.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Device does not contain a recognized partition table Building a new DOS disklabel with disk identifier 0x5cca602a. Command (m for help): m Command action a toggle a bootable flag b edit bsd disklabel c toggle the dos compatibility flag d delete a partition g create a new empty GPT partition table G create an IRIX (SGI) partition table l list known partition types m print this menu n add a new partition o create a new empty DOS partition table p print the partition table q quit without saving changes s create a new empty Sun disklabel t change a partition's system id u change display/entry units v verify the partition table w write table to disk and exit x extra functionality (experts only) Command (m for help): g Building a new GPT disklabel (GUID: 002FA017-DD70-4CA2-A4E0-41D4B51E68ED) Command (m for help): p Disk /dev/sda1: 524 MB, 524288000 bytes, 1024000 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 Disk label type: gpt # Start End Size Type Name Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: Re-reading the partition table failed with error 22: Invalid argument. The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) Syncing disks. [root@localhost /]# fdisk -l Disk /dev/sda: 500.1 GB, 500074307584 bytes, 976707632 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 Disk label type: dos Disk identifier: 0x00018c75 Device Boot Start End Blocks Id System /dev/sda1 * 2048 1026047 512000 83 Linux /dev/sda2 1026048 976707583 487840768 8e Linux LVM Disk /dev/mapper/centos-root: 53.7 GB, 53687091200 bytes, 104857600 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 Disk /dev/mapper/centos-swap: 4160 MB, 4160749568 bytes, 8126464 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 Disk /dev/mapper/centos-home: 441.6 GB, 441630851072 bytes, 862560256 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 [root@localhost /]# fdisk l fdisk: cannot open l: No such file or directory [root@localhost /]# fdisk /dev/sda Welcome to fdisk (util-linux 2.23.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): g Building a new GPT disklabel (GUID: B59077CE-6FB8-4EA4-B6DA-92E14E33A412) Command (m for help): p Disk /dev/sda: 500.1 GB, 500074307584 bytes, 976707632 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 Disk label type: gpt # Start End Size Type Name Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: Re-reading the partition table failed with error 16: Device or resource busy. The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) Syncing disks. [root@localhost /]# mkfs.ext4 /dev/sda mke2fs 1.42.9 (28-Dec-2013) /dev/sda is entire device, not just one partition! Proceed anyway? (y,n) y /dev/sda is apparently in use by the system; will not make a filesystem here! [root@localhost /]# mkfs.ext4 /dev/sda1 mke2fs 1.42.9 (28-Dec-2013) /dev/sda1 is mounted; will not make a filesystem here! [root@localhost /]#
-
@ManofValor Whether you’re able to shrink the
/home
directory and then expand the/
directory depends on how the partitions are laid on the disk. For a partition to be expanded, the actual physical location on the HDD that it’s expanding into must be available. Does that make sense?And while some Linux magic might exist to do it, I’ll always opt to do it using the OS Installer’s GUI, and if I wanted to possibly expand a partition in the future, I’d probably not even bother with bare metal, and use a VM and assign two HDDs before I installed the OS, and then I’d follow @george1421 's tutorial on expanding a virtual HDD.
So what I might tell you is… if you have a ton of space in /home, then maybe it’d be easier to just move your images to there. There is a good (and recent) thread on this here: https://forums.fogproject.org/topic/6580/changing-the-directory-where-fog-images-are-stored-question/27
-
@ManofValor when formatting a disk, it cannot be used during or before the time of the run.
You mount, from what I can tell, is already established for /dev/sda1, so run:
umount /dev/sda1
(I don’t know what folder it’s mounted to)Then make your changes to the partition layout. Also don’t try to format a disk. (/dev/sda), you should really only ever format a partition.
-
@ManofValor Ouch! I really think you should look into how fdisk and partitioning in general works before using this tool. From what I can see you’ve totally screwed the partition scheme on your FOG server and you will run into big trouble sooner or later. You might not see any issue yet as your disk was in use when you changed the partitions. But rebooting the machine will finally kill it I am pretty sure. So if you still have access try backing up things over the network or onto an external disk before it is too late!
Then you probably need to start from scratch. Install CentOS and probably best make sure you add a good size partition for
/images
right then. So you don’t have to move things around later on. Then install FOG trunk again. -
@Sebastian-Roth said:
Then you probably need to start from scratch. Install CentOS and probably best make sure you add a good size partition for
/images
right then. So you don’t have to move things around later on. Then install FOG trunk again.FWIW: Unless you specifically go into the hard drive layout during centos install Centos 7 will divide the hard drive between the root partition and the /home partition. Not really helpful for an application server configuration. If you are setting up fog on a VM create the initial FOG disk in the 16 to 20GB size, then after centos is installed add a new vmdk file that is 50-100GB and mount this new disk to the /opt directory before you install fog. Then during fog install tell fog to install its images in /opt/fog/images. This will keep all of the big files on the /opt disk without the risk of filling up the root partition on linux.
-
@george1421 said:
Unless you specifically go into the hard drive layout during centos install
That’s the only way I ever do it
I actually give /images it’s very own partition, and I seriously reduce the size of all other partitions.
-
@george1421 I knew I was going to screw it up. I want to make the images file as big as possible since this is strictly for image backup. So after install I could make it like 350G in size, right?
-
@ManofValor If you do as I suggest just create a 20GB vmdk for the OS. The OS only really needs about 5GB, but leave room for updates and such. Once that is done go back in and create a new vmdk file for your storage. Make it what ever size you need today. By putting the images in their own vmdk file you can dynamically grow that disk as you need to as time goes by.
Once you have that second vmdk file (will probably be listed as /dev/sdb) you will need to partition it with fdisk and then format it as ext4. Once you have that disk you need to attach it over/to the /opt directory so it mounts every time (using /etc/fstab file).
Once you have that new vmdk attached, then you can install fog and tell it to put its images in /opt/fog/images
This will be a great learning experience for you. Google is your friend.
-
@george1421 Solid advice, absolutely, and would work fine too.
I would prefer though to mount the 2nd hdd to /images because /opt/fog/images is a deviation from the expected. And because /images would be the expected location for all of our documentation, all of our forums posts, and any future advice we give out, and any tech with previous fog experience coming into an environment to take care of FOG would expect the images to be in that location, and the installer uses this location as default.
But again, nothing mechanically or logically wrong with moving it to /opt/fog/images, it’d be perfectly functional and equally as expandable in the future.
-
@Wayne-Workman What partitioning scheme do you recommend? I’ve been trying to look up the difference between the four options I have (standard, btrfs, LVM, and LVM Thin Provisioning). I was thinking standard for the OS and LVM thin for the images?
This is question for all.
-
@ManofValor LVM is easier to resize later. However, all can be resized, just the older the scheme the more difficult it is. You might want to hold off till @george1421 chimes in.
-
@ManofValor LVM is the way to go. But you still want to move your FOG storage off your root LVM, or if you fill it up you will have the same issue as if you had everything on the same partition. *nix does not like it when you fill up the root partition. When you do this, you will never have a happy ending. But if your images are on a different LVM or disk that is attached to your root partition then you can fill up that disk, but it won’t whack the root volume. Its kind of complicated how it is setup.
If you want to think about it in MS windows terms. The root disk/partition is like the drive and we will connect a new disk to the folder C:\opt. When you change into the C:\opt folder behind the magic curtain windows will seamlessly transition to that other drive.
-
@george1421 So for the install just do the 20 GB and then do the other one later after the install? I’m not trying to set this up as a VM, isn’t that what a vmdk is for? This is a physical server.
-
@ManofValor Sorry I shouldn’t think the whole world is virtualized.
On your server do you have a single disk, array, or what?
-
@george1421 Single. We are mostly virtualized, but not for this yet.
-
Using the install GUI, do I do it like this:
Manually partition OS with LVM at 20GB mounted on /boot using ext4
Manually partition storage, for images, with LVM at 450GB mounted on /opt/fog/images using ext4
Something along those lines?
-
@george1421 said:
Sorry I shouldn’t think the whole world is virtualized.
I was just going with the flow lol.
-
This post is deleted!