Re: Patching kernel with aufs (riding a dead horse?)
Moin^WHi
Thomas Lange schrieb:
> > Has someone got a patch ready which I can apply to a recent 2.6.27 (or
> > later) kernel to get aufs in there? I've been struggling yesterday
> > evening without much success to get this into the kernel tree, somehow I
> > made something wrong:
> Have a look at grml. IIRC they use a very recent kernel, and they also
> use FAI and live-initramfs to build their live CD.
>
I'm using that now, but it breaks in the initramfs:
debug output from live.log (typed in manually, so might contain typos)
+ mount -t aufs -o
noatime,dirs=/cow=rw:/live/image/live/filesystem.dir=rr aufs /root
mount: mounting aufs on /root failed: No such device
+ panic mount aufs on /root failed with option
noatim,dirs=/cow=rw:/live/image/live/filesystem.dir=rr
then a few lines showing the variables DEB_{1,2,3,4}, LIVELOG and DEBUG
then I get the shell
The directory /root exists (part of / whicih is of type rootfs (rw)
/live/image is of type nfs (/srv/fai/nfsroot on the nfs server)
/cow is of type tmpfs(rw)
Any idea? So far google only gave me blanks.
Thanks a lot
Carsten
Re: Patching kernel with aufs (riding a dead horse?)
short update: /proc/config.gz with the grml kernel did not show any AUFS related entries, now trying the same with Ubuntu's jaunty kernel 2.6.28-11-server so far it looks good. Cheers Carsten
Re: Patching kernel with aufs (riding a dead horse?)
* Carsten Aulbert [20090507 10:50]:
> Thomas Lange schrieb:
> > > Has someone got a patch ready which I can apply to a recent 2.6.27 (or
> > > later) kernel to get aufs in there? I've been struggling yesterday
> > > evening without much success to get this into the kernel tree,
> > somehow I
> > > made something wrong:
> > Have a look at grml. IIRC they use a very recent kernel, and they also
> > use FAI and live-initramfs to build their live CD.
> I'm using that now, but it breaks in the initramfs:
> debug output from live.log (typed in manually, so might contain typos)
> + mount -t aufs -o
> noatime,dirs=/cow=rw:/live/image/live/filesystem.dir=rr aufs /root
> mount: mounting aufs on /root failed: No such device
> + panic mount aufs on /root failed with option
> noatim,dirs=/cow=rw:/live/image/live/filesystem.dir=rr
> then a few lines showing the variables DEB_{1,2,3,4}, LIVELOG and DEBUG
> then I get the shell
> The directory /root exists (part of / whicih is of type rootfs (rw)
> /live/image is of type nfs (/srv/fai/nfsroot on the nfs server)
> /cow is of type tmpfs(rw)
> Any idea? So far google only gave me blanks.
The initramfs includes aufs? (Rebuilding the initramfs in case of
question is always a good idea ;))
How does /proc/cmdline and /proc/mounts look like?
Step into debugging using the break= bootoption (like for example
break=live-bottom).
PS: Using a digicam to make a screenshot is a good idea to avoid
confusing typos. :)
regards,
-mika-
--
http://michael-prokop.at/ || http://grml.org/ || http://grml-solutions.com/
signature.asc
Description: Digital signature
Re: Patching kernel with aufs (riding a dead horse?)
* Carsten Aulbert [20090507 11:27]: > short update: > /proc/config.gz with the grml kernel did not show any AUFS related > entries, now trying the same with Ubuntu's jaunty kernel 2.6.28-11-server > so far it looks good. We (as in grml) use aufs as external module and don't patch it into our kernel nowadays (so we can update aufs later on without the need to touch the kernel). Just use module-assistant with aufs-source. regards, -mika- -- http://michael-prokop.at/ || http://grml.org/ || http://grml-solutions.com/ signature.asc Description: Digital signature
Re: option bootable in setup-storage
Hi, Michael Tautschnig wrote on 2009-05-07 06:17:28 +0200 [Re: option bootable in setup-storage]: > > [...] > > I'm just wondering ... what happens if / is on a logical partition or > > LVM LV? > > I do test for / being on a real disk and only set the bootable flag (or > actually the value in the hash that will later cause the bootable flag to > be set) only in such cases, so we should be fine. But anyway, thanks for > looking closely! I wasn't really worried about the implementation. I was wondering about the concept. I don't fully understand the implications of the matter, so maybe my point is, err, pointless. Ideally, the config file specifies which partition (if any) is to be marked bootable. If none is marked, we have the root partition as default, if (and only if) it is on a primary partition. Otherwise we have no default. The historical purpose of the bootable flag (as I understand it, on x86 systems) is to tell DOS MBR which partition to boot. With lilo, grub et al. this is obsolete. I take it some BIOSes make a misguided attempt of plausibility checking and only boot the MBR if a partition is marked bootable (this assumption is - possibly incorrectly - deduced from the initial issue of this thread). Sure, DOS MBR *can* boot a grub stage1 or lilo boot sector off a primary partition (which would, thus, need to be marked bootable), but this can just as well be /boot or even /usr/local/foo if someone were inclined to set it up that way. My point is: the default of / can be wrong, there remain cases without a default, and there are cases where no partition needs to be marked bootable, so what is the point of providing a default in the first place (which can really just be a convenience to save typing, but not thinking)? Put differently: the current solution is complicated to define, which might mean it is not optimal. Then again, I might be missing important facts (especially on non-x86- platforms) ... Regards, Holger
System stalls (for 15-30 minutes) during savelog
Hi, after the jaunty kernel gives the same result as the originally tried 2.6.26, so I think I can mostly exclude that it's a kernel issue. So, one of our new boxes (Asus board with 2 GPUs on it) boots via PXE, starts the FAI install (3.2.16) and runs through it fine, however, when almost done it tries to run savelog and during that it fails, loses its network interface and stalls for 15-30 minutes. It always fails when trying to transfer the content of dmesg, thus on the FAI server this file is always of size 0 while other files before are transferred fine. This was tested with both rsh and ssh. Also, when I log into the system via ssh and call dmesg interactively, it also kills the network interface and the install then of course stalls as well. Writing dmesg directly into a file and copying it over via scp works, but does not reveal anything strange. http://atlas.atlas.aei.uni-hannover.de/~carsten/installlog.jpg shows a (bad) screen shot of the last lines during the installation. In this state it takes between 15-30 minutes until some time-out kicks in and the machine is rebooted. When switching over to tty4 I do see this weird stuff on the screen: http://atlas.atlas.aei.uni-hannover.de/~carsten/syslog.jpg Anyone with an idea what's happening to this nice and shiny box? Cheers Carsten
Re: Patching kernel with aufs (riding a dead horse?)
Hi Michael Prokop schrieb: > > The initramfs includes aufs? (Rebuilding the initramfs in case of > question is always a good idea ;)) > I rebuilt it, but if they are coming with an external package I probably have missed that, i.e. not a chance for the poor kernel to mount that. My fault, sorry. > How does /proc/cmdline and /proc/mounts look like? > Step into debugging using the break= bootoption (like for example > break=live-bottom). I could try that again if you want to get the results, right now I'm using the Ubuntu jaunty server kernel which has aufs build in. > > PS: Using a digicam to make a screenshot is a good idea to avoid > confusing typos. :) Yeah, I was to lazy to go back into my office. See my other email, there you can see two bad screen shot with the digicam - unfortunately it's too cheap. Without a flash light I was not able to get good image, may I propose the name "Tattergreis" as the successor of "Schluchtenscheisser" ;)? Cheers Carsten
Re: System stalls (for 15-30 minutes) during savelog
> On Thu, 07 May 2009 16:36:38 +0200, Carsten Aulbert > said: > It always fails when trying to transfer the content of dmesg, thus on > the FAI server this file is always of size 0 while other files before > are transferred fine. This was tested with both rsh and ssh. Strange. In the past I also had a machine were I got the strange strings in the kernel logs (looks a little bit like rot-13). But I can't remember how I fixed it. > Also, when I log into the system via ssh and call dmesg interactively, > it also kills the network interface and the install then of course Maybe some strange chars in dmesg causes the network break, but I'm sure that's a kernel problem with your hardware. Can you try you configuration with another piece of hardware. Did you run memtest86+ on this machine? -- regards Thomas
Re: System stalls (for 15-30 minutes) during savelog
Hi Thomas, Thomas Lange schrieb: > Strange. > > In the past I also had a machine were I got the strange strings in the > kernel logs (looks a little bit like rot-13). But I can't remember how > I fixed it. Piyty that, I wish you could remember. > > > Also, when I log into the system via ssh and call dmesg interactively, > > it also kills the network interface and the install then of course > Maybe some strange chars in dmesg causes the network break, but I'm > sure that's a kernel problem with your hardware. > > Can you try you configuration with another piece of hardware. > Did you run memtest86+ on this machine? Just tried an another (identical box) showing the very same problem. I'll try it on another box as well. Anyone else? Cheers Carsten PS: Is there an easy way to enable an accessible terminal on tty2 and 3? I've tried editing /etc/inittab in the live image, but that did not do the trick. I'm currently looking into the main fai cfengine script in there
Re: option bootable in setup-storage
> Hi, > > Michael Tautschnig wrote on 2009-05-07 06:17:28 +0200 [Re: option bootable in > setup-storage]: > > > [...] > > > I'm just wondering ... what happens if / is on a logical partition or > > > LVM LV? > > > > I do test for / being on a real disk and only set the bootable flag (or > > actually the value in the hash that will later cause the bootable flag to > > be set) only in such cases, so we should be fine. But anyway, thanks for > > looking closely! > > I wasn't really worried about the implementation. I was wondering about the > concept. I don't fully understand the implications of the matter, so maybe my > point is, err, pointless. > > Ideally, the config file specifies which partition (if any) is to be marked > bootable. If none is marked, we have the root partition as default, if (and > only if) it is on a primary partition. Otherwise we have no default. > > The historical purpose of the bootable flag (as I understand it, on x86 > systems) is to tell DOS MBR which partition to boot. With lilo, grub et al. > this is obsolete. I take it some BIOSes make a misguided attempt of > plausibility checking and only boot the MBR if a partition is marked bootable > (this assumption is - possibly incorrectly - deduced from the initial issue > of this thread). Sure, DOS MBR *can* boot a grub stage1 or lilo boot sector > off a primary partition (which would, thus, need to be marked bootable), but > this can just as well be /boot or even /usr/local/foo if someone were inclined > to set it up that way. > My impression also was that this isn't that much needed anymore, but as the initial author of this thread had problems with such situtations, your analysis seems to be correct: Most of the time it works even without anything being marked bootable, but sometimes it doesn't. > My point is: the default of / can be wrong, there remain cases without a > default, and there are cases where no partition needs to be marked bootable, > so what is the point of providing a default in the first place (which can > really just be a convenience to save typing, but not thinking)? > Put differently: the current solution is complicated to define, which might > mean it is not optimal. > > Then again, I might be missing important facts (especially on non-x86- > platforms) ... > You're definitely right: It is somewhat complicated to define and the defaults might even be wrong. I'm open for either change: Make setup-storage use the currently experimental new "default is /" code, or, instead, change the man-page to match what is currently in FAI 3.2.20. Both solutions are really easy to implement, it's rather a matter of what the majority perfers. Even though a bit bogus, I'll for now leave the situation as is: One possible bugfix is ready, but it stays in experimental. I'll just wait for further feedback. Best, Michael pgpwvWwNIsqNC.pgp Description: PGP signature
Re: Thank you and good bye.
Henning Sprang wrote: > Russ Allbery wrote: >> Debian-based FAI cannot build Ubuntu intrepid or jaunty systems; the >> boot from the NFS root fails. That's due to the initramfs-tools and >> live-initramfs problems. > > But that happens only when you try to install from an Ubuntu NFSRoot - > which you don't need to. > > You can extract about any base image you want, from a Debian NFSroot, > even Redhat and SuSE, and then call their package managers, etc. from > the NFSroot into /target. > > That way, the initrd from Ubuntu is not used at install time. > Or do I get the problem wrong? We are planning to upgrade(?) from etch to jaunty this summer in our computer labs due to demands for newer software versions. But I don't want to lose fai in the process, and that includes softupdate. Can I use this method on a lenny server with the stock fai package, or do I need a newer version from the fai repository? What about softupdate after such an installation? Is it still broken in Ubuntu? If so, would it be possible to use some debian version of fai-client? I haven't seen any automatic installation for Ubuntu that comes close to fai, so if I cannot use fai, I'll probably go with lenny instead and take the beating from the users. /Per
Re: Thank you and good bye.
Per Foreby wrote: > Can I use this method on a lenny server with the stock fai package, or > do I need a newer version from the fai repository? Lenny version should do fine. > What about softupdate after such an installation? Is it still broken in > Ubuntu? Where softupdates broken in Ubuntu? I did not notice. I only use hardy and the last time I checked, it worked fine. (that said, that answers my question about throwing fai out of ubuntu: as long as softupdates work, it should stay there, and that is independent from initrd-stuff). Henning
Re: Thank you and good bye.
Henning Sprang wrote: > Per Foreby wrote: >> Can I use this method on a lenny server with the stock fai package, or >> do I need a newer version from the fai repository? > > Lenny version should do fine. > >> What about softupdate after such an installation? Is it still broken in >> Ubuntu? > > Where softupdates broken in Ubuntu? I did not notice. I read it somewhere, but i hope I'm wrong. (I just recently started investigating fai/ubuntu, so consider me a novice.) > I only use hardy and the last time I checked, it worked fine. But if you use Ubuntu's fai-client to do a softupdate against a $FAI_CONFIGDIR from Debian's fai-server, isn't there a risk that the configuration will be incompatible if the fai versions don't match? > (that said, that answers my question about throwing fai out of ubuntu: > as long as softupdates work, it should stay there, and that is > independent from initrd-stuff). Sounds wise as long as the initial installation can be done from a Debian fai server. /Per
