Re: [gentoo-user] Installing BTRFS on MBR with OpenRC
On 15 August 2015 8:54:56 AM AEST, Peter Humphrey wrote:
>
># cat /boot/grub/grub.cfg
>root (hd0,1)
>timeout 10
>
>Menuentry 'Gentoo Linux 4.0.5, no X {
> linux /boot/kernel-x86_64-4.0.5-gentoo root=/dev/sda4 softlevel=nox
>net.ifnames-0
I presume the -0 is a typo. Should be =0 ? Not that its likely to be related
> initrd /boot/initramfs-4.0.5-gentoo.img
>}
>
># grep initrd /var/log/dracut.log
>I: *** Creating initrd image file '/boot/initramfs-4.0.5-gentoo.img'
>done ***
>--->8
>
># ls -l /boot
>--->8
>-rw--- 1 root root 6.7M Aug 14 23:22 initramfs-4.0.5-gentoo.img
>-rw-r--r-- 1 root root 3.9M Aug 14 23:12 kernel-x86_64-4.0.5-gentoo
>--->8
>
># grep btr /etc/fstab
>LABEL=GENTOO / btrfs defaults0 0
Have you tried putting /dev/sda4 in place of LABEL=GENTOO?
Probably wont help, but worth a try.
>
>All that seems right to me. The label came from mkfs.btrfs -m raid1 -d
>raid1 --label=GENTOO /dev/sda4 /dev/sdb4
>
>Adding rootdelay=30 made no difference either. In fact I didn't see
>such a
>pause.
It does smell like a timing issue, but I'm out of ideas, I'm afraid.
--
:b
Re: [gentoo-user] iptables tunneling a chrooted Linux?
On Sat, Aug 15, 2015 at 2:53 AM, Andrew Savchenko wrote: > > On Sat, 15 Aug 2015 06:53:30 +0200 meino.cra...@gmx.de wrote: >> on my Android tablet I have installed a Gentoo rootfs. >> I can start this by chgrooting it after Android has booted. >> Via xvnc I can connect from a running Android to the also >> running Gentoo Linux. >> If I set up a firewall as root (the Android is rooted) while >> I am in the chrooted Linux this firewall setting have to be >> active also in the Android environment, right? >> Of vice versa: I can track any network traffic of the Android >> OS inside my chrooted Linux, right? >> >> One kernel to rule them all...? > > If this is only chroot, you have to set all iptables rules (and > other network configuration) in the host system environment (on > Android). A bit of clarification here: Chroots and their "hosts" share the same network configuration. So, if you configure an iptables rule in the chroot, it affects the host, and vice-versa. That means you can set things up on either side, as long as you're talking about kernel-space settings (iptables, iproute2, etc). If you're touching resolv.conf or /etc/hosts that of course needs to be done in both places. > If you are using LXC or other container...then you have to set up network > inside container and > bridge/route it with the host system. If you're using containers, the network namespace can be shared or not. If the namespace is shared, then it behaves the same as a chroot with regard to the network, iptables, etc. If the network namespace is not shared then the container gets its own interface, and there are a lot of options for how you go from there. Usually you just bridge a virtual ethernet interface to the host, but if you have multiple physical interfaces you could have each namespace have its own physical interface (I have no idea if the cell network vs wifi network interfaces are separated in android). You could set iptables either on the bridge on the host (which MUST be done from the host), or on the virtual interface in the container, and each set of rules affects the packets that go through it. Also, if you're bridging your container will have a different IP, so you might need NAT on the host if your cell provider blocks multiple DHCP assignments to the same device. I actually have openvpn running in a container and it acts as the gateway for my network (everything else just sees it as a standard router, including the host). That does need some iproute2 magic if your host ends up also servicing non-vpn traffic since it is multi-networked. It would be easier to set up on a phone. -- Rich
Re: [gentoo-user] Installing BTRFS on MBR with OpenRC
On Saturday 15 August 2015 04:15:37 Neil Bothwick wrote:
> On Fri, 14 Aug 2015 23:54:56 +0100, Peter Humphrey wrote:
> > # cat /boot/grub/grub.cfg
> > root (hd0,1)
> > timeout 10
> >
> > Menuentry 'Gentoo Linux 4.0.5, no X {
> >
> > linux /boot/kernel-x86_64-4.0.5-gentoo root=/dev/sda4
> >
> > softlevel=nox net.ifnames-0
> >
> > initrd /boot/initramfs-4.0.5-gentoo.img
> >
> > }
>
> Is this what dracut --print-cmdline recommended?
This is one long series of humbl^W learning experiences.
--
Rgds
Peter
Re: [gentoo-user] Installing BTRFS on MBR with OpenRC
On Saturday 15 August 2015 20:46:32 Bruce Schultz wrote:
> On 15 August 2015 8:54:56 AM AEST, Peter Humphrey
wrote:
> ># cat /boot/grub/grub.cfg
> >root (hd0,1)
> >timeout 10
> >
> >Menuentry 'Gentoo Linux 4.0.5, no X {
> >
> > linux /boot/kernel-x86_64-4.0.5-gentoo root=/dev/sda4 softlevel=nox
> >
> >net.ifnames-0
>
> I presume the -0 is a typo. Should be =0 ? Not that its likely to be related
> > initrd /boot/initramfs-4.0.5-gentoo.img
Yes, you're right; it's a typo. The selection and paste buffers are distinctly
rocky into and out of VirtualBox, so I had the two windows adjacent and typed
what I read (almost!).
--->8
> ># grep btr /etc/fstab
> >LABEL=GENTOO / btrfs defaults0 0
>
> Have you tried putting /dev/sda4 in place of LABEL=GENTOO?
> Probably wont help, but worth a try.
Yes, tried that.
> It does smell like a timing issue, but I'm out of ideas, I'm afraid.
It looks as though Neil has hit the nail on the head.
--
Rgds
Peter
Re: [gentoo-user] iptables tunneling a chrooted Linux?
Rich Freeman [15-08-15 13:04]: > On Sat, Aug 15, 2015 at 2:53 AM, Andrew Savchenko wrote: > > > > On Sat, 15 Aug 2015 06:53:30 +0200 meino.cra...@gmx.de wrote: > >> on my Android tablet I have installed a Gentoo rootfs. > >> I can start this by chgrooting it after Android has booted. > >> Via xvnc I can connect from a running Android to the also > >> running Gentoo Linux. > >> If I set up a firewall as root (the Android is rooted) while > >> I am in the chrooted Linux this firewall setting have to be > >> active also in the Android environment, right? > >> Of vice versa: I can track any network traffic of the Android > >> OS inside my chrooted Linux, right? > >> > >> One kernel to rule them all...? > > > > If this is only chroot, you have to set all iptables rules (and > > other network configuration) in the host system environment (on > > Android). > > A bit of clarification here: Chroots and their "hosts" share the same > network configuration. So, if you configure an iptables rule in the > chroot, it affects the host, and vice-versa. That means you can set > things up on either side, as long as you're talking about kernel-space > settings (iptables, iproute2, etc). If you're touching resolv.conf or > /etc/hosts that of course needs to be done in both places. > > > If you are using LXC or other container...then you have to set up network > > inside container and > > bridge/route it with the host system. > > If you're using containers, the network namespace can be shared or > not. If the namespace is shared, then it behaves the same as a chroot > with regard to the network, iptables, etc. If the network namespace > is not shared then the container gets its own interface, and there are > a lot of options for how you go from there. Usually you just bridge a > virtual ethernet interface to the host, but if you have multiple > physical interfaces you could have each namespace have its own > physical interface (I have no idea if the cell network vs wifi network > interfaces are separated in android). You could set iptables either > on the bridge on the host (which MUST be done from the host), or on > the virtual interface in the container, and each set of rules affects > the packets that go through it. Also, if you're bridging your > container will have a different IP, so you might need NAT on the host > if your cell provider blocks multiple DHCP assignments to the same > device. > > I actually have openvpn running in a container and it acts as the > gateway for my network (everything else just sees it as a standard > router, including the host). That does need some iproute2 magic if > your host ends up also servicing non-vpn traffic since it is > multi-networked. It would be easier to set up on a phone. > > -- > Rich > Hi Andrew, hi Rich, thanks for your replies! 8) Android has a "problem": Apps/Applications for the masses with advanced features broken down to a few colored bottoms to press. Sounds a little pessimistic...it is not. Its only the sound of frustration. I want to block out the "man (goo...) in the middle" while copying files from my PC to my tablet and vice versa via wifi. As soon the wifi is switched on, my tablet starts talking to persons I had never known (goo...). So I installed some Android firewalls and a Android SFTP-servers. No go...all firewalls I tried block all incoming traffic and there is no switch to deactivate or define it better. Some SFTP-server application even stop working, if they could not phone home. Last chance: Installing a fully functional chrooted Linux, setup some handcrafted iptables/ipset/sidmat stuff (which I still have to do) and...get a "Yes, network is shared on kernel level" as answer from this thread. :) And I got this answer...YEAH! :)) Thanks a lot for your help!!! Best regards and have a nice weekend! Meino
Re: [gentoo-user] iptables tunneling a chrooted Linux?
On Sat, Aug 15, 2015 at 7:45 AM, wrote: > Last chance: Installing a fully functional chrooted Linux, setup > some handcrafted iptables/ipset/sidmat stuff (which I still have > to do) and...get a "Yes, network is shared on kernel level" as answer > from this thread. :) > And I got this answer...YEAH! :)) > Yup. If your goal is to block outgoing connections to selected IPs then you just need to have iptables/etc installed. Doing it from a chroot is probably a good a solution as any. You could also go the prefix route, though that is trickier. Neither is any better, so I'd stick with simple and use the chroot. -- Rich
[gentoo-user] Re: Installing BTRFS on MBR with OpenRC
Peter Humphrey prh.myzen.co.uk> writes: > > https://wiki.archlinux.org/index.php/Boot_debugging#netconsole > > the document is excellent, but some steps may have to be modified > > for your particular setup and debug needs. > Thanks James. I seem to have plenty of progress messages already; it isn't > like a standard boot process because it's in a VM. > Still, I'll have a look at it. Perhaps a parallel (as much as possible) install on actual spinning rust (a real HD) might illuminate the location of the problem(s) inherent to the VM install procedure ? Perhaps, just separate the steps into (2) separate sequences, one real one for vm, and (assuming the real hw steps work) look at the differences on what much occur for the vm install to be successful? Perhaps script it up and let different folks try your steps (sequence) to verify the failure points of the install procedss? hth, James
