Slackware This Forum is for the discussion of Slackware Linux.
|
| Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
 |
GNU/Linux Basic Guide
This 255-page guide will provide you with the keys to understand the philosophy of free software, teach you how to use and handle it, and give you the tools required to move easily in the world of GNU/Linux. Many users and administrators will be taking their first steps with this GNU/Linux Basic guide and it will show you how to approach and solve the problems you encounter.
Click Here to receive this Complete Guide absolutely free. |
|
 |
03-11-2011, 01:18 PM
|
#1
|
|
LQ Newbie
Registered: Jul 2009
Posts: 5
Rep:
|
Slack current with btrfs root (seperate /boot) has mkinitrd issue
Harddrive setup is:
/dev/sda1 /boot
/dev/sda2 swap
/dev/sda3 LUKS encrypted
Then on the encrypted partition, I used btrfs, but my Slackware root is really a subvolume named system and not the root of btrfs. I do a similar setup of having the OS's root in it's own filesystem on FreeBSD+ZFS.
Anyways, my problem lies in mkinitrd. There's no way to enter extra boot options, as I require subvol=system to be added to
mount -o ro -t $ROOTFS $ROOTDEV /mnt
in the init script of /boot/initrd.gz. I don't reboot often and it's easy to manually remount /mnt with the correct options, however, is there another way of passing boot options to mkinitrd?
I see Patrick is the author of mkinitrd, so maybe this kind of option could, or maybe should, be added? I'm sure most people wouldn't make a subvolume for the OS's root, but I've been use to it with ZFS and prefer it for some reason.
|
|
|
|
03-11-2011, 04:47 PM
|
#2
|
|
Senior Member
Registered: Sep 2006
Location: Liverpool - England
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810
|
Hey - your post get me interested in btrfs file systems, (of which I have no experience), so I created a new Slackware VM in VirtualBox following Alien Bob's instructions for installing LUKS and LVM,( something I have done before), and utilizing a btrfs root file system, (something I have not done before), and everything worked OK.
Now admittedly I am not using subvolumes here so obviously your setup is more sophisticated than my test rig however would it not be possible to just edit /boot/initrd-tree/init and add your subvol=system bits manually to the "mount -o ro -t $ROOTFS $ROOTDEV /mnt" parts of the script and then create the initrd without adding the "-c" to clear initrd-tree? Mkinitrd is an amazing script and i'm sure it can easily create the new initrd from existing contents ot the /boot/initrd-tree. As said, this should create the initrd from the existing contents of /boot/initrd-tree including your edited mount parts. I hope so but I've not tried it - in any case thanks for your interesting post - I love new areas of Linux to experiment with, ( yes, I'm a total geek), and the combination of LUKS/LVM and btrfs got my interest!
I think I'll be looking into brtfs a lot as I have a fascination with different filesystems and their benefits. The Hammer filesystem, part of DragonFly BSD is personal a favourite.
|
|
|
1 members found this post helpful.
|
03-11-2011, 05:02 PM
|
#3
|
|
Member
Registered: Feb 2009
Distribution: Slackware, Arch
Posts: 513
Rep: 
|
I could be wrong, but isn't LVM2 unnecessary with btrfs? I thought it had most of LVM2's features built-in.
|
|
|
|
03-11-2011, 05:21 PM
|
#4
|
|
Senior Member
Registered: Sep 2006
Location: Liverpool - England
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810
|
Quote:
|
I could be wrong, but isn't LVM2 unnecessary with btrfs? I thought it had most of LVM2's features built-in.
|
Very possibly, as I said my experience of LUKS is limited and I have only ever combined it with LVM following Eric's instructions in README_CRYPT and as he says :
Quote:
|
If you want to unlock your complete system using a single passphrase, and if you do not shy back from using LVM, then the better alternative is to follow the instructions in the "Combining LUKS and LVM" chapter which follows next. If you think that LVM adds one layer of complexity too much, then just read on and implement the solution described right here.
|
so it's possibly just me jumping in with the LVM additional bits. The OP made no mention of LVM's.
|
|
|
|
03-11-2011, 05:21 PM
|
#5
|
|
Senior Member
Registered: May 2008
Posts: 2,839
|
Perhaps the addition of a $ROOTOPTS variable to the initrd script would do it. Shouldn't be too hard.
I've not played with btrfs yet, but can you make use of
Quote:
subvolume set-default <id> <path>
Set the subvolume of the filesystem <path> which is mounted as default. The subvolume is identified by <id>, which is returned by
the subvolume list command.
|
as a workaround?
|
|
|
|
03-11-2011, 10:32 PM
|
#6
|
|
LQ Newbie
Registered: Jul 2009
Posts: 5
Original Poster
Rep:
|
Quote:
|
edit /boot/initrd-tree/init and add your subvol=system bits manually to the "mount -o ro -t $ROOTFS $ROOTDEV /mnt" parts of the script and then create the initrd without adding the "-c" to clear initrd-tree?
|
Yes sir. I had the same idea, but forgot to drop the -c option, thank you.
Quote:
|
I could be wrong, but isn't LVM2 unnecessary with btrfs? I thought it had most of LVM2's features built-in.
|
Correct, with btrfs, no need for LVM. So my setup is LUKS + btrfs instead of LUKS + LVM.
Quote:
|
Perhaps the addition of a $ROOTOPTS variable to the initrd script would do it.
|
Was wondering if Pat would be interested about adding something like $ROOTOPTS. Although, how many initrd's need extra mount options? The solution of editing the init script and not cleaning the tree seems to be a better approach, at least for now anyways.
|
|
|
|
03-12-2011, 05:06 AM
|
#7
|
|
Senior Member
Registered: May 2008
Posts: 2,839
|
Quote:
Originally Posted by rexregis
The solution of editing the init script and not cleaning the tree seems to be a better approach, at least for now anyways.
|
Yep, I've done that before too.
Tip: create yourself a initrd_build.sh and put all the commands necessary to build your custom initrd in there. If you do it manually then sooner or later when it's time for a new kernel, you'll end up forgetting to do it.
And, I've done that before too.
Was the btrfs subvolume set-default suggestion no good for you?
|
|
|
1 members found this post helpful.
|
03-12-2011, 08:21 AM
|
#8
|
|
LQ Newbie
Registered: Jul 2009
Posts: 5
Original Poster
Rep:
|
Quote:
Originally Posted by GazL
Was the btrfs subvolume set-default suggestion no good for you?
|
To be honest, once I saw the -c suggestion, I went "I'm an idiot." and never tried the set-default suggestion. Not sure I want to try set-default, as btrfs is essentially a partition manager also, so I can install several btrfs supported OSes all within one MBR/GPT partition. Thus one of the main reasons I do not use the btrfs root as the OS root, instead create a subvolume for the OS root.
Example:
OS #1: / - subvol=system; /usr - subvol=usr; /var - subvol=var; /home - subvol=home
OS #2: / - subvol=system2; /usr - subvol=usr2; /var - subvol=var2; /home - subvol=home
And so on, until I run out of storage space. And easy to delete an OS I no longer want to boot. All without ever needing to redo MBR/GPT partitions.
So in my case, I think it would be easier to make a second initrd.gz which has mount -o subvol=system2, and tell lilo in another entry to use that second initrd.gz. Your suggestion, I would have to issue the set-default command at each reboot that I wanted to switch OSes? I could be wrong though.
Quote:
|
Tip: create yourself a initrd_build.sh
|
Already had a script to run mkinitrd, problem was it had the -c option in it. Operator error. Thank for the tips though.
|
|
|
1 members found this post helpful.
|
| Thread Tools |
Search this Thread |
|
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -5. The time now is 10:08 PM.
|
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|