Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with chroot into nodev mount #199

Closed
semsen opened this issue Feb 6, 2013 · 3 comments
Closed

Problem with chroot into nodev mount #199

semsen opened this issue Feb 6, 2013 · 3 comments
Labels
bug The code does not do what it is meant to do discuss / RFC enhancement Adaptions and new features

Comments

@semsen
Copy link

semsen commented Feb 6, 2013

Since 1.1x rear mounts the filesystems while the recover with the originated mount options. I have a problem with the final chroots for mkinitrd and grub. I use SLES11 SP2 and mount the "normal" filesystems due to some security advices with the "nodev" option.
So when there is done the chroot to /mnt/local the /dev doesn't work and there are errors from the mkinitrd part (only cosmetic) but also from the part the grub configuration because grub says the device does not exist and he does nothing.

Since I was not able to mount a udev or devfs to /mnt/local/dev quickly like its done for /proc, I solved it by overwriting the "nodev" with "dev" for / in the disklayout.conf

Here's my change in layout/save/GNU/Linux/23_filesystem_layout.sh

    options=${options#(} 
    options=${options%)} 
   # Don't mount the original root fs with nodev, chroot for initrd and grub won't work 
   if [[ $mountpoint = "/" ]]; then 
    options=$(echo $options|sed 's/nodev/dev/') 
   fi 
    echo -n " options=$options" 

Please feel free to adopt this change. Maybee a better place to solve this problem is not when writing the disklayoutfile, but when reading it. It would also be possible to do a remount before the chroots, but I thought this would be the place nodev is removed thoroughly.

I had an adittional problem.

In my old environment (SELS10, rear 1.7.23, TSM-Backup with TSM-Client 6.2) a rear recover produced a ISO of about 40MB. In my new environment (SLES11, rear 1.14 and TSM Backup with TSM-Client 6.4) the ISO is about 175MB!

Some of the groth is about SLES11, some is about rear (packaging all storage and network drivers into the iso). But most of the growth is caused by the new TSM Client which has a lot of huge libs. I had to enlarge my /tmp and /var filesystems to run rear recover successfully.
Therefor I exclude some files via COPY_AS_IS_EXCLUDE_TSM in my local.conf

COPY_AS_IS_EXCLUDE_TSM=( /opt/tivoli/tsm/client/api/bin64/libTsmViSdk.so /opt/tivoli/tsm/client/ba/bin/libTsmViSdk.so /opt/tivoli/tsm/client/ba/bin/libtypes.so /opt/tivoli/tsm/client/ba/bin/plugins64/libdiskLibPlugin.so )

TSM-Restore works without them and the ISO shrinked to 100MB

Maybee you can add this in the default.conf, (maybee as comment) to give users a hint where to start.

@gdha
Copy link
Member

gdha commented Feb 6, 2013

@dagwieers @jhoekx What are your opinions about the "nodev" issue?

@jhoekx
Copy link
Contributor

jhoekx commented Feb 6, 2013

Let's just ignore the nodev option in 13_include_filesystem_code.sh.

@jhoekx jhoekx closed this as completed in 92b0b7f Feb 6, 2013
@jhoekx
Copy link
Contributor

jhoekx commented Feb 6, 2013

Not quite tested the fix. Please reopen if the issue is still present.

dagwieers pushed a commit to dagwieers/rear that referenced this issue Jun 7, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The code does not do what it is meant to do discuss / RFC enhancement Adaptions and new features
Projects
None yet
Development

No branches or pull requests

3 participants