Encrypted root with btrfs

So I'm trying to set up my system with /dev/sda1 as a 500mb boot partition and /dev/sda2 as a plain dm crypted btrfs partition.
I've got it all set up and I can chroot into it. Everything is fine except it won't boot into a functional system
i've installed mkinicpio-btrfs from aur and reran mkinitcpio.
i can't figure out where the problem is. any ideas?
FSTAB
# /etc/fstab: static file system information
# <file system> <dir> <type> <options> <dump> <pass>
#### /dev/mapper/btrfs LABEL=btrfs
####UUID=78a05d43-f52a-4086-9255-5062e5fcbb94 / btrfs rw,relatime,space_cache,subvol=__active/rootvol 0 0
#### /dev/mapper/btrfs LABEL=btrfs
####UUID=78a05d43-f52a-4086-9255-5062e5fcbb94 /home btrfs rw,relatime,space_cache,subvol=__active/home 0 0
# /dev/mapper/btrfs LABEL=btrfs
/dev/mapper/btrfs / btrfs rw,noatime,compress=lzo,discard,autodefrag,inode_cache,subvol=__active/rootvol 0 0
/dev/sda2 /boot ext2 defaults 0 2
# /dev/mapper/btrfs LABEL=btrfs
/dev/mapper/btrfs /home btrfs rw,noatime,compress=lzo,discard,autodefrag,inode_cache,subvol=__active/home 0 0
# /dev/mapper/btrfs LABEL=btrfs
/dev/mapper/btrfs /mnt/defvol btrfs rw,noatime,compress=lzo,discard,autodefrag,inode_cache 0 0
syslinux.cfg
# Config file for Syslinux -
# /boot/syslinux/syslinux.cfg
# Comboot modules:
# * menu.c32 - provides a text menu
# * vesamenu.c32 - provides a graphical menu
# * chain.c32 - chainload MBRs, partition boot sectors, Windows bootloaders
# * hdt.c32 - hardware detection tool
# * reboot.c32 - reboots the system
# To Use: Copy the respective files from /usr/lib/syslinux to /boot/syslinux.
# If /usr and /boot are on the same file system, symlink the files instead
# of copying them.
# If you do not use a menu, a 'boot:' prompt will be shown and the system
# will boot automatically after 5 seconds.
# Please review the wiki: https://wiki.archlinux.org/index.php/Syslinux
# The wiki provides further configuration examples
DEFAULT arch
PROMPT 0 # Set to 1 if you always want to display the boot: prompt
TIMEOUT 50
# You can create syslinux keymaps with the keytab-lilo tool
#KBDMAP de.ktl
# Menu Configuration
# Either menu.c32 or vesamenu32.c32 must be copied to /boot/syslinux
UI menu.c32
#UI vesamenu.c32
# Refer to http://syslinux.zytor.com/wiki/index.php/Doc/menu
MENU TITLE Arch Linux
#MENU BACKGROUND splash.png
MENU COLOR border 30;44 #40ffffff #a0000000 std
MENU COLOR title 1;36;44 #9033ccff #a0000000 std
MENU COLOR sel 7;37;40 #e0ffffff #20ffffff all
MENU COLOR unsel 37;44 #50ffffff #a0000000 std
MENU COLOR help 37;40 #c0ffffff #a0000000 std
MENU COLOR timeout_msg 37;40 #80ffffff #00000000 std
MENU COLOR timeout 1;37;40 #c0ffffff #00000000 std
MENU COLOR msg07 37;40 #90ffffff #a0000000 std
MENU COLOR tabmsg 31;40 #30ffffff #00000000 std
# boot sections follow
# TIP: If you want a 1024x768 framebuffer, add "vga=773" to your kernel line.
LABEL arch
MENU LABEL Arch Linux
LINUX ../vmlinuz-linux
APPEND root=/dev/mapper/btrfs cryptdevice=/dev/sda2:btrfs rw
INITRD ../initramfs-linux.img
LABEL archfallback
MENU LABEL Arch Linux Fallback
mkinitcpio.conf
# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run. Advanced users may wish to specify all system modules
# in this array. For instance:
# MODULES="piix ide_disk reiserfs"
MODULES="crc32c"
# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image. This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=""
# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way. This is useful for config files.
FILES=""
# HOOKS
# This is the most important setting in this file. The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added. Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
## This setup specifies all modules in the MODULES setting above.
## No raid, lvm2, or encrypted root is needed.
# HOOKS="base"
## This setup will autodetect all modules for your system and should
## work as a sane default
# HOOKS="base udev autodetect block filesystems"
## This setup will generate a 'full' image which supports most systems.
## No autodetection is done.
# HOOKS="base udev block filesystems"
## This setup assembles a pata mdadm array with an encrypted root FS.
## Note: See 'mkinitcpio -H mdadm' for more information on raid devices.
# HOOKS="base udev block mdadm encrypt filesystems"
## This setup loads an lvm2 volume group on a usb device.
# HOOKS="base udev block lvm2 filesystems"
## NOTE: If you have /usr on a separate partition, you MUST include the
# usr, fsck and shutdown hooks.
HOOKS="base udev autodetect encrypt lvm2 modconf block filesystems keyboard fsck btrfs"
# COMPRESSION
# Use this to compress the initramfs image. By default, gzip compression
# is used. Use 'cat' to create an uncompressed image.
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"
# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=""
and this is what happens when i try to boot into it
http://i.imgur.com/FeaBjvC.jpg
-- mod edit: read the Forum Etiquette and only post thumbnails http://wiki.archlinux.org/index.php/For … s_and_Code [jwr] --

falconindy wrote:You're not passing any subvol in your bootloader config.
thanks that was the problem. it's running perfectly now. it's a great feeling diving into something deep in the command line and accomplishing it. making things work in arch is one of the most satisfying things ever.
Strongly recommend against mkinitcpio-btrfs, BTW. Its unmaintained, archaic, and unnecessary for most folks. Device assembly can be done entirely with udev.
so what do i need as far as hooks? just encrypt? or do i still need btrfs?
and is it going to create problems? i've already done it. does it require a reformat and starting over? can i uninstall mkinitcpio-btrfs and just run mkinitcpio again? or should i just leave it be since it's working?
edit: added rootflags=subvolume=__active/roovol
Last edited by risho (2014-09-07 06:29:28)

Similar Messages

[SOLVED] Trouble installing with encrypted root system

I'm trying to install with an encrypted root filesystem following the wikiguide: http://wiki.archlinux.org/index.php/Enc … Filesystem
I've downloaded the latest 0.7.1 ISO with 2.6.15-12 kernel.
All I get when I try to intall a bootloader is
Missing/Invalid root partition
Errormsg taken from the top of my head
Any suggestions? Isn't the guide applicable on 0.7.1 / 2.6.15-2-kernel?

It was all my bad.. I somehow forgot to configure a mount for /boot.

Luks encrypted root on sd card - problem with hooks

Hi,
I was trying to set up my arch system on an SD card on EeePC. I was using arch like that for about 4 months already, before my card crapped out, so now I have to reinstall it on a new card.
This time I thought I make an effort and use encrypted root, just like it is in the wiki.
I followed it exactly, and everything went fine - except when I actually tried to boot the system, it didn't work. Apparently the "encrypt" hook is being executed earlier than my /dev/sdb2 is recognized by the system.
However, when I use the arch-install cd to boot it ("arch root=/dev/sdb2") it correctly asks for my password and everything is fine, I'm in my newly installed system!
So, is this difference because the arch-install uses a different order of hooks? Or because it has to wait for the cdrom to settle, the /dev/sdb2 is not too late anymore?
I guess one solution would be is adding a "sleep 5" or something to the "encrypt" hook at installation. Where does the arch install find that version of "encrypt" that mkinitcpio uses during the install?
Or - is there any better solution? Like rearranging the order of hooks?
Thanks!

It doesn't seem to help - i think the "rootdelay=" kernel parameter only appears to have a difference at a different stage (and I think the [usb] hook has that already)
The problem is, that the udev hook (or the hardware recognition in [autodetect]?) doesn't finish before the [encrypt] hook runs.
I can see, that the hook [encrypt] passes, and a few lines afterwards "waiting for devices to settle", then the /dev/sdb is recognized....
Using the install CD - all hardware section finishes way before [arch_encrypt]...

Encrypted root fails without udev in initramfs

I'm trying to decrease my boot time on my new machine. After testing, I found the two biggest time-wasters on my system were Xorg and the initramfs. I can't do much about X, because I'm by no means highly skilled with code and I'd rather not use my inexpert skills to dissect and strip the Xorg binary. My focus, therefore, has been on removing udev from the initramfs to make it load faster.
I have tried this before, manually specifying the drivers and modules I need in the MODULES array and removing all hooks except base, encrypt, and fsck. My root partition is encrypted, but I may not even need the encrypt hook since I specify the dm_crypt and cryptsetup module/binary in the proper arrays. When I try and boot this, however, it hangs and then drops me to a prompt with the error "/dev/mapper/root not found." Here is my mkinitcpio.conf:
# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run. Advanced users may wish to specify all system modules
# in this array. For instance:
# MODULES="piix ide_disk reiserfs"
MODULES="sd_mod ata_piix jfs dm_crypt"
# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image. This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES="fsck.jfs fsck cryptsetup"
# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way. This is useful for config files.
FILES=""
# HOOKS
# This is the most important setting in this file. The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added. Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
## This setup specifies all modules in the MODULES setting above.
## No raid, lvm2, or encrypted root is needed.
# HOOKS="base"
## This setup will autodetect all modules for your system and should
## work as a sane default
# HOOKS="base udev autodetect block filesystems"
## This setup will generate a 'full' image which supports most systems.
## No autodetection is done.
# HOOKS="base udev block filesystems"
## This setup assembles a pata mdadm array with an encrypted root FS.
## Note: See 'mkinitcpio -H mdadm' for more information on raid devices.
# HOOKS="base udev block mdadm encrypt filesystems"
## This setup loads an lvm2 volume group on a usb device.
# HOOKS="base udev block lvm2 filesystems"
## NOTE: If you have /usr on a separate partition, you MUST include the
# usr, fsck and shutdown hooks.
HOOKS="base udev modconf keyboard encrypt fsck"
# COMPRESSION
# Use this to compress the initramfs image. By default, gzip compression
# is used. Use 'cat' to create an uncompressed image.
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
COMPRESSION="cat"
# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=""
I'm assuming udev is needed to scan for the root device and/or find the encrypted partition for cryptsetup to unlock. Is there a way around this? I'd like to cut out udev, as it is the biggest time hog within initramfs.
I heard something about static /dev folders, but I'm not entirely sure how to go about setting that up or if it will work with an encrypted root...
EDIT:
I looked more closely at the initramfs shell on my latest test. Without udev, the /dev folder is still populated with my drive partitions and cryptsetup (when run manually from within initramfs) will unlock my root partition just fine. It seems to me that cryptsetup is failing to run initially for some reason. Thoughts?
Last edited by ParanoidAndroid (2013-06-18 21:51:11)

The encrypt hook requires the udev hook. If you had taken a look at the actual install file for the encrypt mkinitpcio hook, you would have seen that it functions by pulling in a few udev rules which are activated when the init script calles "udevadm trigger". If you want your initramfs to decrypt your filesystem without udev, you are going to have to write your own hook.
As a side note, I have tried using mdadm vs mdadm_udev, as well as udev vs no-udev/btrfs in my initramfs, and having udev is always faster. I think if you are so concerned about boot time, the best way to do that is to use a mush more simplified set up. But since you use encryption, it would seem that security must have some signifigance to you, so that may not be an option. You have to understand that the time spend in the initramfs also includes the time it takes for you to enter your password to decrypt your partition (if you use a password).
One non-obvious thing you can do to potentially speed up your initramfs load time is to not compress it. As far as compression is concerned, lzo is the fastest, and 3.9 brought some not insignifigant speed improvments. But having it just read the whole thing uncompressed I have foudn to be consistently faster.
Really though, I think the whole idea of speeding up boot time is not really something worth pursuing unless you have something that is making it horribly slow. What kind of time is systemd-analyze repotying anyway? (BTW, systemd-analyze is not really a true representation of experienced boot time as it only records time it takes to get to userspace, which is not what most people think it is)

Should i use compression with btrfs, an ssd, and a 1.6 atom processor?

My netbook has a 60gb ssd with btrfs, is it a good idea to enable compression? My main goal for this net-book is battery life.
If i do enable compression only new files are compressed, is there a way to walk over old files and compress them?
My current partition looks like this:
/boot ext2 200mb
/ btrfs 7g
/home btrfs 46g
I need to make my root larger because i am running out of space so i'm going to be messing with the file systems anyway this suggests that i place my entire system in a subvolume, is this something i can do retroactively, or would I have to do a reinstall, which i'm ok with
Last edited by seniorsassycat (2012-01-27 01:45:58)

Compression can help with SDD longevity (less data written) but not the battery's longevity (which will require charging more often and eventually start to hold less charge). I would probably not enable compression at all. 60 GB is plenty.
If you think about it, while you can't actually replace either of them in a netbook, the battery is more important - at least in a portable device. Even if the SSD gives out in 5-8 years at least you could still boot from a USB stick and breathe some life into it. But replacing the battery... well, it's probably not gonna happen. And by that time it will probably end up on a garbage landfill anyway. Pff... Consumerism.

[solved] kernel 2.6.27 - open LUKS encrypted root partition fails

Hi,
after updating to kernel 2.6.27 the passphrase for my LUKS encrypted root partition does not work anymore.
I get this error messages:
Enter LUKS passphrase:
device-mapper: table: 254:0 crypt: Error allocating crypto tfm
device-mapper: ioctl: error adding target to table
device-mapper: ioctl: device doesn't appear to be in the dev hash table.
Command failed: No key available with this passphrase.
Enter LUKS passphrase:
With a old (2.6.25) vanilla kernel it works.
any ideas?
EDIT
Solved.
The Problem was that I had this line in my mkinitcpio.conf to get rid of the padlock-error-message at boot.
#CRYPTO_MODULES="aes_i586 aes_generic sha256_generic"
With kernel 2.6.27 there are new / more modules needed to open the LUKS encryptet root partition.
So I removed the line from mkinitcpio.conf and deletet the padlock modules in /lib/modules/2.6.27-ARCH before regenarating the initrd image.
Thanks to GerBra for the tip.
Last edited by SiD (2008-10-22 11:41:56)

I'm not shure, but think ... yes.

[SOLVED] Encrypted root, /boot on USB, cryptkey issue

Well to the topic. Followed this guide.
Usb flash drive with GRUB and a keyfile on it. Encrypted root.
grub.cfg
linux /vmlinuz-linux root=UUID=<uuid> ro cryptdevice=/dev/disk/by-id/<id>:luks cryptkey=/dev/disk/by-uuid/<uuid>:ext2:/key ipv6.disable=1 quiet
echo 'Loading initial ramdisk ...'
initrd /initramfs-linux.img
mkinitcpio.conf
MODULES="ata_generic ata_piix nls_cp437 ext2 i915"
HOOKS="base udev autodetect modconf block encrypt filesystems keyboard fsck consolefont"
Result: "Meh can't read a keyfile. Please input a passphrase om nom nom."
Tried:
1. Quadruple-checked UUID's, used /dev/sdX instead of them.
2. Using different modules, like nls_utf8, removing ata_* stuff.
3. Playing with <path> and <keyfile> strings, slashes, e t c.
4. A barrel roll.
Is it actually possible to make that filesystem key reading work? If not, how can I get physical offset of keyfile in a filesystem?
UPDATE:
Trouble in device detection speed. Any other usb media get's recognized instantly, while the one I booted from is slow like hell.
Last edited by wfoojjaec (2013-08-14 14:37:11)

Marked as solved.
It seems that origin of a bug was somewhere in a kernel. After a recent update, done today of a 'linux' package a /boot usb device is properly recognized after about 5 seconds passed from poweron (instead of a full initialization at ~270 sec and hanging udev before).
A hack with fstab & noauto is not required now. <_<

[SOLVED] Encrypted root on USB drive problem

Hi,
I have encrypted root on external USB harddrive. On one machine it works just fine, LUKS ask for password and system starts.
On second it does not work. I tryed nearly all possible combinations of modules and hooks. I can also access my usb drive if I use break=y. I am using current kernel & utils, I definitely use right paths...
Machine is an Dell with Intel chipset. My USB drive is like this:
/dev/sdb1 - big fat32
/dev/sdb2 - ext2 boot with Grub, kernel and initrd image
/dev/sdb3 - root fs, reiserfs encrypted with LUKS
I made little debuging and it seems that encrypt hook was launched, but did not make anything. Before I digg deeper I wonder that someone had same problem, or can give me advice.
Kernel panic screenshot:
PS: how can I put busybox to initrd image? echo * sucks.
Thanks
Last edited by Trained.Monkey (2007-10-10 09:42:13)

I solved, problem is that encrypt is running BEFORE usb drive is fully initialized. Encrypted partition is not found and not used.
Solotion:
put sleep 5 at beggining of encrypt hook. You must also add sleep binary at installer.

HT204490 Problem encrypting email with iMail after downloading 10.10.3 OS X

After installing 10.10.3 OS X, my colleague and I both lost our ability to send encrypted email with iMail. Sending encrypted email is part of our regular day job so the loss was immediately noticeable after installing 10.10.3. We can digitally sign an email, but no ability to encrypt. I've already deleted my certificates and reinstalled to no avail. Any other thoughts?

OS X Yosemite: If your certificate isn’t being accepted
List of available trusted root certificates in OS X Yosemite

Plymouth graphical boot, encrypted root, and systemd...

I'm having some difficulty getting Plymouth working with an encrypted root, and, systemd in the initramfs. I had identical issues getting Plymouth working without systemd in the initramfs, so that doesn't seem to be the issue.
I installed plymouth-git from the AUR. I similarly tried this with the non-git AUR package as well, with no different results. While trying to use the non-git package, I used the sd-plymouth mkinitcpio module from Celti's Github (He maintain's the -git AUR package), as posted in the comments. This enables support for systemd support inside the initramfs for plymouth, through using the sd-plymouth hook in place of the normal plymouth flag. When using the normal plymouth flag, and base + udev in place of systemd in my hooks, the same thing happens, so it seems unlikely to be the systemd implementation.
Anyhoo, when using plymouth and plymouth-encrypt in my hooks, I never get asked for a password to decrypt the root volume. It just presents the splash, and, that's all I ever see. After a couple of minutes, it dumps me to a black screen.
The contents of my /etc/mkinitcpio.conf file
MODULES=""
BINARIES=""
FILES=""
HOOKS="systemd sd-plymouth autodetect modconf block keyboard plymouth-encrypt filesystems fsck"
COMPRESSION="gzip"
COMPRESSION_OPTIONS=""
I use rEFInd, not grub or gummiboot, and my kernel options are as follows:
rd.luks.name=945737e7-94a0-49a0-b1ab-b51cb497ec4a=root root=/dev/mapper/root initrd=intel-ucode.img initrd=initramfs-linux.img rw nomodeset add_efi_memmap quiet splash
When booting, I'm greeted with my rEFInd GUI, it drops to a black screen for a fraction of a second, and loads Plymouth, and, sits there for about 90 seconds before dumping me to a black screen. When I type something on the keyboard, it shows up in the console, on top of the splash screen. It's almost as if plymouth isn't hooking the input. It fails to ask for a password or decrypt my root, too. I do notice when not using sd-plymouth, the splash logo appears to have an input box as if it at least knows it's attempting to decrypt it, but again, the input fails to go into the splash screen, but shows up (in cleartext) in the console at the top corner.
Suggestions would be appreciated.

Without hacking the encrypt hook, you'll only be able to unlock one volume at the same time. Afaik the device mapper asks for a password for each encrypted partition, and using one for all won't work, you have to repeat the process for each partition, whereas the encrypt hook only seems to be able to handle one partition. You can hack it, but I haven't done that (yet), it's already quite messy you have to hack the hook file to make it apply to non-root partitions.

Unable to open encrypted pages with 11.0.02 on Win7 IE10 system fully updated.

Just get blank screen with "X" in upper left. Have searched this forum and tried all suggestions including:
Cleared and reset all IE10 settings - no luck
Disabled and enabled Adobe add-ins - no luck
Right click on link and 'save as' or 'open' and others on the Tool menu - no luck
System restore - no luck
Disabled and enabled other add-ins - no luck
My win8 IE10 system opens encrypted pages with no problem. I set the IE10 tab options identically in the win7 system - no luck
Contacted websites using encryption (bank and credit cards). They have no other suggestions.
Any other suggestions?

Hi there,
Welcome to Adobe Forums.
Try turning off the Protected View under Edit > Preferences >Security (Enhanced) in Adobe Reader.
Hope this helps!
Thanks!

Slow system with btrfs

Hi, I have reinstalled system and choose btrfs as system default filesystem. System is overally very slow, maybe this can be also caused by systemd(I had installed archlinux without systemd before), but dont think so.
It takes about 30s to start any application, openning webpages is slow, downloading....copying between folders is about 5MB/s.
Can be this caused by btrfs?
I have noteebook ibm x41, with 1,5ghz cpu, 1,5gb ram.
Is possible and how to backup data on system disk with btrfs and change filesystem to ext4?
thanks

http://arosenfeld.wordpress.com/2010/12 … rom-btrfs/
https://btrfs.wiki.kernel.org/index.php/Gotchas
http://www.spinics.net/lists/linux-btrfs/msg14691.html
http://www.phoronix.com/scan.php?page=a … ions&num=4

Can anyone recommend a portable USB 3.0 drive with hardware encryption, compatible with OSX and Windows 7. I need it for my MacBook Pro 13", 2012, running Mountain Lion

Can anyone recommend a portable USB 3.0 drive with hardware encryption, compatible with OSX Mountain Lion and Windows 7. I need it for my MacBook Pro 13”, 2012, running Mountain Lion & Windows 7 Ultimate - BootCamp. I’ve heard that the Buffalo MiniStation Encryption does not work with OSX, is that true..? I'd like it to work with both operating systems, using the built in hardware encryption. Thanks

This article may help: A flashing question mark appears when you start your Mac.

[SOLVED] dual booting windows 7 with btrfs on grub-bios -- core.img

I am trying to install arch in a dual boot configuration with an existing windows 7 partition. I have everything from the beginner's guide done but the bootloader. When I run grub-install it tells me that core.img is too big.
Some googling tells me that this is relatively common with btrfs, and it seems the only work around is to switch to gpt mode and use a grub bios partition. But the info I've seen indicates that I need to use MBR mode to dual boot windows.
Is it safe to do this with windows? Is there another workaround? Or will I have to settle for ext4?
Last edited by jorenko (2013-06-09 03:53:24)

Well there's your problem, your first partition starts at sector 63. With recent versions of windows and fdisk (and every other partitioning tool I can think of off the top of my head) things now align themselves correctly. Also because there is now GPT, the first partition typically starts later as the GPT partition table will typically sit between the MBR and the first partition.
On a MBR partitioned system, grub2 will actually use the first 446 bytes like normal, but will then also use the space that is empty where GPT would sit. This is why when you have a GPT partitioned system, it will require you to create a 1-2MB grub boot partition, as it needs somewhere else to put its bloat. GPT actually still uses the MBR section, but simply creates one large partition covering the whole disk. This is so that tools that are not GPT aware will not think that they have a whole free disk to use as they please.
For comparison, here is whe I get from fdisk:
# fdisk -l /dev/sda
sudo fdisk -l /dev/sda
[sudo] password for curtisshima:
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
Disk /dev/sda: 250.1 GB, 250059350016 bytes, 488397168 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
1 2048 2099199 1G EFI System EFI System
2 2099200 252166798 119.2G Linux filesyste arch-btrfs-1
3 252168192 488397134 112.7G Linux filesyste arch-btrfs-3
Note that I do use GPT. But that is not the point here. What I am trying to show is where my first partition starts. This is also where fdisk will start partitions these days. This is to ensure compatibility with 4k advanced format disks.
If you are not dead set on Grub2, you could try using syslinux. I really like it much better, though if you are booting more than one Linux, you need to either employ chainloading to various partition boot records, or have a shared /boot. Having a windows partition doens't really matter, as you are simply chainloading to that funky reserved partition anyway.
The other option is to use grub-legacy, which can still be found in the AUR. I actually liked the orginal Grub, as it provided a nice feature set, but was still configurable by hand and it actually fit into the MBR.

Encrypt sensitive with password and calling sub pkgs

Hi we run 2012 enterprise and r introducing a db2 connection that "allows saving password".
We run from the file system (not the catalog) and face a challenge.
The default prot level on the SUB PACKAGE that has the db2 connection (only such connection right now) prevents our prod credentials from making the connection because its a different user than the one that created the sub pkg.
Encrypt sensitive with password seems a more strategic alternative but I dont know if the param (I think its called "decrypt") on the dtexec command line that allows passing a password at run time applies to just the parent pkg or all subs also.
I dont want to delay validation. I wouldnt even mind changing the xml connection string (by entering pswd in whatever syntax is necessary) using notepad but dont know what issues that will cause.
I wouldnt mind having someone logon and "re" save the pkg using the credentials of our prod userid and choosing the default prot level instead.
I also wonder if none of the other pkgs (including master) dont have any sensitive data, can their prot level defaults be left alone?
Can the community comment?

If you are having sensitive info (passwords for conn strings etc) in our packages, the best way is to change the protection level to "encrypt sensitive with password" and then provide the password.
When we schedule a job or exec the parent package, the child packages are called automatically.
Thanks, hsbal

Encrypted root with btrfs

Similar Messages

Maybe you are looking for