GRUB set address kernel is loaded at - grub

How would I go about changing the address GRUB tries to load my kernel at without using the linker?
I would like to do this from GRUB config files.

Boot your machine. When you get to the grub menu press c. You will go into grub prompt.
With ls you can view your devices and partitions. Look through your partitions until you have the correct one.
ls
ls (hd0,gpt1)/
ls (hd0,gpt2)/
ls (hd1,gpt1)/
ls (hd1,gpt2)/
...
Let's assume the files are located at hd0,gpt2 and it is the only USB device -> /dev/sda2. We also assume at the root folder / there is your kernel vmlinuz and an initial ramdisk initrd.img.
Type into your grub prompt:
set root=(hd0,gpt2)
linux /vmlinuz root=/dev/sda2 rootdelay=10
initrd /initrd.img
When your machine boots correctly you can put this into your grub config files.

Related

Buildroot with readonly filesystem: allow writing on /etc

I'm preparing a Buildroot IoT project based on Orange PI Zero, so I will make it a readonly system. Anyway, I need to persistently write on /etc to update wpa_supplicant.conf when user configure it for his WiFi network. I also need to update a custom text file with some config parameters, if the user want to.
I'd like to avoid remounting the whole filesystem in r/w everytime I need to update a single file.
Which is the best way to accomplish this?
You can set up a writable overlay on top of /etc so changes goes there. Options are either overlayfs in the kernel or unionfs using fuse. As init / initscripts already use /etc you may need to create a wrapper script around init to setup this overlay before executing init. - E.G. something like:
mount -t proc proc /proc
mount /mnt/data
mount -o bind /etc/ /mnt/rom-etc
unionfs -o cow,allow_other,use_ino,nonempty \
mnt/data=RW:/mnt/rom-etc=RO /etc/
exec /sbin/init $*

Make attached media bootable

Good evening everyone! I have been working on this for sometime, but can't figure it out. I am simply trying to get the working bootcode of a bootloader installed on an attached media, but can't figure this out!!! I have tried grub legacy, lilo, and grub2... The host system has it's drive listed as /dev/sda* and the target attached media is listed as /dev/sdb* and is mounted to /mnt/target.
With grub legacy, I was attempting to work with another media (/dev/sdc*, /mnt/source) that already had it installed and tried dirty hacks like:
dd if=/mnt/source/boot/grub/stage1 of=/dev/sdb bs=446 count=1
dd if=/mnt/source/boot/grub/stage2 of=/dev/sdb bs=512 seek=1
This will actually boot into a grub interface where you can enter things like:
root (hd0,0)
setup (hd0)
I get no error messages, but grub will boot to garbage on the screen and then stop.
With lilo, I actually had the package installed and tried to setup (after creating a lilo.conf):
default=Test1
timeout=10
compact
prompt
lba32
backup=/mnt/target/boot/lilo/MBR.hda.990428
map=/mnt/target/boot/lilo/map
install=/mnt/target/boot/lilo/boot.b
image=/mnt/target/boot/vmlinuz
label=Test1
append="quiet ... settime"
initrd=/mnt/target/boot/ramdisks/working.gz
And then from the prompt execute the following:
$ lilo -C /mnt/target/boot/lilo/lilo.conf -b /dev/sdb
Warning: /dev/sdb is not on the first disk
Fatal: Sorry, don't know how to handle device 0x0701
With grub2, I tried something like:
grub-mkconfig -o /mnt/target/boot/grub/grub.cfg
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.11.0-12-generic
Found initrd image: /boot/initrd.img-3.11.0-12-generic
Found memtest86+ image: /boot/memtest86+.bin
No volume groups found
done
I couldn't even get the above to generate a grub.cfg correctly or in the right spot so I gave up on this one... The entries listed above are for the host system, not the target system.
I can provide any additional information that you guys need to help resolve this problem.
-UPDATE-
After working with the media a bit longer, I decided to run an 'fdisk -l' and was presented with the following info:
Partition 1 has different physical/logical beginnings (non-Linux?):
phys(0,32,33) logical(0,37,14)
Partition 1 has different physical/logical endings:
phys(62,53,55) logical(336,27,19)
I should also note that when I try to mount the partition I always get a message that states:
EXT4-fs (sdb1): couldn't mount as ext3 due to feature incompatibilities
Not sure if that is just specific to busybox, or if that is related to the fdisk output. Anyhow, I don't know if the fdisk info is indicating that there may be a problem with the disk geometry that could be causing all these bootloaders to not work.
First stage boot sector code for grub legacy is in "stage1", for grub(2) in "boot.img". Fist stage code contains the address of next stage to be loaded on same disk.
On some other disk the address of next stage to be loaded could be (and is maybe) different.
I think using chroot and grub-install would be a better way to go.
See Grub2/Installing.
As for disk/partition structure:
dd if=/mnt/source/boot/grub/stage2 of=/dev/sdb bs=512 seek=1
maybe has overwritten partition table in MBR of sdb.

Mount VHD using GRUB2 loopback command

I need to mount a VHD file at grub2 command prompt.
I tries using "loopback" command as shown below:
grub > insmod ntfs
grub > insmod ntldr
grub > loopback loop (hd0,1)/test.vhd
grub > ls (loop)/
error: unknown filesystem
I tried both "static" and "dynamic" vhd and both VHD file had ntfs partitioned data.
I guess VHD files have some header data which makes the filesystem not recognizable after "loopback" mount. I am able to mount and access "iso" files using same set of commands.
Is my guess correct? If so, is there a way to overcome this issue?
Well, your guess is half right:
Whilst VHD supports a linear "fixed" storage model, which actually is just the raw data as it would be stored on a "real" hard drive, followed by a VHD footer, this is most probably not usually the case; VHD supports dynamically resizing images, which of course aren't linear internally, so you can't simply boot into that.
I was finally able to get the data from the loop mounted data with following change in the above pasted grub command.
grub > insmod ntfs
grub > loopback loop (hd0,1)/test.vhd
grub > ls (loop,1)/
The file "test.vhd" was a single partitioned VHD file.
NOTE: Only "fixed" or "static" model VHDs work. I could not get it working with "dynamic" VHD (as suggested by #Marcus Müller )
Thanks for the help. Hope this helps somebody.
To use VHD disks on grub2 need:
insmod part_msdos
insmod ntfs
loopback loop /point/where/disk.vhd tdisk=VHD
ls (loop,msdos1)/

Check in Cocoa if a MountPath Partition is bootable

I want to check that you can boot from a volume… Like the System Pref for Start Volume does.
Any ideas?
I looked in a lot of Tables, but nothing that indicates that is bootable.
On Linux you can use fdisk -l but that won't work on Mac OS.
diskutil info -plist (path)
With the -plist option the results include a boolean flag named Bootable.

symbolic links work when shared to Windows or Linux (smb), but broken when shared to Mac (afp or smb)

On a Mac, I have a shared folder, ~\Documents. There are two subfolders, Data and Data_2011, the former containing folders of files from the last several years, and the latter containing symbolic links to the folders in the Data folder that have been updated since Jan 1 2011. The links were created with the standard ln -s command.
When I mount the shared Documents folder on a Windows computer, the links work. When I mount on Linux using smb, the links work. When I use these links directly on the hosting Mac, they work. However, when I mount the Documents folder from a remote Mac, the soft links are broken. To be clear, I mount the Documents folder by going to Finder > Connect to Server > afp://xxx.xxx.xx.xx/ or smb://xxx.xxx.xx.xx/Documents
Any ideas for how to get these soft links to work when shared to a remote Mac?
-Sibo
Mac OS file sharing exposes symbolic links as actual symbolic links.
If I connect one Mac to another, using either AFP or SMB, I can confirm this.
Note that symbolic links are resolved by the client -- even in a non-file-sharing case this means relative paths in symbolic links can be tricky, and in this case involving network file sharing, it means the client computer needs to be able to see the target file (the target file must also be in a folder that's shared and mounted), and the path needs to be the same.
For example, if I create a text file named "foo" in my home directory, then do "ln -s foo symlink" to create a link to it named symlink, then mount that home directory from a second computer and do "ls -l" it's shown as "symlink# -> foo", and if I cat the file I can read it. But if I create the symlink as "ln -s /Users/matt/foo symlink", then on the second computer ls -l shows it as "symlink# -> /Users/matt/foo", and cat says "cat: symlink: No such file or directory". That's because on the second computer, /Users/matt is a local home directory that doesn't contain a file named foo (and if it did, anything resolving the symlink would see the local foo, not the foo shared from the first computer).
So basically: you can use "ls -l" to see where the symlink points, and note that the client computer will resolve the symlink and try to open whatever file has that name, which may or may not be what you expected.
(Probably the reason that your test worked from your Linux machine and not your Mac is that the Linux machine has more network shares mounted or with different names, such that the symlink target name was a valid filename on the Linux machine but not the Mac.)

Resources